The Lift & Shift Problem
I have always been a strong believer that achieving the best results in cloud requires more than a Lift & Shift, or Rehost if you prefer 7 Rs terminology.
For the uninitiated, Lift & Shift is a process of migrating to the cloud where on-premises, colocated or datacentre networks and virtual machines are directly mapped into VPC networks in the cloud with direct migration of existing virtual machines including the OS, software and configuration without any architectural rework or improvements.
Traditionally Lift & Shift has always been seen as the quickest and most cost effective methodology of migrating applications to cloud, however the pitfalls are plentiful:
- Same Problems, New Home – Technical debt and security concerns are not mitigated, moving the problems you have today in colocation / datacentre to the cloud. Teams continue to fight the same fires rather than iterating on the roadmap.
- Rightsizing Rarely Occurs – Resulting in paying a premium in cloud for overprovisioned resources migrated from the datacentre.
- Lack of Architectural Benefit – You don’t benefit from autoscaling, managed service elasticity, resiliency and operational efficiency, or offloading responsibility in the shared responsibility model that consuming cloud platform features provides.
- False Sense of Done – Leadership considers the migration to be complete, the colocation lease is finished and for all purposes you are “in the cloud”, funding dries up and the replatforming that should have followed never happens with a suboptimal end state.
Ultimately Lift & Shift becomes hard to defend over time when the bill is similar, or sometimes higher, but nothing has actually improved.
Potential Solutions
Replatforming offers significant benefits over a lift and shift, the application code and logic doesn’t fundamentally change but the deployment methodology does. Workloads are now deployed via Infrastructure as Code (IaC) to scalable and resilient platforms such as Kubernetes with configuration and secrets securely stored within cloud platform features enabling easily deployed, repeatable environments. On-premise services can be swapped for managed cloud equivalents for example migrating objects stored on NFS mounts to S3 significantly cuts cost, or converting an on-premise Oracle database to an Amazon RDS hosted PostgreSQL instance, reducing operational overhead and licensing fees.
Refactoring performs a deeper modernisation of the workload and varies from a lighter effort which may include quality of life improvement activities such as version bumping runtimes, replacing deprecated functions, upgrading dependencies and rewriting specific business logic to make use of cloud platform features to overcome application weaknesses through to much larger rewrites which significantly modify the code base and application architecture. Example of this may include taking a legacy batch driven solution and rewriting it to be event driven decoupled asynchronous microservices.
Most leadership teams already accept that Replatform or Refactor delivers superior long-term ROI, however these approaches have historically lost out to Lift & Shift for four reasons:
- Engineering effort was too high to justify against tight deadlines.
- Risk of breaking legacy code was unacceptably high for critical business systems.
- Specialised cloud skills were scarce and expensive jeopardising project time lines and budgets.
- Organisational goals are too short term to realise suitable ROI within the required timelines.
These constraints often made Lift & Shift (Rehost) the pragmatic default even when everyone in the room knew it wasn’t the right long term answer.
Why is this possible now?
The tide has turned on Replatform & Refactor migration methodologies due to the advent of agentic AI. With the right tooling, analysis of legacy applications can be reduced from weeks to days, and implementation can be performed in weeks rather than months. During testing, tools such as AWS Transform, which specifically focusses on cloud modernisation or more generic tools such as Claude Code are very proficient in analysing code bases, finding cloud antipatterns, bumping runtimes, refactoring tech debt and deploying to modern platform capabilities such as Kubernetes or serverless. This reduces modernisation time for a modest portfolio of workloads from years to months and without pushing the limits of the team. The old excuses of breaking even from a TCO perspective being too long, or the associated risk being too high is now a much mitigated factor.
Exceptional Circumstances
There are a few occasions when a Lift & Shift may still be acceptable in my opinion, but generally speaking applications destined for cloud should only be considered as a last resort;
- Legacy software that is soon to be retired – If you are likely to retire an application within the next 12 months it may be permissible to lift and shift it as the engineering effort to refactor or replatform may not break even and the benefits cannot be realised long term.
- Colocation or datacentre lease renewal is tomorrow – If your datacentre or colocation lease is due for renewal in the very near future, even with the accelerated delivery of generative AI, you may still not land in the cloud in time with a replatform or refactor. Typically short term extensions to datacentre leases are punitively expensive, in this case it may be permissible to lift and shift into cloud providing it is seen as a stepping stone and a longer term cloud native modernisation is the ultimate goal.
TLDR
Lift & Shift is probably the worst cloud migration strategy as it moves all of your existing problems from the datacentre to the cloud and often doesn’t result in the much promised cost efficiencies. In the age of agentic AI it is practical for teams to perform more effective modernisation techniques including Replatform and Refactor realising the benefits of consuming cloud platform features without the long timelines and expense typically associated to these methods.