Lifting and Shifting a Monolithic Thirty-Year-Old Application Into the Public Cloud: What Actually Happens

Lifting and shifting a monolithic thirty-year-old application into the public cloud without refactoring the code is entirely possible — and organisations do it every day. Whether it's the right decision is a different question entirely, and one that deserves an honest answer rather than a vendor deck. Done with clear eyes, a lift-and-shift migration can be a legitimate first step. Done as a substitute for a strategy, it's the IT equivalent of moving house and hoping your problems don't know the new address.

This article covers what lift-and-shift actually involves for legacy monoliths, where it genuinely makes sense, where it quietly falls apart, and what you need to know before you sign off the business case.

What does "lift and shift" actually mean?

Lift-and-shift (also called a "rehost" migration) means moving an application from its current infrastructure — usually on-premises servers — to the public cloud with no changes to the application code, architecture, or core dependencies. You are, essentially, replacing the physical tin with virtual tin hosted by someone else.

The application continues to behave exactly as it did before. It just lives in a different postcode. AWS, Microsoft Azure, and Google Cloud all have tooling and migration programmes specifically designed to support this approach, and it remains one of the most common cloud migration strategies in use.

The appeal is obvious: you're not touching the code. For a thirty-year-old monolith where institutional knowledge has long since walked out the door with the people who built it, "don't touch the code" can be a very rational constraint.

Is it actually safe to lift and shift a legacy monolith without refactoring?

Yes — with caveats that matter. The application itself is not being changed, so the functional risk of the migration is lower than a refactor or rewrite. What changes is the infrastructure layer: networking, storage, compute, and the operating environment around the application.

The risks are real but manageable. A 2023 Gartner survey found that over 60% of cloud migration projects that failed to meet their objectives cited inadequate pre-migration assessment as a root cause — not the migration approach itself. The approach wasn't the problem; the lack of honest preparation was.

I've sat in rooms where the decision to lift-and-shift was made in about forty minutes, largely because nobody wanted to be the person who said the application was too fragile to touch. That's not a migration strategy. That's conflict avoidance with a cloud budget attached.

What are the six Rs of cloud migration — and where does lift-and-shift fit?

The 6 Rs framework (originally developed by Gartner and popularised by AWS) describes six migration strategies. Lift-and-shift sits at the simpler end:

Rehost (Lift-and-Shift): Move as-is to cloud infrastructure. No code changes.
Replatform (Lift-Tinker-and-Shift): Minor optimisations — for example, moving to a managed database service — without changing core architecture.
Repurchase: Replace with a SaaS product (e.g. moving from a legacy CRM to Salesforce).
Refactor / Re-architect: Rebuild with cloud-native patterns (microservices, containers, etc.). Highest cost, highest long-term value.
Retain: Keep it on-premises for now. Sometimes the honest answer.
Retire: Switch it off. Often the most courageous and underused option.

For a thirty-year-old monolith, the realistic options are usually Rehost, Retain, or Retire. Anything else requires code-level knowledge you may simply not have.

What are the genuine benefits of lifting and shifting a legacy application?

Speed is the most honest answer. A rehost migration can be completed in weeks or months. A refactor or rewrite is typically measured in years — and that's before the inevitable scope creep turns it into a small nation-state.

Other legitimate benefits include:

Data centre exit: If you're vacating a physical data centre under a deadline (a lease expiry, an end-of-life hardware support contract), lift-and-shift is often the only option that fits the timeline.
Reduced operational overhead: Even without code changes, you shift hardware maintenance, physical security, and some infrastructure management to the cloud provider.
Disaster recovery improvements: Cloud providers offer resilience and geographic redundancy that most on-premises setups can't match without significant capital investment.
A foundation for future modernisation: Once the application is in the cloud, you have more options. Refactoring incrementally from a cloud environment is often easier than doing so from a legacy data centre.

What are the real risks — the ones nobody puts in the business case?

This is where it gets interesting. Lift-and-shift preserves every technical debt, every architectural limitation, and every inefficiency the application has accumulated over three decades — it just moves them to a more expensive environment to run them in.

Cloud pricing models are optimised for elastic, cloud-native workloads. A monolith designed to run on dedicated hardware, provisioned for peak load and sitting largely idle the rest of the time, will often cost significantly more to run in the cloud than it did on-premises. The Flexera 2024 State of the Cloud Report found that organisations waste an average of 28% of their cloud spend — and over-provisioned legacy workloads are a significant contributor.

Other risks worth naming plainly:

Licensing costs: Many legacy applications carry licences tied to on-premises hardware. Moving to cloud can trigger additional licensing fees, particularly for Oracle and Microsoft products. This has surprised more than a few finance directors.
Performance degradation: Applications built for low-latency local network connections may perform poorly over cloud networking. This is especially true for applications that make thousands of internal calls that were never designed to cross a network boundary.
No cloud-native benefits: Auto-scaling, serverless, managed services, pay-per-use economics — none of these are available to an application that hasn't been refactored to use them.
Security and compliance: Moving to the cloud doesn't automatically make an application compliant. If the application has security vulnerabilities baked into its thirty-year-old architecture, they travel with it.
The illusion of progress: This is the one I find most corrosive. Organisations sometimes declare "cloud migration complete" and believe they've modernised. They haven't. They've changed where the problem lives, not what the problem is.

How do you assess whether a legacy monolith is even suitable for lift-and-shift?

Before committing to a migration approach, a proper application discovery and dependency mapping exercise is non-negotiable. Tools like AWS Application Discovery Service, Azure Migrate, or third-party platforms like Cloudamize can automate much of this — but someone still needs to interpret the results.

Key questions to answer in the assessment:

What operating system does the application run on, and is it still supported? (Windows Server 2003 in the cloud is not an improvement over Windows Server 2003 on-premises.)
What are the application's external dependencies — databases, third-party integrations, hardware dongles, local file system paths?
Are there any hardcoded IP addresses, server names, or local paths in the application code or configuration?
What are the licensing terms for the application and any middleware it relies on?
What are the current performance baselines, and what are the acceptable tolerances post-migration?
What does the application's network traffic pattern look like — and will cloud networking support it adequately?

I've seen applications that looked straightforward on paper turn out to have an undocumented dependency on a specific physical network card. Discovery is not optional. It's the bit where you find out what you've actually got.

What does the actual migration process look like, step by step?

The lift-and-shift process for a legacy monolith typically follows these stages:

Discovery and assessment: Map the application, its dependencies, its infrastructure, and its performance baselines. Identify blockers early.
Migration planning: Choose the target cloud provider and region. Define the target architecture (VM sizes, storage types, network topology). Plan for licensing. Establish rollback procedures.
Environment preparation: Build the cloud landing zone — VPCs (Virtual Private Clouds), subnets, security groups, identity and access management. This is infrastructure work, not application work.
Data migration: Migrate databases and file storage. For large datasets, this may involve physical data transfer services (AWS Snowball, for example) rather than network transfer.
Application migration: Use VM import/export tools or cloud migration services to replicate the server environment. AWS Server Migration Service, Azure Site Recovery, and Google Migrate for Compute Engine all support this.
Testing: Validate functionality, performance, and integrations in the cloud environment before cutting over. Do not skip this. I cannot stress this enough.
Cutover: Switch production traffic to the cloud environment. Keep the on-premises environment warm for a defined rollback window.
Post-migration optimisation: Right-size VMs, review costs, address any performance issues identified during testing. This is where you start paying back the technical debt of the migration approach — gradually, if you're sensible about it.

How does lift-and-shift compare to the alternatives?

Approach	Time to Complete	Cost (Short-Term)	Cost (Long-Term)	Risk Level	Cloud Benefits Realised	Best For
Lift-and-Shift (Rehost)	Weeks to months	Low to medium	Medium to high	Low to medium	Minimal	Data centre exit deadlines; low-risk applications; first step in a phased strategy
Replatform	Months	Medium	Medium	Medium	Moderate	Applications where managed services offer clear wins with limited code changes
Refactor / Re-architect	One to three years (typically)	High	Low	High	Full	Strategically critical applications with long-term investment appetite
Retain (Stay on-premises)	N/A	Low	Medium to high	Low	None	Applications with complex compliance requirements or near end-of-life
Retire	Variable	Low	None	Low to medium	N/A	Applications with low or no active user base; duplicated functionality

What cloud providers and tools are best suited for this kind of migration?

All three major cloud providers — AWS, Microsoft Azure, and Google Cloud Platform (GCP) — have mature tooling for lift-and-shift migrations of legacy workloads. The right choice usually depends on your existing Microsoft licensing estate, your team's existing skills, and any pre-existing commercial relationships.

Key tools by provider:

AWS: AWS Application Migration Service (MGN), AWS Database Migration Service (DMS), AWS Server Migration Service (SMS — now largely superseded by MGN), AWS Snowball for large data transfers.
Microsoft Azure: Azure Migrate (the hub for discovery, assessment, and migration), Azure Site Recovery for VM replication, Azure Database Migration Service.
Google Cloud: Migrate for Compute Engine (formerly Velostrata), Database Migration Service, Transfer Appliance for large datasets.

If your legacy application runs on Windows Server and relies heavily on Active Directory, SQL Server, or other Microsoft products, Azure often presents the most straightforward licensing path. That said, don't let licensing familiarity be the only factor in your cloud provider decision — it's a long marriage, and the prenuptial agreement (your exit costs) deserves scrutiny.

What happens to cloud costs after a lift-and-shift?

This is the conversation that tends to happen about six months after go-live, usually in a room with a finance director who has received a cloud bill and would like to understand it better.

Cloud costs for lifted-and-shifted legacy workloads are almost always higher than initial estimates, for several structural reasons. Legacy applications were typically sized for peak capacity on dedicated hardware. In the cloud, you're paying for that peak capacity continuously — unless you right-size, which requires understanding the application's actual resource consumption patterns.

Strategies to manage costs post-migration include:

Reserved Instances or Savings Plans: Committing to one or three years of cloud usage in exchange for discounts of 30–60% on on-demand pricing. Only sensible if you're confident the workload will remain in the cloud at that scale.
Right-sizing: Using cloud monitoring tools to identify over-provisioned VMs and reduce them to appropriate sizes. This alone can cut costs by 20–40% on legacy workloads.
Storage tiering: Moving infrequently accessed data to cheaper storage tiers (e.g. AWS S3 Glacier, Azure Archive Storage).
Scheduling: Shutting down non-production environments outside of business hours. Simple, effective, often overlooked.

Should lift-and-shift be a strategy or a stepping stone?

In my experience, the organisations that get the most value from lift-and-shift are the ones who are honest about what it is: a tactical move, not a destination. They migrate, stabilise, and then use the cloud environment as a platform to incrementally modernise — breaking off services, replacing components, retiring redundant functionality over time.

The organisations that struggle are the ones who treat the migration as the transformation. They announce a "cloud-first strategy," migrate a portfolio of legacy applications with no code changes, and then wonder why their operational costs have gone up and their developers are still working around the same architectural constraints they had before.

Lifting and shifting a thirty-year-old monolith into the cloud is a perfectly legitimate thing to do. Calling it a digital transformation is a different matter entirely.

Frequently Asked Questions

Can you lift and shift an application that runs on an unsupported operating system?

Technically, yes. Practically, it's a significant risk. All three major cloud providers will host VMs running end-of-life operating systems like Windows Server 2008 or older Linux distributions — but you lose any vendor security patching, and your compliance posture takes a serious hit. If you're migrating an application running on an unsupported OS, treat OS modernisation as a parallel workstream, not something to defer indefinitely.

Will lift-and-shift improve application performance?

Not inherently. In some cases, performance improves because cloud infrastructure is more modern than the on-premises hardware being replaced. In other cases, particularly for applications with high internal latency sensitivity or dependencies on local storage, performance can degrade. Always establish performance baselines before migration and test rigorously in the target environment before cutover.

How long does a lift-and-shift migration typically take for a large legacy application?

For a single application with well-understood dependencies, a few weeks to three months is a reasonable range. For a complex monolith with undocumented dependencies, multiple databases, and integration points across the estate, six to twelve months is more realistic once you include discovery, testing, and a sensible cutover plan. Compress the timeline at your peril.

Does lift-and-shift affect application security?

The application's inherent security posture doesn't change — any vulnerabilities in the code travel with it. However, the surrounding security controls change significantly: cloud providers offer sophisticated network security, identity management, and monitoring capabilities that are often superior to on-premises equivalents. The key is ensuring those controls are properly configured. Migration is not a security audit substitute.

What's the difference between lift-and-shift and replatforming?

Lift-and-shift (rehost) means no changes to the application or its dependencies — you're moving the whole environment as-is. Replatforming involves minor modifications to take advantage of cloud-managed services — for example, migrating from a self-managed database on a VM to a managed database service like Amazon RDS or Azure SQL Database — without changing the application's core architecture. Replatforming typically offers better long-term economics with modest additional migration effort.

Can I lift and shift an application with a hardcoded IP address or server name?

You can, but you'll need to address the hardcoded references before or during migration — either by reconfiguring the application's configuration files (if the hardcoding is in config rather than compiled code), using DNS aliasing to preserve name resolution, or in some cases assigning specific private IP addresses in the cloud environment. Discovery tooling will usually surface these issues; the important thing is not to discover them on cutover day.

Is lift-and-shift suitable for regulated industries like financial services or healthcare?

Yes, with appropriate due diligence. All major cloud providers hold extensive compliance certifications (ISO 27001, SOC 2, PCI DSS, HIPAA, and many others). However, compliance certifications cover the cloud platform, not your application. Your data governance, access controls, audit logging, and data residency requirements all need to be validated for the new environment. Engage your compliance and legal teams early — not as an afterthought during UAT.

What's the biggest mistake organisations make when lifting and shifting legacy applications?

Underinvesting in the discovery and assessment phase. The migration itself is usually the easy part. The expensive surprises — unexpected licensing costs, undocumented dependencies, performance issues, security gaps — almost always trace back to things that weren't properly understood before the migration started. Spend the time upfront. It's considerably cheaper than spending it in a post-incident review.