Lift and shift is not a mistake. Sometimes the data centre lease is ending, the hardware is out of support and the only sensible move is to get everything somewhere else quickly. We have recommended it ourselves.
The mistake is treating the move as the end of the project. Copying servers into the cloud unchanged keeps all the habits of the data centre and adds a meter that runs every hour. The bill does not arrive all at once. It creeps, and by the time someone in finance asks why cloud costs more than the old setup did, the people who made the decisions have moved on.
Here is where the money usually goes.
Why lift and shift happens
It is worth being fair about this first. A move done as-is is quick to plan, low risk on the day, and needs very few changes to the application. Teams that are short of time or short of cloud skills choose it for good reasons, and providers often make it attractive with migration credits and early discounts.
The trouble is that every one of those reasons is about the move. None of them is about the next five years of running the thing.
Servers sized for a peak that never comes
In a data centre you buy hardware for the busiest day of the year plus a margin, because adding capacity later means a purchase order and a three-month wait. That made sense. The server was a sunk cost and nobody paid extra for leaving it idle.
Copy that server into the cloud and you now rent the busiest-day size every hour of every day. We routinely find virtual machines that have not gone above a fifth of their CPU in months. Nobody picked that size on purpose; it was simply what the old box had.
Two to four weeks of utilisation data is usually enough to right-size the obvious cases. The ones that genuinely spike can go behind autoscaling so they grow on the busy day and shrink afterwards.
Environments that never switch off
Development, test and staging environments in a data centre ran all night because there was no reason to turn them off. In the cloud there is a very good reason.
The arithmetic is simple. A week has 168 hours. If your teams work twelve hours a day, five days a week, that is 60 hours of real use. The other 108 hours, nearly two thirds of the week, are paid for and unused. Scheduling non-production environments to stop overnight and at weekends is one of the least glamorous and most effective things you can do, and it rarely needs anyone’s code to change.
The data centre taught everyone that idle is free. The cloud charges for exactly the same habit.
Licences that counted differently on-premise
This one catches out even experienced teams. Commercial databases, operating systems and middleware are often licensed by processor cores, and the rules for counting cores in a public cloud are not always the same as the rules for the physical server you came from. Depending on the vendor and the agreement, the same workload can need more licences after the move, or be eligible for a cheaper bring-your-own-licence route that nobody applied for.
We have seen both outcomes on the same estate. Before any move, and certainly before any renewal, get someone who reads licence agreements for a living to compare what you own with what you will actually be running. It is the reason Software Asset Management sits in our service list beside cloud work rather than in a separate department.
The quiet line items
A handful of smaller charges add up without anyone noticing, because none of them is big enough to show up on a summary slide.
- Data leaving the cloud. Traffic out to the internet, between regions, and sometimes between zones is charged per gigabyte. Chatty systems that used to talk across a rack now talk across a billing boundary.
- Snapshots and backups nobody deletes. Easy to create, easy to forget, and they quietly pile up for years.
- Disks with nothing attached to them. A deleted server can leave its storage behind, still being billed.
- Commitments bought on the old sizes. Reserved capacity or savings plans signed before right-sizing lock in the oversized shape for one to three years.
Why it shows up in year three
Year one usually looks fine. Migration credits and introductory discounts absorb a lot, and everyone is focused on getting the move finished.
In year two the credits run out and commitments get signed, often against the sizes that were copied over. Costs rise, but they can be explained as growth.
By year three the comparison people make is no longer with the migration budget. It is with what the old data centre would have cost. That is when the awkward meeting happens, and it is also when the original team has typically moved to other work.
Getting it back without a rebuild
The good news is that most of the waste can be removed without re-architecting anything. The order we usually work in is:
- Tag everything with an owner and an environment. You cannot cut what you cannot attribute.
- Schedule non-production to stop outside working hours.
- Clean up the orphans: unattached disks, old snapshots, idle load balancers and forgotten test accounts.
- Right-size from real data, then put the spiky workloads behind autoscaling.
- Review licences against what is actually running now.
- Only then buy commitments, on the new, smaller shape.
- Pick one or two systems to modernise properly, for example moving a self-managed database onto a managed service, where the operational saving is clear.
Steps one to three are usually done in a few weeks and often pay for the whole exercise. The later steps take longer, and they are where an honest conversation about which systems are worth modernising belongs.
Written by the people at Ucanly who do this work for clients. If you think we have got something wrong, or you have seen it go differently, we would genuinely like to hear it: support@ucanly.in.