What a cloud migration actually costs

Most cloud migration business cases we are shown compare two numbers: what the current servers cost, and what the equivalent cloud instances cost. The second number is smaller, so the project is approved. Eighteen months later the bill is higher than the hardware ever was, and nobody can point to the decision that caused it.

Nothing dishonest happened. The model was just missing four things.

1. You will run both for longer than you planned

Dual-running is the single largest line item that gets left out. You cannot switch a business off on a Friday and on again on Monday, so for some period you pay for the old environment and the new one simultaneously — plus the licences, the backups and the monitoring on both.

Teams routinely budget three months for this and spend nine. The overrun is rarely technical. It is the one integration owned by a supplier who cannot schedule the work until next quarter, or the application whose vendor will not support it on the new platform.

Model dual-running at twice your honest estimate. If you finish early, you have found money. The reverse is a conversation with your board.

2. Egress is priced to keep you there

Moving data in is free. Moving it out is not, and the rate is low enough per gigabyte to look irrelevant in a spreadsheet and high enough to matter at volume. The costs that surprise people are almost never the one-off migration transfer — they are the steady-state ones nobody attributed to a workload.

• Backups written to a different provider or back on-premises, every night, forever.
• A reporting database replicating to a system that stayed where it was.
• Traffic between availability zones, which is a charge in most providers and is invisible in an architecture diagram.
• A media or file-heavy product serving users directly from storage rather than through a CDN.

None of these are reasons not to migrate. They are reasons to know the shape of your data flows before you sign, because egress pricing is the mechanism by which leaving later becomes expensive.

Moving data in is free. That asymmetry is not an accident, and it is worth understanding before you depend on it.

3. Lift-and-shift is a decision, not a phase

Lift-and-shift — moving a workload as-is onto cloud instances — is often the right call. It is faster, lower-risk, and gets you out of a data centre contract on time. The failure is not choosing it. The failure is calling it phase one of a plan whose phase two is never funded.

A virtual machine sized for a physical server runs the same twenty-four hours a day whether or not anyone is using it, and you now pay by the hour for all of them. That is the mechanism behind most "cloud is more expensive" conclusions, and it is a procurement outcome rather than a technical one.

If optimisation is not scoped, costed and scheduled in the same business case as the move, assume it will not happen, and model the steady-state bill on that basis.

4. Your licences may not come with you

Per-socket and per-core licensing written for physical hardware often behaves very differently on shared infrastructure, and some vendors price specifically for it. Database licensing is where this bites hardest and where the sums are large enough to change which provider you pick.

Have someone read the actual agreements for your top three most expensive pieces of software before the architecture is settled. This is a dull afternoon that occasionally saves six figures.

What a realistic model includes

• Compute, storage and network at steady state — the easy part, and the only part most models have.
• Dual-running for a period you would defend in front of a sceptical finance director.
• The migration itself: people, their time, and the delivery management to keep it sequenced.
• Egress for backups, replication and anything crossing a zone or provider boundary.
• Licence changes for the workloads where terms differ on shared infrastructure.
• A funded optimisation phase, with a date — or an honest steady-state figure that assumes there is not one.
• Training and the productivity dip while your team learns to operate the new environment.

The honest summary

Cloud is usually cheaper than owning hardware once workloads are sized for it, and it is almost always better on resilience, recovery and the speed at which you can try something. But it is cheaper the way a gym membership is cheaper than home equipment — conditional on actually using it the way it is designed to be used.

If a migration is being justified purely on cost, and the plan is to move everything as-is, be straightforward with yourself about the outcome. There are much better reasons to go, and they survive scrutiny.