What a cloud migration actually costs

We have moved a fair number of businesses off ageing on-premise servers, and the conversation almost always starts the same way: someone has read that the cloud is cheaper. Sometimes it is. Often the honest answer is that it is better, and roughly the same price once you count everything.

Where the money actually goes

A migration has four cost buckets, and only one of them appears on a cloud provider's pricing calculator.

1. The running bill. Compute, storage, data transfer. This is the visible one, and it is usually the smallest surprise.
2. The migration project. Assessment, design, the actual moves, testing, cutover weekends. One-off, but real.
3. Rework. Applications that assumed a local file share, hard-coded IP addresses, licensing that does not transfer. This is where estimates go wrong.
4. Running it afterwards. Somebody has to patch, monitor, review the bill and respond when something breaks at 2am. The server room disappeared; the work did not.

The three things that blow up a cloud bill

Right-sizing that never happens. Teams migrate like-for-like — a 32 GB server becomes a 32 GB instance — then never revisit it. On-premise, over-provisioning was a sunk cost. In the cloud you pay for it monthly, forever.

Data transfer out. Getting data in is free. Getting it out is not. If you are serving large files or replicating between regions, model this properly before you commit.

Nothing ever gets switched off. Test environments running at the weekend, orphaned disks from deleted machines, snapshots from 2022. We have found 30 % of a monthly bill in this category more than once.

The cheapest cloud engagement we ever delivered was an assessment that concluded the client should stay where they were for another two years. They kept the report and we kept the relationship.

What good looks like

A migration worth doing has these characteristics:

• A written assessment of what you have now, including the things nobody wants to talk about
• Workloads moved in tested waves, each with a rollback path, not a single big-bang weekend
• The old environment left intact until the new one has proven itself under real load
• A cost review scheduled 30 and 90 days after cutover, when the real usage pattern is visible
• Documentation handed over, so you are not dependent on the firm that did the move

When to stay put

If your hardware is two years old, your workload is steady and predictable, and you have no plans that need elastic capacity, the financial case is weak. Migrate when there is a reason — a hardware refresh coming, a new office, a compliance requirement, an application that needs to scale. "Everyone is doing it" is not a reason, and any supplier who tells you otherwise is selling.