Skip to content
Technical

Migrating to AWS Method 3 - Replatforming, aka Lift-and-Shape

Cloudsoft

Replatforming is halfway between Rehosting and Refactoring. It gives some immediate and modest cloud benefits without too much change and risk.

This is the fourth in a five-part series covering the practical realities of migrating applications to AWS:

  • Part 1 – A Practical Guide to Understanding the 6Rs for Migrating to AWS
  • Part 2 – Migrating to AWS Method 1 – Repurchasing, aka Drop-and-Shop
  • Part 3 – Migrating to AWS Method 2 – Rehosting, aka Lift-and-Shift
  • Part 4 – Migrating to AWS Method 3 – Replatforming, aka Lift-and-Shape
  • Part 5 – Migrating to AWS Method 4 – Refactoring, aka Cloud Native

In this post we explore the Replatforming migration method in the same consistent manner as the other three methods using the following outline:

  1. Defining what Replatforming is
  2. Drivers of Replatforming
  3. Benefits of Replatforming
  4. Risks of Replatforming
  5. How to Replatform
  6. What you need to Replatform
  7. Replatforming Summary and Next Steps

If you want to access the whole series in one sitting, you can go get the Cloudsoft white paper:

Everything you need to know about Migrating Applications to AWS

1 Defining Replatforming

Replatforming involves making a few cloud optimizations during migration -- shaping the application towards being cloud-native.

For example, cloud load balancers can be immediately swapped in to replace in-VM load-balancers during migration to reduce the number of virtual machines, configurations and operational processes to be migrated without changing the application. This is also the first iteration in evolving an application towards cloud-native.

To do Replatforming you need to know more about the cloud and more about the application than when Replatforming: you need to know more about what's inside the virtual machine. That is, you need to know more about the application, but you don't need to be a programmer necessarily. If you can wire stuff together like a web app to a database, typical sysadmin stuff, then you can probably do Replatforming:

  • Can you understand how a load-balancer works with a web server and make the connection, wire them together?
  • Can you understand how an application connects to a database, and wire them together?

For example, a common “shaping” activity during Replatforming is to just move your data and not your database to the cloud, and instead "migrate" to a managed relational database service such as Amazon Relational Database Service (RDS).

2 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 --- half-way between Rehost and Refactor.

But why do people choose Replatforming?

2.1 People have tried Rehosting, and realise its shortcomings

After migrating an application via Rehosting, there is work to do to make it exploit the cloud. Why not just improve Rehosting by making these changes as we go? That's an evolution towards Replatforming

2.2 People have learned more cloud skills, and can confidently shape

If you've been doing cloud for a while, your experience enables you to take some short cuts.

2.3 Most apps are common three-tier web apps, so common shaping

Most apps are three-tier web, app, database with load balancers and firewalls and caching and things like that. Once you've reshaped one, you can leverage this across a wide range and make significant efficiencies in migration effort and effectiveness in cloud migration as you go.

3 Benefits of Replatforming

The main business benefit of Replatforming is taking immediate, but modest, advantage of cloud by swapping common components -- and therefore benefiting from cost and performance improvements -- and improving on Rehosting without the risk, complexity, cost and time of a full Refactor.

Replatforming can reduce the cost of the migration programme and the cost of running the application while minimizing risk, which business leaders feel is a sweetspot and “we’re not betting the farm”.

As an example, a typical three-tier application that includes a load-balancer in a VM and a database layer in a VM can be adjusted to swap the load-balancer VM for an AWS managed load balancer, and the database VM for AWS managed Relational Database Service.

But what are the benefits of Replatforming?

3.1 Not difficult for an AWS expert

A good AWS engineer will know how to replace common application components with AWS services.

3.2 Immediate benefit from some cloud nativeness

Using higher-order services means less management cost, higher availability, costs that match consumption instead of “peak load”.

3.3 Reduce the application/ data copying

The configuration is duplicated/improved on a replacement cloud service such as replacing Nginx in a VM with AWS Elastic Load Balancer.

4 Risks of Replatforming

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

4.1 None/Low/Poor AWS Skills

Choosing an inappropriate AWS service to replace a component (e.g. selecting the NoSQL DynamoDB to replace MySQL) or poorly configuring the AWS service.

4.2 Overly aggressive change

Every individual shape during Replatforming increases the risk of causing problems: be circumspect and choose common, well-known shapings. Avoid exotic changes unless it’s a niche opportunity or unavoidable. The goal is a successful Replatform, not an exotic one.

4.3 Not using automation

It is possible to hand-craft Replatform an application, by clicking around the GUI and manually making changes and copies. A better answer is to model the application needs using an automation platform, and then make modifications to the model to represent the Replatform shapings.

5 How to Replatform

It is possible to manually Replatform an application to AWS but the best method is to use an application modelling technique that can describe the application as code, making adjustments transparent and testable to increase speed while reducing risk and effort.

  1. Analyse the application, understanding its components, dependencies, operational needs and “normal” behaviour including known problems.
  2. Model the application using a blueprinting technology that captures the components, their configurations and integrations with each other.
  3. Leverage the AWS Well Architected Framework as part of the migration, which is a great help to make sure the application is aligned with best practices such as security, cost and operations: what is possible/aligned now, and what can be done later in the cloud?
  4. Shape a limited selection of the components to leverage cloud services such as AWS Load Balancer and Relational Database Services, as well as reducing potential issues by replacing brittle scripts by more automation or managed services.
  5. Deploy the modelled application including data migration (usually from a test system) to an AWS account.
  6. Test the deployed application, make adjustments.
  7. Transition including network changes, data migration and, operations onboarding.

6 What you need to Replatform

To do a Replatform, you need a bit more than a Rehost across all the three vectors of budget, tools and timeline.

6.1 Budget

The budget varies depending on many factors from application complexity to the migrating team's skill and existing toolset.

  • Tool costs (free from AWS), add any specialist application modelling software such as Cloudsoft AMP Data moving costs (free to ingest in AWS, but you might incur bandwidth or other transport costs)
  • Labour costs - need someone who understands more than just virtualization and IaaS. Requires someone qualified at AWS Professional level and experienced/expert at AWS services. May have to exceed the budget of £500-£800/day in the UK for an independent freelancer, and a qualified Partner may cost more (and do more) - or they can be cheaper!
  • Estimate AWS costs before Replatforming with AWS Simple Calculator

6.2 Tools

Some of these are free, some can be rented, some need professional services to come with them - your mileage may vary!

6.3 Timeline

This is always variable depending on the application, but the time components are normally consistent across migrations:

  • Time to set up and prepare the target AWS account ready for Replatforming
  • Time to model the application using the automation software.
  • Time to copy some application components and data to AWS
  • Time to verify the migrated applications and data
  • Time to configure the replacement AWS services like ELB or RDS. Time to deploy automated stacks and refine them
  • Testing and Transition

7 Summary of Replatforming and Next Steps

Replatforming is not only a natural evolution, through experience and skill, of Rehosting: it also gives faster business benefits by adopting cloud services during migration. It can lead to Refactoring of application components to exploit more cloud services, but often Replatforming specialists are not programmers so this is as cloud-native as they get.

Related Posts