Red Hat Migration Toolkit for Applications featured image

As a developer, you have probably experimented with Kubernetes. It's also possible that you are already running several Java applications on a Kubernetes platform, maybe Red Hat OpenShift. These initial containerized applications were greenfield projects, where you enjoyed the benefits of a platform providing templated deployments, easy rollbacks, resource availability, security by default, and a manageable way to publish your services.

Now, you might be thinking, "How can I enjoy all of these benefits in my existing Java applications?" Most Java applications in production today are running on virtual machines (VMs), likely on an application platform that is not container friendly. So, how can you migrate them from the current platform to containers on Kubernetes?

It isn't an easy task, but this is a problem that we have been working hard on for years. Red Hat's Migration Toolkit for Applications (MTA) 5.0 is the latest resulting iteration: An assembly of tools that you can use to analyze existing applications and discover what is required to modernize them. Read on to learn MTA 5.0's features and migration paths.

Modernize your application portfolio

Red Hat engineers, architects, and consultants have spent years capturing the lessons learned from re-platforming a large set of applications. We translated what we learned from these Java migration challenges into migration rules, and then developed a toolkit (starting with an open source project called Windup, which we later released as Red Hat Application Migration Toolkit) to help automate the process of analyzing application migrations and making them repeatable. With that toolkit, you can discover issues before you even begin a migration.

Now, we've entered a new stage in the evolution of enterprise application migration. We're focusing on containerized workloads while keeping all of the valuable lessons we've learned so far. Red Hat's Migration Toolkit for Applications (MTA) 5.0 is the next iteration: An assembly of tools that you can use to analyze existing applications and discover what is required to modernize them.

Potential MTA migration paths include:

Migration Toolkit for Applications 5.0

Migration Toolkit for Applications 5.0 is now generally available to every developer who needs an easier way to modernize and migrate Java applications. MTA is free of charge, and there are five different ways to use it:

  • WebUI: A user interface that you can run in a laptop or deploy on OpenShift 3.11 or 4.x.
  • Command-line interface (CLI): Most useful for analyzing massive amounts of applications, as well as embedding MTA into current CI/CD pipelines.
  • IDE plug-ins:
  • Maven plug-in: Use the Maven plug-in to analyze applications during build time.

Figure 1 shows the MTA 5.0 console with supported applications labeled.

Figure 1: The MTA 5.0 console showing supported applications.

Note: For more information about how developers and architects use the various components, see the MTA 5.0 product page.

Many migration paths

Migration Toolkit for Applications 5.0 supports a broad set of transformation paths, with rules for the following cases:

  • Apache Camel 2 to Camel 3: MTA 5.0 contains new rules to help developers updating their applications use the latest version of Apache Camel 3, with 13 rulesets and 147 rules. Figure 2 shows a rule specific to the Camel 2 to Camel 3 migration. (Special thanks to Matej Melko and John Poth for their contributions to these rules.)
Figure 2: A rule specific to the Camel 2 to Camel 3 migration.
  • Spring Boot to Quarkus: We've seeded three new rules for migrating from Spring Boot to Quarkus. For the upcoming MTA 5.1 version, we plan to add a set of 28 rules. Fourteen rules have already been built, two are in progress, and 12 are in the pipeline. Figure 3 shows a rule for replacing the Spring Shell dependency with the appropriate Quarkus PicoCli interfaces.
Figure 3: A Spring Boot-to-Quarkus migration rule.
  • JBoss EAP: We have added a comprehensive set of rules to ensure that migrated applications comply with Java/Jakarta Enterprise Edition (JEE) standards, which is a requirement for working on JBoss EAP. As shown in Figure 4, an issue is raised when using the WebLogic-specific logger, which provides advice for using the standard Java logger.
Figure 4: Choose the correct logger for your migration.
  • Containers: We have added rules that are based on the Twelve- Factor App methodology for containerizing applications. Figure 5 shows a rule against using Java RMI.
Figure 5: Java RMI should be avoided in cloud environments.
  • Linux: We've added rules to help you avoid issues specific to using Java on Windows. One such rule, shown in Figure 6, calls for replacing a Windows filesystem path with a Linux-style path.
Figure 7: Consider replacing Java 2D with the OpenJDK Java 2D library.
  • OpenJDK: This rule helps you avoid problems coming from using specific proprietary libraries that are not in the JDK, such as the Java 2D library (shown in Figure 7).
Figure 7: Consider replacing Java 2D with the OpenJDK Java 2D library.

Note: See the complete matrix of transformations and combinations that are made easier by MTA 5.0.

Get started with MTA 5.0

Go here to download Migration Toolkit for Applications. The Getting started guide gets you up and running with MTA 5.0 in five minutes.

If you want to learn more about the real-world experience of using MTA to modernize and migrate your Java applications, check out this video: How architects and developers use MTA. For a more in-depth introduction, see the Migration Toolkit for Applications video demo.

You might also want to take a look at the MTA 5.0 documentation to find out how to make the most of MTA. As an example, you can use the documentation to learn how to write your own migration rules.

Follow us @MTAbyRedHat to stay up to date and engage directly with our team. We are looking forward to seeing your apps at the next level!

Last updated: October 28, 2020