Businesses, constantly searching for ways to gain a competitive edge, are looking at their application portfolios to help meet changing business requirements, optimise operations and add new functionality.
When trying to evaluate the next state of an application, you need to do an application rationalisation exercise. In many instances, applications have to be migrated to a new platform to gain new benefits, such as scalability and elasticity. In other instances, replacing an application may make sense to gain new functionality and retire the technical debt.
When an application is selected for migration, it’s evaluated across the 6 Rs — rehost, replatform, refactor, replace, retire, retain. These are the application migration patterns, or dispositions, that describe the way an application will be migrated (or replaced, retained or retired). Besides deciding on the migration pattern, you also need to choose an appropriate target platform to host the application. That can range from public cloud, to private cloud, to another on-premise solution.
There are many articles and blogs that explain common architecture patterns and suitability for a certain platform and what the migration patterns are. In this article, we will expand on how to evaluate suitability, and dig deeper into the 6 Rs to explain the logic of why an application may be more suited to a specific pattern.
What Are Migration Patterns?
When an application is to be moved from its current state, migration patterns describe which components of an application need to change hardware, operating system, platform/stack, application code, architecture). If you are looking at many applications, migration patterns are also a way to group applications into categories according to the areas of change, to make it easier to address the applications collectively.
As a primer, we use the Figure 1 chart to explore what each of the patterns generally mean for an application. If an application is to be migrated from its current state to a new home, various layers of the application may undergo change. For example, a replatform migration pattern will mean that the application is undergoing a change all the way from its current hardware platform to the application and data stack. Examples include:
- From Oracle database on Windows Server to Amazon RDS
- From Java application running on WebLogic to AWS Elastic Beanstalk
The application functionality, configuration, code and underlying architecture will remain unchanged.
Now, let us investigate what determines the desired migration pattern for a specific application.
The Platform Suitability and Migration Pattern Approach
Before looking at all the characteristics of an application and digging deeper to determine suitability and the appropriate pattern, other factors, including general strategy, roadmap and business drivers, play important roles in such decisions.
The general approach we recommend is that businesses conduct a high level assessment first across the application portfolio, develop rationalisation themes and align with the overall strategy which can then be further developed with detailed application assessments based on various factors such as priorities, quick wins etc. We have developed a data model and assessment methodology as part of our Application Assessment and Migration framework that allows for accelerated assessments. This framework defines what data sets are needed at what stage of the assessments, how to capture the relevant information using various sources (CMDB, discovery and dependency mapping tools, code scan software etc.) and how to consume all the information.
Let us look at an example here and explore how we could come to a specific conclusion.
Client A has decided to reduce the data centre footprint and consolidate as part of their general strategy. The roadmap calls for reducing their footprint by 50 percent in three years. As part of the roadmap, one of the data centres is to be shut down, so all assets in that DC need a new home. To achieve the goal in the desired period, the client will need to look at the application landscape and decide what can be done for each of the applications and their assets.
An application assessment using objective analysis will shed light on the suitability of a specific platform and the recommended patterns.
In our assessment we typically run through a set of questions from various company domains, including business units, financial, technical, operational, security, etc. Questions are assigned to domains and topics. Each question is also configured with a range of suitability scores based on potential responses. A client application profile is created that associates all the relevant questions to the profiles. Based on the responses, a total score is then generated that signifies the suitability and the desired pattern. This methodology allows the objective analysis of a set of applications. The level of confidence for a particular outcome is defined by how many questions were answered.
The following is an example of a suitability score for a few domains, with various topics within those domains. In this hypothetical example, the outcome demonstrates that AWS is the most suitable platform for the operational and technical domains. There are other viable options, but they are less suited.
Figure 2 below shows each of the platforms that were considered, and lists their corresponding suitability scores. The higher the score, the more suitable the platform.
Figure 3 below shows the recommended migration patterns for each platform considered. For example, for AWS, the preferred pattern is replatform, but the for the DC consolidation the preferred pattern is rehost. The migration pattern will be different based on the capabilities of the target platform.
Figure 4 below shows all the topics in the corresponding domains that influenced the suitability score. For example, licensing, operating system, database and networking played major roles in determining the suitability and migration pattern for a specific platform.
Without going too much into how an objective assessment is done, let us look at some common reasons for specific migration patterns.
In a rehost migration scenario, the application is moved “as is.” Even though some infrastructure level changes may have to be done due to the underlying platform change, the application does not undergo any changes.
The following are the general criteria for why an application may be a good candidate for a rehost migration pattern when the current infrastructure platform has to change:
- Time constraints associated with alternative options
- Custom off-the-shelf applications — apps that require manual installation and cumbersome configuration due to lack of a deployment package and automation, cannot easily be broken down into individual components or services
- Application in general meets the immediate needs of the business, and there is no need to change any functionality
You can easily argue that such criteria may also call for refactor and/or replace, to break the application into components for easier management, scaling, automation, new features, etc. These are valid options but a rehost is usually considered preferable in the context of cost, effort and duration. It depends on the application’s specific functionality, but it will typically take relatively longer time to refactor an application due to additional coding and testing, as opposed to rehost and replatform.
In our experience, even with rehost migration patterns, it is common to take on minor replatforms of certain components, optimising the application to gain the benefits of the target platform and the migration effort. The most common components that are candidates for replatform are OS, database, batch jobs and load balancers.
An example of a rehost with minor replatform migration is a commercial off-the-shelf (COTS) business intelligence application that was moved to Azure. The application was based on Microsoft Windows Server, IIS/ASP.NET and Microsoft SQL Server. Even though the application was moved “as is” using Azure Recovery Service, we were able to replatform the database layer. The database component was moved to a managed SQL platform to reduce the database administration overhead. In addition, the application gained some benefits by leveraging Azure Traffic Manager and Virtual Machine Scale Sets for load balancing, high availability and auto recovery functionality. In a data centre exit scenario with time constraints, this approach is the most viable option.
In a Replatform migration scenario, the application is moved “as is,” but certain application components will be moved to a different platform. Many components are candidates for replatform, including OS, web and app layers, database, message queuing, batch processing, Java application layer, etc.
The following are the general criteria for why an application may be a good candidate for the replatform migration pattern:
- Custom, traditional three-tier application
- Individual services or components
- Address current challenges on scaling and elasticity due to platform or licensing costs
- Desire to reduce administrative overhead
An example of a replatform migration was moving a traditional Java application to AWS. The application was deployed using the fully managed platform of Elastic Beanstalk. Another use case was migrating a WebLogic-based application to AWS using Apache Tomcat to reduce licensing costs.
In both cases, the application was moved “as is” without any major architecture changes, but the underlying platform was replaced. In this case, all the Java code was directly ported with minor changes.
In a refactor migration scenario, the application is refactored, and generally newer components are used to replace the existing components. In the end, the application should end up providing similar business or end user functionality with many enhancements.
The following are the general criteria for why an application may be a good candidate for the refactor migration pattern.
- Monolithic, legacy, custom in-house developed applications
- Time to market has become a critical factor to being competitive
- Continuous improvements are required to meet ever changing business functionality requirements, and the current application state requires considerable effort to release new improvements
- The current development, integration and release processes are complex, with many interdependencies
A recent example of a refactor effort was migrating a back-end system based on SQL Server Integration Services (SSIS) and Spring Batch jobs. The application was receiving many files, and the files had to be acted upon (zipped, compressed, encrypted, indexed, etc.) and sent to another destination. A refactor of this application was called for in light of the many scalability and performance issues. This app was migrated to AWS using native Platform as a Service components, including Lambda batch, SNS/SQS, Step Functions and CloudWatch. The emphasis here was to use the microservices concept to achieve the required scale and elasticity, and reduce the burden on the client’s business and IT teams.
A Methodical Approach
In taking a methodical approach to objective analysis, the categorisation of the application portfolio into different buckets and associating them with specific migration patterns will accelerate your migration initiatives. The migration patterns will allow you to focus your energy on developing solutions and skills for specific patterns.
Develop a few architecture patterns for each of the relevant migration patterns, and then you can accelerate the migration execution with just minor tweaks for individual applications.
This article was originally published in The Doppler, published by Hewlett-Packard Enterprise. Reprinted with permission.