Analyze monolithic Java applications in multiple workspaces with Red Hat’s migration toolkit for applications

Analyze monolithic Java applications in multiple workspaces with Red Hat’s migration toolkit for applications

Transforming monolithic Java applications into distributed, cloud-native microservices is never easy, but Red Hat’s migration toolkit for applications helps you understand and evaluate the migration path. As a developer, you can apply the following features to a broad range of transformation use cases:

  • Planning and work estimation
  • Identifying migration issues and providing solutions
  • Detailed reporting
  • Built-in rules and migration paths
  • Rule extensibility and customization
  • Source code or application archive analysis

This article guides you through configuring Red Hat’s migration toolkit for applications to analyze an existing monolithic Java application. We will set up our development environment in Red Hat CodeReady Workspaces. After that, I’ll show you how to use the toolkit to analyze migration issues and generate potential solutions.

Note: Migration toolkit for applications is an extensible and customizable rule-based tool that helps simplify Java application migrations. The toolkit has a comprehensive set of cloud- and container-readiness rules to assess applications for Kubernetes deployment. It is available through Red Hat Runtimes.

Install a CodeReady Workspaces Operator

To start, we will create a new project and install a CodeReady Workspaces Operator. Log into an OpenShift 4 cluster with cluster-admin credentials, then use the menu on the console’s left side to navigate to Home > Projects. Click Create Project in the top-right corner of the screen, then create a project. As shown in Figure 1, I’ve named the example project che-test.

The dialog to create a new project in your OpenShift 4 cluster.

Figure 1: Create a new project in your OpenShift 4 cluster.

Navigate to Operators > OperatorHub and type “codeready” in the search box. Select the Red Hat CodeReady Workspaces Operator, as shown in Figure 2.

A screenshot of the OperatorHub, where the CodeReady Workspaces Operator tile is outlined in red.

Figure 2: Install a CodeReady Workspaces Operator from the OpenShift OperatorHub.

Select the che-test namespace, then click Install, as shown in Figure 3.

Under Install Operator, the option to select the 'che-test' namespace is outlined in red.

Figure 3: Select and install the che-test namespace.

Everything you need to grow your career.

With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.


Create a new CheCluster

After you select the che-test namespace, you will be presented with the option to create a new CheCluster, as shown in Figure 4.

Clicking 'Red Hat CodeReady Workspaces' opens the option to create a new CheCluster.

Figure 4: Create a new CheCluster.

Select the YAML view for creating a CheCluster, as shown in Figure 5, then add the following custom Che properties in the server configuration:


These properties allow the CodeReady Workspaces server to create namespaces for any number of user workspaces. Figure 5 shows the server configuration to create the CheCluster with customCheProperties.

Select the YAML view to edit the server configuration file.

Figure 5: Add the custom Che properties to your server configuration.

CodeReady Workspaces will create the number of namespaces required to deploy a CodeReady Workspaces pod for each user workspace.

Install the toolkit’s IDE plug-in

Next, we’ll configure a devfile to install the migration toolkit for applications IDE plug-in. Add the following development component to your CodeReady Workspaces devfile.json:


"alias": "mta-ide-plugin",
"type": "chePlugin",
"reference": "",
"memoryLimit": "1500M"


Note that we are configuring a development environment with multiple users. You can also use the devfile to define the source code, application runtimes, and a list of predefined commands. See the quarkus-quickstarts repository for an example.

Using Keycloak for access

Let’s say that you have created 10 developer credentials with the username (developer1...developer10). The password for each credential is the same as the username in Keycloak. You can use the Keycloak API and access token to create a developer account:

KEYCLOAK_TOKEN=$(curl -s -d "username=<YOUR_KEYCLOAK_ADMIN_USERNAME>&password=<YOUR_KEYCLOAK_ADMIN_PASSWORD>&grant_type=password&client_id=admin-cli" \
-X POST https://keycloak-che-test.<YOUR_ROUTE_SUBDOMAIN>/auth/realms/codeready/protocol/openid-connect/token | \
jq  -r '.access_token')

curl -v -H "Authorization: Bearer ${KEYCLOAK_TOKEN}" -H "Content-Type:application/json" \
-d '{"username":"developer1","enabled":true,"emailVerified": true,"firstName": "developer1","lastName": "Developer","email": "", "credentials":[{"type":"password","value":"developer1","temporary":false}]}' \
-X POST "https://keycloak-che-test.<YOUR_ROUTE_SUBDOMAIN>/auth/admin/realms/codeready/users"

Pre-warm the developer workspaces

Finally, let’s configure the devfile to pre-warm each developer’s workspace. Pre-warming lets us avoid an initial wait to start the workspaces:

for i in $(eval echo "{1..10}") ; do

DEVELOPER_TOKEN=$(curl -s -d "username=developer${i}&password=developer${i}&grant_type=password&client_id=admin-cli" \
-X POST https://keycloak-che-test.<YOUR_ROUTE_SUBDOMAIN>/auth/realms/codeready/protocol/openid-connect/token | \
jq  -r '.access_token')

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' \
--header "Authorization: Bearer ${DEVELOPER_TOKEN}" -d @devfile.json \


Open a workspace in CodeReady Workspaces

Return to the OpenShift developer console and navigate to the userXX-che project, where “XX” is the user number. For example, as shown in Figure 6, you might see a workspace pod running in the user1-che project.

The user1-che workspace in the topology view.

Figure 6: A user workspace in the developer console’s topology view.

Navigate to the che-test project in your developer console, then click a URL to open one of the pods in CodeReady Workspaces, as shown in Figure 7.

The topology view shows the available pods.

Figure 7: Open a pod in CodeReady Workspaces.

When you log in, you will be moved to your personal dashboard. Click the name of the pre-created workspace on the left, as shown in Figure 8.

An arrow points to the pre-created workspace in the left-side menu.

Figure 8: Click the name of the pre-created user workspace.

After a few seconds, you will be moved to the workspace landing page, as shown in Figure 9.

The workspaces landing page includes options to open a new file or update the settings.

Figure 9: The workspace landing page in CodeReady Workspaces.

Configuring migration toolkit for applications

Click the icon labeled “MTA Explorer” in Figure 10, then click the plus (+) icon to add a new migration toolkit for applications configuration.

Arrows indicate the MTA explorer icon and the plus symbol to create a new configuration.

Figure 10: Add a new migration toolkit for applications configuration.

After adding the required configuration elements (such as --input, --source, and --target server), click Run to run an analysis. The toolkit’s command-line interface (CLI) will be executed automatically in a new terminal. After a few minutes, you will see that the analysis is complete. Click Open Report, as shown in Figure 11.

Click 'Open Report' at the bottom of the new terminal window.

Figure 11: Open the migration analysis report.

Next, you’ll see the option to review your migration report, as shown in Figure 12.

Select the option to view the report details. Note that this migration report lists 22 story points.

Figure 12: View the report details.

You might notice that there are 22 story points in this report. A story point is an abstract metric commonly used in agile software development to estimate the effort needed to implement a feature or a change. Red Hat’s migration toolkit for applications uses story points to express the effort involved in migrating particular application constructs and the application as a whole. The level of effort will vary depending on the size and complexity of the application or applications you want to migrate.

What’s next for your transformation path

Analyzing your transformation path with migration toolkit for applications is just the beginning of modernizing a monolithic Java application. As a next step, you could break the application into microservices using cloud-native runtimes such as Quarkus, Spring Boot, and Node.js. With support from Red Hat Runtimes, you can gradually refactor your entire, monolithic application as a set of distributed cloud-native microservices.