The migration process is cumbersome, to say the least. The root cause for this can be associated with the ambiguity about the differences that may exist between two vantage points (i.e., origin and destination). Hence in the absence of a knowledgeable, tried, and tested roadmap, one simply cannot identify the gaps that are to be bridged while moving from origin to the destination. Same goes for software migration. A software migration process must factor in the changes it expects to undergo while migrating (i.e., downgrading, upgrading, or switching between two different and/or compatible/incompatible versions of the same or different brands). The key to success for such a venture lies in knowing the unknowns alongside their respective impact to its surroundings. Only then can an effective list of changes be identified and implemented.
Recently, I had the opportunity to work on the same lines where few enterprises were looking to move away from an incumbent Java Development Kit (JDK) and Java Runtime Environment (JRE) in favor of the Red Hat build of OpenJDK. JDK and JRE are the most critical components of a Java based IT landscape and can inflict widespread impact to its dependents. While the adapted process during these engagements was specific to Red Hat build of OpenJDK, migration between other JDKs and softwares can also draw inspiration from it.
Inventory list
Like any migration process, the process to migrate to Red Hat build of OpenJDK from any other JDK involves detailed assessment and planning to ensure that all unknowns responsible for causing impact and complexity are identified and dealt with carefully. The assessment process should always start by listing the inventory.
Before migrating, we need to identify every single component that may face an impact, including computers, servers (bare metal and/or virtual machines), workstations (physical or virtual desktops and/or laptops), Java processes (application servers, binary executables, CI/CD pipelines and more importantly the business applications). In terms of business applications, a distinction must be made between the ones developed and maintained in-house or procured from a third-party vendor. The reason for this will be discussed later under Application Migration. Long story short, anything that is impacted by a change in Java version or vendor must be listed as an item to the inventory.
Artifact screening
Human errors are probably the most common factor contributing to a failure. Although inventory is usually documented by someone who knows the whole infrastructure well, still there is a possibility to miss something. This possibility appears more probable for some less frequently utilized or upgraded Java based artifact. To eliminate this, simple automation can be effective. For example, a simple automation process can be developed that scans every single host to locate files of type Jar, War, or Ear. This can be very easily achieved with the help of a commonly available scripting technology like bash, PowerShell or Red Hat Ansible Automation Platform, etc.
Automate Java installation
One of the most critical tasks during JDK/JRE migration is the installation of the binaries for the intended Java version released by the preferred vendor. However, this process is extremely laborious. What makes it complex is the varsity and size associated with the targeted infrastructure. For example, even the infrastructure maintained by small to medium sized enterprises is a handful, let alone the larger enterprises. The reasons for this are multifold. Hardware infrastructure consists of a large number of computers that may run different types of operating systems (i.e., servers usually operate with Linux or Windows whereas workstations can run macOS or Windows).
Additionally, Java is made available for installation in different ways. Some organizations allow direct download, some make it available for installation via an internal marketplace, and some organizations ensure that it is installed while provisioning the workstation. On top of this, different vendors release different packaging like RPM, binary archive, or even a graphical installer.
All these multidimensional facts suggest that each installation task must be handled uniquely. As each host is expected to be migrated to a newer Java brand and/or version individually, the installation process must be capable of successfully repeating itself without failing. Hence, automation using a tool like Ansible Automation Platform is the key to success.
Application migration
Probably the most critical task of JDK/JRE migration is to make in-house and third-party business applications compatible with newer versions and/or brands of Java. As JDK/JRE provide compile time as well as runtime support to these applications, these components are expected to endure the majority of the impact. One can draw comfort from a simple rule, cross vendor migration between competing versions may inflict minimal to no impact at all. However with the wider gaps between two versions, the impact is also expected to be greater considering that implementation may have changed and the libraries, classes, methods, etc. may have been deprecated and/or replaced. Yet we need a better approach to handle this task.
Third-party applications cannot be upgraded or compiled in-house. This is why the vendor(s) should be providing clarity around these applications if they are tested and supported by them with the Java version/brand intended to provide the runtime and/or compile time support. In case there is a need for some patch work or upgrade, it should also be handled by the respective vendor(s).
Contrary to third-party applications, in-house applications are designed, developed, and maintained by the enterprise. These applications must undergo an assessment for the expected impact. Windup or migration toolkit for applications are good tools for this purpose. This will identify the changes needed for successful compilation of the source code to operate with the intended JRE.
Delivery and verification
Now that we have the infrastructure migrated to operate with a newer or different version or brand of Java, development environment alongside CI/CD pipelines are migrated to use intended Java version or brand during development and compilation time. Business applications are refactored alongside unit tests. It is still strongly recommended to verify everything for functional correctness. Once the business applications have passed the verification phase, migration can be deemed successful.
Navigating the software migration process
Even though software migration involves uncertainty, there are methods and tools available to deal with it. What matters is how effectively you utilize these methodologies and technologies.
Last updated: August 30, 2023