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:
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 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:
Such measures reduce the footprint of the estate the organisation has to manage and can streamline ops and support processes.
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.
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 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:
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).
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.
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.