AWS Cloud Migration Strategy: Replatform vs Refactor

Migrating systems to the cloud helps codify DevOps best practices via an ecosystem of tools steeped in IT process automation. When it comes to cloud migration, however, it can be challenging to differentiate between replatforming and refactoring. As a result, in this article we’ll examine how the two compare, and when you might favor one approach over the other.

However, before we dive into our analysis, let’s quickly level set. While we are focusing exclusively on two migration approaches here, it should be noted there are several other approaches, which we recommend for infrastructure and workloads that are identified to be of low business value and should be retired, rehosted, or retained as is.

For high business value applications, we recommend that they be relocated to the cloud via refactoring or replatforming. Let’s define what we mean when we talk about these two different approaches to cloud migration:

• Replatforming moves assets to the cloud with a small amount of up-versioning — perhaps using a managed DB offering or the addition of automation enabled auto-scaling — to benefit from cloud infrastructure. Replatforming takes advantage of containers and VMs, only changing application code when needed to use base platform services like Amazon Elasticache, and advanced Amazon EC2 services like autoscaling and ELB. When replatforming, you may also find you use PaaS services like AWS RDS and Amazon SQS.
  
  The Benefit: Replatforming allows workloads to take advantage of base cloud functionality and cost optimization, without the level of resource commitment required for refactoring.
  
  
• Refactoring involves a more advanced process of re-architecting and often re-coding some portion of an existing application to take advantage of cloud-native frameworks and functionality. Organizations that refactor are able to modify their applications and infrastructure to take full advantage of cloud-native features and to maximize operational cost efficiency in the cloud. Most often, refactoring entails changing middleware, and application components to take advantage of cloud-native features and advanced concepts like microservices and serverless.
  
  Application code itself is not refactored, but rather the services composing it. While the application business logic remains the same, the application itself is factored into different tiers and pieces with services, like databases, swapped out for the cloud service equivalent. These advanced platform services can lead to paradigm changes, e.g., moving a monolith to microservices using containers and serverless technologies.
  
  The Benefit: While refactoring requires more time and resources up-front, it ultimately allows applications to maximize the benefits of cloud computing, optimizing cost efficiencies as well.

As you analyze the applications driving value to the business, consider the following key differences and similarities:

While refactoring offers the most robust opportunities, it is also the more resource-intensive of the two approaches. It is recommended that organizations strike the right balance between the potential upside and the required inputs to migrate an application. More to the point, some applications simply aren’t right for one approach or the other. For example, architectural requirements or licensing agreements may preclude a given approach.

Cloud migration motivators
Refactoring is often driven by the business’s need to increase an application’s ability to compete. Whether it be new features, greater scalability or higher performance, the business is driving change that is difficult to achieve without refactoring the app. Remember that these applications are providing direct business value, and if the investment is outweighed by the benefit, then refactoring is the right choice. However, given organizational and application constraints, businesses choose refactoring for a small number of applications — in our experience, about 10%.

When refactoring isn’t a fit, replatforming is often chosen. It can help you achieve tactical benefits, like reducing the amount of time spent managing database instances. Given tight constraints, we see companies opting to replatform 25-40% of their portfolio. In these cases, the burden is on the DevOps team to build a harness for the application, which without requiring major code changes, can provide benefits of cloud features such as auto-scaling, self-healing, containers, etc.

As you migrate more of your applications, your agility will grow, which will open the door for greater innovation. In this way your organization can begin creating a virtuous cycle of innovation that continuously contributes greater value to the business.

*This was originally written by Flux7 Inc., which has become Flux7, an NTT DATA Services Company as of December 30, 2019