Application migration and modernization is a daunting task. Not only do you have to update legacy applications with newer libraries and APIs, but often must also address new frameworks, infrastructures, and architectures all while simultaneously keeping resources dedicated to new features and versions.
Red Hat Application Migration Toolkit (RHAMT), formerly Windup, provides a series of utilities for easing this process. Applications can be analyzed through a CLI, a web-based interface, or directly inside Eclipse, allowing immediate modification of the source code.
Choosing the Right Distribution
You’ve read the introduction, possibly seen a video, and are eager to run your first application through the process. Where do you begin?
RHAMT provides a number of different distributions to meet your needs, and all include detailed reports that highlight migration issues with effort estimation. Each of these is summarized below.
CLI Download - Product Documentation
The CLI is a command-line tool, typically used by advanced users with highly customized needs. It allows you to finely tune the RHAMT analysis options or to integrate with external automation tools.
Web Console Download - Product Documentation
The web console is a web-based system that allows a team of users to assess and prioritize migration and modernization efforts. In addition, applications can be grouped into projects for analysis.
Eclipse Plugin Download - Product Documentation
The Eclipse plugin provides assistance directly in Eclipse and Red Hat JBoss Developer Studio, and allows developers to see migration issues directly in the source code. The Eclipse plugin also provides guidance on resolving issues, and offers automatic code replacement where possible.
Start by choosing the distribution that fits your needs best. Follow the download link, and then examine the first few chapters in the appropriate guide to install and run the tool.
Analyzing an Application
You have a local installation of RHAMT, located at RHAMT_HOME, and an application you want to analyze. For the purposes of this blog, we’ll assume that you chose the CLI. With that out of the way, let’s get started!
The analysis is performed by calling `rhamt` and passing it in the application along with any desired options, as seen in the following example.
|$ bin/rhamt-cli --sourceMode --input /path/to/source_folder/ --output /path/to/output_folder/ --target eap7
|Source Code Application Migration
The options are straightforward:
- --sourceMode - indicates the input files are source files instead of compiled binaries
- --input - path to the file or directory containing the files to be analyzed
- --output - path to the directory to contain the reports
- --target - technology to migrate to; used to determine the rules for the analysis
Once the analysis finishes, a message will be seen in the console indicating the path to the report.
|Report created: /path/to/output_folder/index.html
Access it at this URL: file:///path/to/output_folder/index.html
|Output of CLI Analysis
While RHAMT contains a number of rules for common middleware platforms, it also allows you to define a set of custom rules which can be used to identify components or libraries that are not covered by the base ruleset.
Rules are defined in XML, using the following pattern:
|Rule Definition Pattern
Let’s take a look at an actual rule. Assuming there’s an annotation `ProprietaryServlet` that should be flagged, we can create a rule that identifies this annotation and instead references the main `WebServlet` annotation in the standard javadocs. In this case, we only define the `when(condition)` and `perform(action)`.
This ruleset looks for the class-loading element in a jboss-web.xml file, which is no longer valid in JBoss EAP 8
<sourceTechnology id="eap" versionRange="(4,5)"/>
<targetTechnology id="eap" versionRange="[6,)"/>
<javaclass references="com.example.proprietary.servlet.annotation.ProprietaryServlet" as="default">
<hint title="Proprietary Servlet annotation" effort="1">
<message>Replace the proprietary @ProprietaryServlet annotation with the Java EE 6 standard @WebServlet annotation.</message>
<hint title="Standard Java EE 8 annotations">
<message>See the javax.servlet.annotation JavaDoc for more information.</message>
title="Java EE 8 Servlet annotation package summary" />
|Sample RHAMT Rule
Save the rule as `sample.rhamt.xml`, then copy it into the `RHAMT_HOME/rules/` directory. The next time RHAMT Is executed this rule will be evaluated, and any hints will be included in the generated report.
The above highlights including a simple rule into your installation. For full instructions on rule creation examine the Rules Development Guide.
Just Lifting and Shifting?
Lifting and shifting, or rehosting, an application is the first step in migrating it. This process involves moving the application onto a different framework or infrastructure. A common end goal of this stage is to make the smallest number of changes to have the application running successfully in a cloud environment.
Once the application is successfully running in the cloud, the next step is to modernize the application so that it’s natively designed for a cloud environment. Instead of simply rehosting the application, this step involves redesigning it, moving unnecessary dependencies and libraries outside the application.
Regardless of which step you’re at, RHAMT assists with both of these steps by providing a set of cloud-ready rules. Once executed against the application, a detailed report is created that indicates what changes should be made. For anyone familiar with using RHAMT to migrate middleware platforms, the process is similar - examine the report and adjust your application based on the feedback.
It’s that simple.
Wherever you are in the migration process, I’d recommend looking at RHAMT. It’s extremely simple to set up, and comes with a number of default rules to assist in any part of the migration and modernization process.