Cloud Migration Strategies: 3. Replatform, aka 'lift-and-shape'.

Replatforming, also known as “lift and shape” falls somewhere between rehosting and refactoring. You can benefit from some of the cost and performance benefits of the cloud without going all-in on a full rewrite. 

This post will break down the replatforming method, taking a deeper look at:

• Replatforming explained;
• Drivers for replatforming;
• Benefits of replatforming;
• Risks of replatforming;
• How to replatform.

The information in this blog post comes from our Migration eBook: What everyone needs to know about migrating applications to the cloud. You can get your copy here.

Replatforming explained

Replatforming involves making a few judicious cloud optimisations as part of the migration itself, selectively replacing parts of the stack with managed services where this does not require application code to be rewritten.

Very common examples include:

• Introducing an AWS Elastic Load Balancer in place of software like NGINX or HAProxy.
• Migrating relational data straight to AWS RDS instead of self-hosting database software on EC2 instances.

Such measures reduce the footprint of the estate the organisation has to manage and can streamline ops and support processes.

Drivers for replatforming

When an application is replatformed into the cloud, it is modestly shaped to be more cloud compatible but not completely cloud-native.

The main business benefit of replatforming is taking immediate but modest advantage of the cloud by swapping common components—and therefore benefiting from cost and performance improvements—without the risk, complexity, cost and time of a rewrite.

Replatforming can reduce the cost of the migration programme and the cost of running the application whilst minimising risk, which many business leaders feel is a “sweet spot” for the time required.

Benefits of Relocation

By making some cloud-friendly modifications to the application during migration it is
possible to reduce the risks of the migration by avoiding migrating fragile scripts and
configurations to the cloud. It also means that the application is exploiting cloud benefits from day 1 once it is migrated.

• Not difficult for an AWS expert: a good AWS engineer will know how to replace common application components with AWS services.
• Immediate benefit from some cloud nativeness: using higher-order services means less management cost, higher availability, costs that match consumption instead of “peak load”.
• Reduce the application/configuration copying: the configuration is duplicated/improved on a replacement cloud service such as replacing Nginx in a VM with AWS Application Load Balancer.

Risks of Replatforming

Not having the requisite AWS skills is one of the leading risks of replatforming: replacing “known” self-managed components with poorly understood AWS equivalents. However, there are other ways to get replatforming wrong:

• Insufficient AWS skills: choosing an inappropriate AWS service to replace a component or poorly configuring the AWS service.
• Overly aggressive change: every individual re-shape during replatforming increases the risk of causing problems: be circumspect and choose common, well-known replacements. Avoid exotic changes unless it’s a niche opportunity or unavoidable (e.g. moving from MySQL to no-sql DynamoDB would likely require huge changes to the application code and its operation). The goal is a successful replatform, not an exotic one.
• Not using automation: it is possible to manually replatform an application by clicking around the AWS console and making changes. A better solution is to introduce proper configuration-as-code tooling, such as CloudFormation or Terraform.

How to Replatform

As with all the migration strategies, work closely with all the stakeholders including finance, governance, application teams, operations and security.

Analyse the application to understand its components, dependencies, operational needs and “normal” behaviour including known problems. Map the components to cloud services, such as EC2 instances (for VMs), Application Load Balancers, Web Application Firewall, Relational Database Service (RDS), etc. This requires a good understanding of the cloud services, and how they should be used.

Where managed services are used, update the processes and runbooks accordingly. For example, RDS will manage database backups for you and gives you a mechanism for point-in-time recovery in the event of a failure.

Some VMs may be migrated as-is (see tools listed under rehost). For other VMs, these may be analysed to automate their day-to-day operations. For example, the patching and upgrade processes could be automated with tools like AWS Systems Manager and CodeDeploy. Importantly, changes to application code are kept to a minimum (otherwise the replatform turns into a refactor).

Use Configuration as code (e.g. Terraform or CloudFormation) to provision the application environments. This should include dev, staging and production environments in different AWS accounts (the account separation is important for security, cost allocation, and limiting the blast radius).

Migration Strategies Blog Series

This is post 4 of our Migration Strategies blog series. We're posting new blogs daily, each exploring a different migration strategy in more depth.

You can get a head start by downloading a copy of our Migration eBook: "What everyone needs to know about migrating apps to the cloud", which explores each of these approaches in detail.

Working with a partner like Cloudsoft

For many firms, deep knowledge of cloud platforms is not a core competency central to their mission. For them, the sheer breadth of cloud services and the nuances of different migration approaches can be hard to untangle. In such cases, working with a cloud partner can de-risk the options and accelerate the firm’s cloud adoption strategy.

Cloudsoft partners with organisations at all stages of the cloud journey: lending crucial strategy advice through the assess and mobilise phases, guiding the selection of migration methods for different workloads, and assisting with the technical planning and implementation of the migration itself. Staffed with experienced application developers, we also frequently continue to work with customers post-migration, refactoring and modernising the migrated workloads.