Lift-and-shift — taking an existing on-premise system and moving it to a cloud provider with minimal changes — is appealing because it sounds fast and low-risk. In practice, it is one of the highest-risk migration patterns if you go in without a clear picture of what you are moving.
Here are five mistakes we see repeatedly.
1. Treating the Cloud as a Datacenter Rental
The most common mistake is moving a system to the cloud and then managing it exactly as you managed it on-premise. You spin up a VM, install the same software, and run the same manual processes.
This works, but you lose most of the value of cloud infrastructure. More importantly, you inherit cloud costs without cloud benefits — you are paying per-hour for a server that your on-premise system would have handled more cheaply on owned hardware.
Before migrating, identify which parts of your system can use managed services. A managed database service like RDS or Cloud SQL eliminates patching, backup management, and failover configuration. A managed queue service eliminates the VM running your message broker. Each managed service you adopt reduces your operational burden.
2. Ignoring Network Topology
On-premise systems are often designed for a flat network where every service can reach every other service directly. Cloud environments are not flat. VPCs, subnets, security groups, and peering connections all affect what can talk to what.
Before migration, map every network dependency: which services call which, on which ports, and with what authentication. Then map that dependency graph to your cloud network design. Discovering that your application server cannot reach your database because of a misconfigured security group during a production cutover is a preventable problem.
3. Underestimating Data Transfer Costs and Time
Moving large datasets out of your datacenter and into a cloud provider takes longer and costs more than most teams expect. A 10 TB database backup transferred over a 1 Gbps connection takes roughly 22 hours under ideal conditions. Real conditions are rarely ideal.
For large datasets, evaluate physical transfer options (AWS Snowball, Azure Data Box) alongside network transfer. For databases that must stay live during migration, design a streaming replication approach rather than a bulk copy — but account for the fact that replication lag must reach zero before you can cut over.
4. Not Accounting for Licensing
Several common enterprise software packages — Microsoft SQL Server, Oracle Database, Windows Server — have licensing models that change significantly in cloud environments. Some licenses are included in the per-hour cost of specific VM types. Others require you to bring your own license (BYOL), which has its own compliance requirements.
Audit every piece of licensed software in the stack before migration. An overlooked license compliance issue can generate significant unexpected cost or legal exposure after the fact.
5. Skipping the Performance Baseline
You cannot know whether your migrated system performs correctly unless you know how the original system performed. Teams that skip pre-migration performance baselines have no objective way to evaluate whether degraded performance in the cloud is a regression or was always present.
Before migration: capture response time distributions for key operations, database query execution plans, and resource utilization under normal load. After migration: run the same measurements. Differences are findings to investigate, not assumptions to make.
Conclusion
A lift-and-shift is not inherently a bad strategy. For some workloads it is the right first step. But it is a strategy that requires the same rigorous preparation as any other migration. The teams that succeed treat it as a project with defined scope, documented dependencies, and measurable success criteria — not a copy-paste of infrastructure.