Lift and shift: when moving as-is pays off, and when it doesn’t
Lift and shift is usually the first idea on the table when a deadline forces your hand. Your data centre lease ends next year, or a hardware refresh is due, and nobody wants to sign the cheque. Moving applications to the cloud unchanged sounds like the quickest, least painful option, and for many workloads it is. Rehosting can get you out of a data centre or off ageing hardware faster than any other route.
Unchanged also means your servers arrive in the cloud with their oversizing, their licence terms and their security assumptions.
This guide covers what lift and shift is, when it suits your business, when it doesn’t, and what to check before the migration starts.
What is lift and shift?
Lift and shift, also called rehosting, is a cloud migration strategy where you move existing applications, their data, and usually their operating systems to the cloud with minimal changes to code or architecture. The aim is to preserve its behaviour while changing the infrastructure underneath it.
In practice, a lift and shift migration copies virtual machines, operating systems, application binaries, configuration and data from on-premises servers to a cloud platform. The hardware, the network, and the people who look after the physical infrastructure all change. In cloud computing terms, this is an infrastructure-as-a-service (IaaS) move. You rent compute, storage and networking from a provider and keep running your own stack on top.
Cloud migration planning commonly uses seven strategies, known as the 7 Rs, and rehost is one of them. Its closest relatives are relocate, which moves whole virtualised environments at the hypervisor level, and replatform, sometimes called “lift, tinker, and shift”, which adds a few targeted improvements along the way. Rehosting changes the least of the three. There is no redesign, and the application itself is barely touched.
The source doesn’t have to be your own server room. You can also rehost workloads that currently run with another provider. In either case, you need to test how the application behaves with the new networking, storage, and access controls.
Other meanings of the term
The phrase “lift and shift” describes moving something to a new place while keeping it largely as it is. In IT, it usually refers to applications moving to cloud infrastructure, but teams use the term for other kinds of projects too.
- In outsourcing, it means handing a business process to a new provider exactly as it runs today, and redesigning it only once the new team is settled.
- In content management system (CMS) projects, it means moving pages and assets to a new platform without restructuring, retagging, or pruning them first.
- In data warehousing, it describes a data migration that takes schemas and jobs to a cloud data platform as they are.
These projects often have a deadline that leaves limited time for improvements. Moving the existing setup can make the work more manageable, provided the team also agrees which issues can wait. If later changes are part of the plan, they need time and funding of their own; otherwise, the old problems can remain long after the migration is finished.
When lift and shift is the right call
Rehosting is often chosen when a deadline leaves little room for application changes. It can also suit software that is stable or difficult to modify.
- Urgent business deadlines. Data centre exits, expiring colocation contracts and end-of-life hardware come with fixed dates. Rehosting is one of the fastest strategies available, so it’s often the only one that fits the calendar.
- Avoiding a hardware refresh. Moving off ageing servers can spare you a capital purchase and the next refresh cycle after it.
- Applications you can’t or shouldn’t change. Off-the-shelf software and stable legacy applications are often safer to move as they are than to rewrite.
- A first step. Many companies migrate first and modernise later. Applications are often easier to optimise once they run in the cloud, where managed services are a configuration change away.
With few code changes, there is less development work to test and users can keep working with familiar software. Migration tools can copy running workloads and keep them synchronised until cutover. The final interruption depends on the application and the cutover method.
Retiring owned hardware can reduce spending on power, cooling, space and maintenance. Your team also stops procuring, racking and repairing those servers. Whether the overall bill falls depends on the resources you rent, the licences you need, and how the applications use them.
For larger estates, automated replication helps teams repeat the process across migration waves. Each workload still needs its own dependency checks and testing.
When lift and shift will cost you
Lift and shift is fast because it doesn’t fix anything. Technical limitations and technical debt travel to the cloud with the workload. Bain warns that like-for-like moves risk “merely transferring their existing inefficiencies to a new location”. If an application’s problems are the reason you’re moving, rehosting just relocates them.
Watch for these red flags:
| Red flag | Why it hurts | Consider instead |
| The application already struggles with performance or scaling | A bigger virtual machine doesn’t remove a bottleneck in the architecture | Re-platforming or re-architecture |
| Steady 24/7 load on servers sized for peak demand | You pay for peak capacity every hour of every day | Right-size first, or retain for now |
| Per-core or hardware-tied licences | Cloud licence counting can multiply what you pay | Review licensing before you commit |
| Chatty dependencies that stay on-premises | Every call crosses the network, adding latency and data transfer charges | Move dependent systems together |
| Unsupported or end-of-life operating system | Security debt follows you into a new environment | Replatform onto a supported version |
| Strict compliance requirements or data residency rules | The target region or service may not meet them | Retain, or choose a compliant or sovereign target |
| Modernisation planned within a year | You pay for two migrations instead of one | Replatform or refactor now |
Even when none of these apply, a rehosted workload won’t use cloud-native features such as autoscaling, managed databases, or serverless computing. Software built for on-premises hardware often runs inefficiently in the cloud, and the newest cloud services stay out of reach until the application changes. Better performance and new features come from cloud-native architecture, not from a new host.
That’s why analysts are cautious. Gartner has noted that pure rehosting hasn’t historically delivered positive returns and recommends a “lift and optimise” approach where feasible. With rehosting, the trap isn’t migration complexity but simplicity: even a complex migration that changes nothing can’t improve anything.
What lift and shift costs to run
Rehosting can be relatively inexpensive to carry out, then cost more than expected to run. Estimate the migration project and ongoing operations separately.
Know what you’re taking to the cloud
Learn more
Where the extra cost comes from
Several things add to the bill.
- Overprovisioning. On-premises servers are sized for peak demand plus headroom. A Bain analysis of more than 60,000 workloads found that 84% were overprovisioned, and that like-for-like moves can cost 10 to 15% more than staying put. The analysis dates from 2018, but the logic still holds.
- Always-on billing. Development and test environments sat idle on hardware you had already paid for. In the cloud, they cost money every hour.
- Data transfer. When dependent systems stay behind, traffic between the two environments adds charges.
- Dual running. You pay for both environments while the migration is under way.
- Operational overhead. Monitoring, backup and security tooling that came bundled with your old setup may now be separate line items.
- Licences. The next section covers these.
In Flexera’s 2026 State of the Cloud Report, respondents estimated that 29% of their cloud spend is wasted, the first rise in five years.
Getting the saving you planned for
Lift and shift can cut costs if you plan the saving before the move:
- Baseline your current total cost of ownership (TCO): hardware, power, space, licences and people.
- Right-size cloud targets from actual utilisation metrics rather than current server specifications.
- Price steady workloads with reserved or committed-use discounts, and leave variable ones on demand.
- Include the dual-running period in the business case.
- Review the first few bills soon after cutover and adjust.
Teams that skip this planning often find the expected savings never show up.
Check your licences before you pick a date
The application can move unchanged. Your licence terms may not.
- Microsoft. Since 1 October 2019, licences bought without Software Assurance and License Mobility can’t be brought to “Listed Providers”, a group that covers the other major public clouds. Windows Server is the main casualty, and on those clouds you’ll often pay for a provider-included licence instead. Azure Hybrid Benefit lets you reuse eligible licences on Microsoft’s own cloud.
- Oracle. Under Oracle’s policy for authorised cloud environments, two virtual CPUs (vCPUs) count as one processor licence when multi-threading is enabled. The policy sits outside your contract, and Oracle can change it.
- VMware by Broadcom. At the time of writing, hyperscalers no longer resell bundled VMware licences, so you license VMware Cloud Foundation directly and bring it with you.
- Specialist software. Licences tied to a host ID, a MAC address, or a hardware dongle can stop working the moment the server changes.
Record licence details during discovery and involve procurement early. If proprietary infrastructure licensing is a reason for moving, consider whether an open-source platform would suit the workloads. Application licences and support costs still need separate assessment.
Lift and shift security: what moves with the workload
Existing vulnerabilities need attention before the move. Rehosting leaves patching and application security work with your team.
In a typical IaaS deployment, the provider secures the physical infrastructure and the virtualisation layer. Your operating systems, applications, identities, and data stay your responsibility, as they were before. Unpatched servers, hard-coded credentials, and service accounts with far broader permissions than they need still need to be addressed. Review identity and network controls for the target environment: a misconfiguration can expose a service to the internet or prevent an application from reaching a dependency at cutover.
Build a secure foundation before you migrate the first workload. It’s often called a landing zone, and it sets the baseline for account structure, access management, network design, and logging.
Before cutover, patch and scan every server you plan to move, apply least-privilege access management, translate firewall rules into cloud network rules, and encrypt data in transit and at rest. After cutover, check your security posture against the baseline, test backup restores and validate the migrated data, and review who has access. Remove whatever isn’t needed.
Compliance deserves the same attention. Choose regions deliberately and confirm where data and backups actually live. If sovereignty matters to you, NoviArc runs on the European infrastructure you choose, and you’ll get help selecting a provider if you haven’t picked one yet.
Lift and shift vs replatform vs refactor
Rehosting is one point on a spectrum. Replatforming changes targeted components, such as moving a database to a managed service. Re-architecting, or refactoring, redesigns the application itself, often around microservices or a serverless architecture. The table compares the three in relative terms.
| Lift and shift (rehost) | Re-platforming | Re-architect or refactor | |
| What changes | Infrastructure only | Targeted components, such as managed databases | Application architecture |
| Speed | Fastest of the three | Medium | Slowest |
| Upfront effort | Lowest | Medium | Highest |
| Ongoing cost efficiency | Depends on right-sizing | Usually better | Potentially best |
| Cloud-native benefit | Limited | Some | Substantial |
Most portfolios use all three: rehost the bulk, replatform the obvious candidates, and refactor only the few applications that set the business apart.
A lift and shift migration, step by step
A lift and shift migration needs less design work than other strategies, but just as much planning. The process usually runs like this:
- Discovery. Inventory every workload and identify your lift and shift candidates. This usually happens during the initial portfolio assessment, before any migration waves are planned.
- Dependency mapping. Find out what talks to what, so dependent systems move in the same wave, and nothing breaks halfway.
- A secure foundation. Accounts, networking, identity, and logging go in before any workload does.
- Database planning. Databases are often the riskiest part, because downtime and data integrity leave the least room for error. Agree the cutover window early, and validate the data before and after the switch.
- Automated replication. Migration tooling copies workloads while they’re still running, which helps minimise downtime and protect data integrity.
- Testing before go-live. Test application performance and security before you switch production traffic, and keep a rollback plan ready.
- Post-migration optimisation. Right-size from real usage data and flag candidates for re-platforming, so the migration continues past day one.
Dependency mapping and database planning carry most of the complexity, and that’s where schedules slip. McKinsey’s research found that most cloud migrations run over budget and more than a third fall behind schedule, so build slack into your plan. Timelines depend on scope. Small, well-scoped estates can move in weeks, while estates with thousands of servers take months.
Deciding which workloads to move as they are
Before committing to rehosting, assess which applications can move with few changes and which need more work. Some may be better left in their current environment for now.
NoviArc (Spyrosoft Cloud Foundry) uses AI agents to audit existing infrastructure and prepare an inventory, a dependency map, cost and risk analysis, and a recommended migration strategy for each workload. A Spyrosoft architect reviews and signs off each recommendation.
For workloads that need more than rehosting, NoviArc combines replatforming with a ready-made landing zone. Your applications move onto a production-ready platform built on upstream, open-source Kubernetes, running on the infrastructure you choose. That can be a European cloud provider, a public cloud, or your own servers. Your organisation retains ownership of the platform. Spyrosoft describes delivery in weeks and total migration cost savings of up to 80% compared with an all-consulting approach. The expected timeline and savings need to be established against the scope of your project.
Want to know which of your workloads can move as they are? Book a 30-minute workload and TCO session with a Spyrosoft architect and get an early view of cost, licensing and risk before you commit.
FAQ: lift and shift
Lift and shift is a cloud migration strategy that moves applications, data and operating systems to the cloud with little or no change. It’s also called rehosting. You reach the cloud quickly, but each application keeps its existing design, limitations included.
It means moving something to a new environment without changing it. In IT, that’s rehosting applications on cloud infrastructure. Outsourcing teams use the same phrase for handing over a process as it is, and content teams use it for moving pages to a new CMS untouched.
Yes. Rehost is the formal name in the 7 Rs framework, and lift and shift is the everyday one. Both describe moving a workload to the cloud without modifying the application.
Lift and shift changes where an application runs. Refactoring changes how it’s built, usually to use cloud-native services. Rehosting is faster and cheaper upfront. Refactoring takes longer but unlocks scalability and efficiency that rehosting can’t.
Replatforming adds targeted changes during the move, such as switching a self-managed database to a managed service or upgrading the operating system. The core architecture stays the same, which makes it a middle ground between speed and optimisation.
Upfront, usually yes, because there’s no redesign. Over time, not necessarily. Oversized servers, always-on billing, data transfer and licensing can make a rehosted workload cost more to run than it did on-premises.
Technical debt carried into the cloud, cost creep, licensing surprises, misconfigured security and data loss during cutover. Discovery, dependency mapping, a secure foundation and testing keep most of them in check.
It depends on how many workloads you have, how they depend on each other and which cutover method you use. Small, well-scoped estates can move in weeks. Large estates take months, so most organisations plan the move in waves.
Every major cloud provider offers its own rehosting tools, and independent options exist too. They replicate servers while they’re running, then cut over when you’re ready. The right choice depends mostly on your source environment and target cloud.
It’s handing a business process to a new provider exactly as it runs today. The aim is a stable handover, with improvements saved for later.
arrow_circle_rightCONTACT US
Before you lift and shift, check what comes with you
Marcin Waleczko
Vice President of Client Services
arrow_circle_right OUR ARTICLES
