Lift-and-shift cloud migration: what is hidden in the bill
Why moving applications to the cloud without rearchitecting often costs more than expected, and what to examine before starting a migration.
Cloud migration has become a standard item in IT plans. AWS, Azure, and Google Cloud actively offer migration tools, consultants are ready to help, and at first glance the task looks straightforward: take what runs on your own servers and move it to the cloud.
The fastest path is lift-and-shift: move virtual machines as-is, without changes to the application architecture. It is indeed fast. But in the first months after migration, many companies discover that the bill does not match what was expected.
Why the numbers do not add up
The classic argument for cloud is replacing capital expenditure (hardware) with operational expenditure (rented capacity). On paper this looks better: no need to lock money into equipment, pay only for what you use.
The problem is that "pay only for use" works differently than assumed.
Applications written to run on physical hardware are generally not optimised for cloud consumption patterns. They hold allocated resources continuously - as they were accustomed to doing on dedicated servers. In the cloud, this means you pay for resources even when they are not needed.
Additionally: storage, network traffic - especially egress - licences not included in the cloud rate, support, backup. In your own infrastructure, all of this was folded into shared overhead. In the cloud, each line is billed separately.
Three scenarios where lift-and-shift disappoints
Systems with uneven load that cannot scale. If an application is sized for peak load and cannot scale horizontally, the cloud will not provide savings during idle time. You are simply renting the same hardware, often at a higher effective price.
Databases with large data volumes and active replication. Egress network traffic in the cloud is charged. If the architecture involves active data exchange between components, the traffic bill can be a surprise.
Legacy licensed applications. Some enterprise licences require separate vendor approval or additional licences when moved to cloud. This is not a cloud question - it is a licensing contract question.
What to assess before migration
I have nothing against cloud. For many tasks it is the right answer. But lift-and-shift requires an honest calculation.
The load profile of each component. How does consumption vary across hours, days, months? Are there low-utilisation periods when resources could be reduced? This determines how much the cloud actually saves.
Traffic structure. How much data moves between system components? If most of the exchange is internal, it is important to understand what that looks like in cost terms in the cloud.
Licensing restrictions. For each component - does the current licence permit operation in a cloud environment? What is the cost of transitioning if not?
The true cost of the alternative. What does maintaining your own infrastructure actually cost - including staff, hardware replacement, and the facility? This is the correct baseline for comparison.
A practical conclusion
Moving to cloud is a strategically correct direction for most companies. But "just move it" and "get savings" are not the same thing. Lift-and-shift makes sense as a temporary step or as a way to stop managing hardware - not as a way to reduce costs without architecture changes.
Companies that achieve genuine cloud savings typically also optimise architecture during migration. That takes longer and costs more upfront - and is considerably cheaper to operate.