How do you declare success for a legacy modernization to Azure?
In this chapter, we reviewed several different states that might comprise your current legacy environment. We also reviewed the goals you might have for an Azure solution and the constraints you currently face. Now, it’s time to discuss setting up realistic goals, or possibly multiple steps that might be needed to achieve those goals. The idea here is to have early success so that you can build on it. Legacy modernization projects can seem quite daunting, even when there are few or no technical hurdles that need to be overcome. That is why we believe early success makes the daunting task now look achievable.
To help with this, we believe there are several things you should consider.
Identify the first workload to modernize to Azure
This may sound obvious, but there may be several factors you might want to consider, such as the following:
- Will the first application provide a template for replicating similar applications that use Azure features, such as AKS or ASR? In other words, pick an application that has features in common with other applications you want to modernize. Do not choose a one-off.
- Find an application that can be done in a reasonable time frame and achieve a reasonable ROI. These are great measures of success.
- Be careful not to start with the most difficult application move. This is a recipe for failure.
- Make sure business continuity is a key part of the modernization to Azure process.
- Understand the effect latency might have on modernization. Unacceptable latency is another recipe for failure.
- Make sure that the team responsible for the modernization to Azure has the right training to take the application you choose to Azure.
- Make sure you have the proper testing and validation tools and reports to verify success. This could include the use of Azure tools such as Azure Monitor and Application Insights but may also include third-party analysis and benchmark tools.
Determine if modernization can be a multi-step process
Keep in mind that modernization can be a multiple-step process. For example, if you first need to move from on-premises to Azure, moving an application without changing the language might be a good first step. The second step might be to refactor the legacy language to a modern language. The third step might be creating an Azure-native solution.
While it is possible to move directly to an Azure-native solution, doing so will likely require both architecture and source code changes that will take extra time and require more testing. Also, going straight to an Azure-native implementation may be most successful with smaller application modernizations. This makes the process more manageable.
Establish hybrid and integration requirements
Most legacy applications are not standalone and self-contained. There is usually a need to both integrate and interoperate with other legacy applications or applications already on Azure. This means that a hybrid strategy for integration and interoperability is a key feature for success. In looking at the right application to modernize to Azure, there should be the right balance of hybrid or integration needs, along with the ability to segregate functionally so that things such as latency do not become a big issue. Fortunately, Azure provides tools that make creating a hybrid environment practical. They include the following:
- Azure Data Factory: For data ingestion and transformation
- Logic Apps: For low-code data integration
- Power Apps: To extend hybrid functionality with low-code solutions
- Azure Service Bus: For integration with MQSeries or other message environments
- Azure Event Hubs and Event Stream: To enable hybrid event logic
Establish repeatable processes
As a final thought for this chapter, an initial modernization success should also be a recipe for a repeatable process. While not all applications can be modernized to Azure in the same way, there are probably applications that can be categorized as being similar in their approach to Azure. Success in an initial modernization should provide a temple for other applications to follow.
From our experiences, repeatable processes can be achieved in modernization to Azure by first categorizing the application candidates into approaches that are appreciated for each category. Here are some examples:
- If an application currently meets business needs and requires minimal maintenance, then perhaps a rehost of that application or the use of an emulator would be the best option while keeping the same legacy language. This could provide a template for rehosting to Azure for your legacy estate.
- If an application currently meets business requirements but requires a lot of maintenance to the source code, it might be better to refactor (convert it into another language) to allow non-legacy programmers to maintain the application. This does not mean a complete re-architecture of the application, but it will allow you to maintain the application in a modern language. Any example would be refactoring to either Java or C#.
- Finally, if the application needs an overhaul for both business functionality and deployment. This type of application would be best reimagined as an Azure-native architecture.
A single approach may not be appreciated for all applications you want to modernize to Azure. In this case, you may want to create parallel tracks to achieve the optimal paths to Azure.
Now that we’ve looked at how to leverage a successful modernization project to lead to future successful modernizations, we will summarize this chapter.