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:
In this post we explore the Replatforming migration method in the same consistent manner as the other three methods using the following outline:
If you want to access the whole series in one sitting, you can go get the Cloudsoft white paper:
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:
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).
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?
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
If you’ve been doing cloud for a while, your experience enables you to take some short cuts.
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 efficiences in migration effort and effectiveness in cloud migration as you go.
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?
A good AWS engineer will know how to replace common application components with AWS services.
Using higher-order services means less management cost, higher availability, costs that match consumption instead of “peak load”.
The configuration is duplicated/improved on a replacement cloud service such as replacing Nginx in a VM with AWS Elastic Load Balancer.
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:
Choosing an inappropriate AWS service to replace a component (e.g. selecting the NoSQL DynamoDB to replace MySQL) or poorly configuring the AWS service.
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.
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.
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.
To do a Replatform, you need a bit more than a Rehost across all the three vectors of budget, tools and timeline.
The budget varies depending on many factors from application complexity to the migrating team’s skill and existing toolset.
Some of these are free, some can be rented, some need professional services to come with them – your mileage may vary!
This is always variable depending on the application, but the time components are normally consistent across migrations:
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.