The current state of legacy applications
As with legacy hardware and operating systems, the current condition of applications that use your legacy estate is important to consider when you move to Azure. Here are the topics we will cover related to the current application estate:
- Scope of the legacy application estate
- Languages used in the current estate
- Third-party (COTS) applications
- Utilities (tools) used
- Operating system services
- Application-specific SLAs
Scope of the legacy application estate
While we recommend that you also do a detailed inventory and tools-based assessment of your legacy source code, there are some general rules of thumb you can use to scope out how to both accelerate modernization to Azure and take advantage of Azure services in the process.
For example, the total number of lines of source code is a good indicator of the effort needed to modernize to Azure. Lines of code are not necessarily a measure of complexity, as source code can often be converted using automated tools. However, lines of code will likely indicate the effort needed to test code once converted to Azure.
Another measure of complexity or effort deals with code interdependency. This is important as modules run independently and can usually be converted separately, thus simplifying the testing process. Otherwise, the interdependent code module will likely need to convert at the same time. For performance and testing, we advise using Azure tools such as Azure Monitor and Application Insights to assist with performance testing.
Another thing to consider is the possibility of unused code in your legacy estate. Many of your legacy applications were written across multiple decades. This means that your application may be full of dead code that is no longer used. Rather than converting and testing the dead code, running code analysis tools to identify code that is never called can accelerate modernization.
Identifying the data associated with an application you want to modernize to Azure is very important. For example, if you modernize the application code to Azure without also moving the associated data for that application, you are likely introducing latency that may not be acceptable to access that data.
Finally, identifying if you have all the source code and the current version is extremely important. A lack of source code will limit the modernization options you have.
Languages used in the current estate
Since legacy systems were developed over decades, there may be some obscure development languages that it might be hard to find cloud versions for or are simply no longer supported. More commonly, however, you will find older languages such as Cobol or PL/I that are not supported with common tools and IDEs in Azure without third-party Independent Software Vendor (ISV) compiler software.
In particular, if your goal is to move to Azure-native managed code solutions for your legacy applications, you may find the need to integrate your managed code (for example, Java or C#) with unmanaged code in C/C++ or other managed executables.
Third-party (COTS) applications
Another possibility is the presence of third-party software in the legacy environment. Since most legacy applications not written in Java or C# (or another managed language) are not compatible with Azure, we need to find whether the third-party ISV provides a version that is compatible with Azure. For example, a commercial off-the-shelf (COTS) application that currently runs on AIX may have a version that runs on x86 Linux. In that case, moving the COTS application to Azure is typically not a technical problem. There may be licensing issues that need to be addressed. But it’s not a technical problem. If that is not the case, you will likely need to find an alternative for the COTS application. In some cases, such as POWER platforms, running the COTS application as-is on Azure might be an option. Otherwise, an alternative application that runs in Azure will need to be found.
Utilities (tools) used by applications
Many applications depend on utilities that provide services by the operating system to function. This includes things such as queuing, transactions, data replication, scheduling, monitoring, backup, and printing. For example, many applications use queuing provided by MQSeries. When moving to Azure, you will need to decide if you wish to continue to use MQ, which is available in Azure, or use a native Azure queuing server such as Service Bus.
We recommend mapping all the utilities currently used by your legacy application with utilities available in Azure. In some cases, these may be native Azure services such as Service Bus, Azure Monitor, and Azure Data Factory. In other cases, third-party tools might be required for things such as printing and virtual tape.
Operating system services
A special type of utility deals with operating system services. This is particularly true for IBM mainframes and midrange. This includes features on the mainframe such as CICS, IMS DC, and Coupling Facility. When we look at these features further, CICS and IMS DC are really like application servers on the mainframe. So, on Azure, we need to look at things such as App Services or Tomcat hosted in Azure Kubernetes Service to provide similar functionality.
On the midrange, the operating system provides tight coupling with the database for applications, and integration with scripting using CL. For this type of functionality, we need to extract these functions from the applications and put them in the database, scripting language, or other utility functions on Azure.
The SLAs provided natively by Azure for virtual machines (VMs) and data solutions will likely meet the availability and recovery requirements for most legacy systems. However, there are some specific cases where that may not be the case.
Applications that were developed by legacy programmers often depend on proprietary features of the operating system to achieve high availability and resilience. An example would be COBOL applications run in a CICSPlex and use Db2 that runs in a Parallel Sysplex. In this type of scenario, the applications themselves are unaware of the underlying system software that provides application resilience and limits data loss. Application redundancy and data resilience in cloud systems such as Azure typically rely on scale-out redundancy to meet similar availability. The scale-out approach usually relies on the application to be able to restart. That logic might not be present in the legacy code being converted.
There are mitigating approaches that can be followed, such as using a caching service such as Redis Cache on Azure. However, either the ISV software being used for the application layer, or the application code itself, would need to be Redis Cache-aware.
Mainframe applications were typically developed as monoliths (single system, not distributed). This section covered the various requirements Azure needs to provide to offer the same type of robustness and features.