[00:29] Agenda
First, I’ll talk about migration in general and the challenges you might face.
Then I’ll go into Konveyor and Konveyor AI in more detail.
After that, I’ll show a short demo of Kai.
Finally, I’ll share our experience and opinion of Kai, and give a short outlook on what the future could look like for us when it comes to Konveyor AI.
[01:16] The migration challenge
When you want to migrate to another technology, or move an application to the cloud, it is usually not just a simple version bump.
In organizations and enterprise applications, there are often custom implementations that may not work with the target technology.
Dependencies and annotations often need to be replaced with the correct alternatives.
Tests and runtime behavior on the new technology can also require changes.
During the Learning Friday project, we looked at what we might face when migrating to Quarkus.
When tackling a challenge like this, you usually want to check what already exists, so you do not reinvent the wheel. So that is what we did. That was how we first heard about Konveyor and, more specifically, Konveyor AI.
[02:56] What is Konveyor?
Konveyor is an open-source community project and, as far as I know, a CNCF Sandbox project.
The tools and components around Konveyor are focused on analyzing, planning, and transforming applications.
One component is the Konveyor Hub. It helps you categorize and label applications, especially when you have multiple applications in an organization. You can also run analyses there.
Another tool is the Konveyor CLI, also called Kantra. It can analyze your codebase.
That brings us to Kai, which is another component of Konveyor. Kai is the component that uses AI in the background.
[04:15] What is Kai?
Kai is currently a Visual Studio Code extension. At the moment, it is only available for VS Code, although it might support other IDEs in the future.
Kai uses static code analysis.
It also uses RAG, although currently only for one feature that I am aware of.
Kai is capable of learning during migrations, depending on how you use it and whether you want to use that feature.
In the background, Kai uses an LLM to solve issues or help you solve them.
A useful aspect is that Kai is model-agnostic. You can use common models, including locally hosted ones. The only real requirement is that they are compatible with the OpenAI API.
This is especially useful because not every organization wants to send its source code to an external provider. With Kai, you can host a model yourself and configure the endpoint where it is reachable.
[05:50] Demo application
Let’s move into the demo.
First, a bit of context about the application we used during the Learning Friday project.
It is a small backend application for game score tracking. This is the same application I will open in the IDE.
The migration target is from Jakarta EE to Quarkus.
Some technical context:
- Java 21
- WildFly 34
- five modules
- one module mainly used to package a WAR file
- 22 REST endpoints
- around 1,500 lines of code
So it is quite a small application.
[07:02] Kai setup
Kai is installed as a VS Code extension.
When you start, you first create a profile. A profile usually describes where you want to migrate to. I named mine after the target technology, but you can name it however you want.
Inside the profile, you add the target technology. In this case, I added Quarkus and Quarkus 3.
You can also add the source technology. I left it out here.
These labels decide which rules are used during the analysis. I will talk about the rules in more detail later.
That is basically the setup.
[08:34] LLM configuration
If you want to use an LLM, you add your API key.
In this demo, OpenAI is configured as the active default model.
You can also choose other models. As mentioned earlier, you can configure a locally hosted LLM or another model hosted somewhere in your organization, as long as it is reachable and compatible.
That is all there is to the configuration.
[09:43] Running the analysis
Once the profile is created, the first thing you usually do is analyze the codebase.
To do that, you start the Kai RPC server in the background and then run the analysis.
The analysis takes a little time, but not too long.
In the background, Kai uses an analysis engine based on rules.
There are community rules that address common issues and anti-patterns related to certain migration targets.
You can also add custom rules. This will probably be necessary for larger organizations that have a lot of custom implementations.
The rules define which anti-patterns should be found in the codebase.
[11:24] How the analysis works
The analysis engine takes the rules and uses their logic to detect patterns.
This logic is converted into LSP queries, which are then used to analyze the source code and codebase.
After each rule has been checked, every match becomes an incident inside the analysis report.
[12:15] Analysis results
After the analysis finishes, Kai shows the results.
In this example, it found several issues that would not work when migrating to Quarkus.
The issues are grouped into categories such as:
- optional
- mandatory
- potential
Kai also lists every affected file and the exact line in the source code where it identified the anti-pattern.
[12:56] Solving issues
For each issue, there are two main ways to work with Kai.
The first one is the simpler approach.
Kai creates a prompt, sends it to the LLM, and returns a recommendation.
For example, it may remove some code or replace certain annotations.
You can then decide whether the recommendation is correct. You can accept it, reject it, or edit it manually.
If the recommendation looks good, you can apply it.
[14:10] Agent mode
The second option is Agent Mode.
For example, Kai can replace @Stateless with @ApplicationScoped, because @Stateless does not work with Quarkus due to CDI differences.
Kai sends the prompt to the LLM and then proposes changes.
The key difference with Agent Mode is that it can continue working on related issues.
For example, replacing an annotation may require adding a missing dependency to the pom.xml. Otherwise, the source code might not compile.
Agent Mode can detect these additional problems and suggest further changes.
That said, Kai is meant to assist during migration. It is not meant to automatically fix everything while you blindly click “apply.” Humanity remains haunted by the need to review its own code.
Because LLMs are not deterministic, you can accept, reject, or edit the proposed solution.
[20:19] Re-running the analysis
After you accept a solution, the analysis runs again and checks the current codebase.
If something breaks, or if a previously fixed issue appears again, it will show up in the analysis view.
When changes are applied, Kai updates the files and may recommend additional steps.
[21:03] Example rule
The analysis is based on rules.
Rules have labels. When setting up the profile, you add target and source technologies. In this example, I added Quarkus as the target and left out the source technology.
That means every rule with the target label Quarkus is checked.
Rules also define the logic for the anti-pattern they are looking for.
This logic is translated into LSP queries and used to analyze the source code.
When there is a match, an incident or issue is created and shown in the analysis view.
Each rule also contains a message. This message explains the issue in natural language.
That is useful for the person doing the migration, because they can understand the issue directly. The same explanation is also used by the LLM.
[22:48] Prompt example
Here is an example of what the prompt looks like.
Part of it is a system prompt. It describes how the model should behave, for example as an experienced Java developer specialized in code migration.
Then there is the human part, which includes a description and the input file where the issue was found.
The prompt also includes instructions for the expected response.
In this example, the prompt was used for a change where @PersistenceContext was removed and @Produces was replaced with @Named, if I remember correctly.
[24:28] Analysis report as JSON
Every time Kai performs an analysis, it also creates a JSON report.
In that report, you can see the violations that were found.
Each rule has an ID, and the corresponding violation references that ID.
The report includes the exact location, the code snippet, and the message describing the issue.
[25:34] Migration workflow
The workflow is basically this:
You define the anti-patterns you want to search for.
The analysis finds issues based on matching rules.
Then you solve the issues one by one.
You do not have to solve them with the LLM, but if the LLM is available, you can try the suggestion.
If the solution is good, you accept it.
Issue by issue, you move closer to your target technology.
[26:20] Experience with Kai
Based on the analysis, the start felt very easy.
Before looking into Konveyor and Konveyor AI, we read about the challenges we would face when migrating to Quarkus.
Most of those challenges were also found by the analysis. This is partly because the application was quite small, but it still showed that many relevant cases were already covered by the community rules.
Still, the person doing the migration needs technical knowledge.
You cannot just sit in front of the tool and click “yes, yes, apply, apply.” That is not how this works, unless your migration strategy is “hope with a UI.”
What I liked is that the rules and explanations are written in natural language.
The LLM uses these explanations, and the migrator can also read them to understand the issue and judge whether the proposed solution is correct or needs editing.
One limitation is that LLMs are not deterministic. That is not really a Kai issue, but an LLM issue.
There are still minor issues and bugs, but nothing too serious. Usually, it is easy to stop and restart the tool, and then you get the same analysis again.
We also noticed that Kai is under very active development.
During the Learning Friday project, the version went from around 0.2 to 0.8 within a few months. While we were finishing the presentation, the UI had already improved significantly compared to when we started working with it.
[29:19] Future plans
For us, it would be interesting to see how the Konveyor Hub and Kai work together.
We also want to try the Solution Server, which stores already solved issues.
There is probably a bigger picture than the individual migrator perspective shown in this demo.
In larger organizations, multiple applications often have similar architecture. That is where the Hub could become useful for analyzing and managing several applications.
We also want to try Kai on a much larger codebase, with around one million lines of code.
So far, we have not tested that yet. It will be interesting to see how Kai behaves with a much larger application.
For example, in this demo one issue affected seven files. But what happens when one issue affects 100 files or more? That is something we still want to find out.
That summarizes our experience and how Kai works.
Q&A
[31:35] Question: Can Kai run verification steps or tests?
Question:
You showed how the semantic approach works. Is there also a way to point Kai to an actual verification step, such as a test suite, that it can run against the migrated code?
For example, if Kai changes code and relevant tests have already been migrated, can it check whether everything still works?
Answer:
Kai itself uses diagnostics from the IDE to identify certain mistakes, such as potential compile issues.
But as far as I know, it does not currently run the full application or execute tests after every code change.
For example, it does not automatically run unit tests whenever it changes code in a folder.
So the answer is: not yet.
There is a page on the Konveyor GitHub page where future plans are tracked. The project is very active, so this may change.
Konveyor itself is not completely new. It was previously called Migration Toolkit for Applications, or MTA.
With the rise of LLMs, the project has been pushed further.
Konveyor is the upstream project for MTA. Red Hat also has Kai under the name Developer Lightspeed. Red Hat is currently one of the biggest contributors to the project.
[35:09] Question: Are Java and .NET the main languages?
Question:
Are the main languages Java and .NET, based on what I saw in the Git repository? Or is there anything else that makes sense for modernization?
Answer:
I have only worked with Java.
I have heard about .NET, but I do not know whether it works as well as Java.
There are rules for .NET analysis.
In principle, the LLM should be able to work with different languages.
The rule engine itself is language-independent, so it should theoretically work for many technologies. But the community rules are currently more focused on certain ecosystems, especially Java and .NET.
That also makes sense, considering Konveyor comes from the Red Hat ecosystem and is focused on modernizing applications and bringing them to Kubernetes or OpenShift.
[36:24] Question: Can Kai migrate between languages?
Question:
Does this tool support migrations not only between versions or frameworks within one language, but also from one language to another? For example, from Java to Node.js, or from old COBOL code to Python?
Answer:
I am not aware of that.
I do not want to say no with complete certainty, but I do not think that is currently the focus.
For this kind of migration, it would make sense to migrate the unit tests first, assuming the application has good test coverage, and then migrate the whole application to verify that everything still works.
[37:12] Question: Is the Solution Server shared publicly or company-specific?
Question:
You mentioned the Hub and the server with resolved issues. Is that server provided by the community, or does it belong to the company using it?
Answer:
The Solution Server comes from the community. It is part of Kai and can be used with it.
I have not looked into it deeply yet, but I think it runs on Kubernetes.
You start the Solution Server, and it is used to save information about issues that have already been solved, plus additional metrics.
It is not a Gepardec-specific solution.
Everything discussed here is open source: Kai, the Hub, the Solution Server, and the other components.
[38:30] Closing
Thanks, Aleks. Thanks a lot.
