The Cloud Bill Nobody Forecasts

There is a cost in cloud migration that is almost never estimated properly, and the reason is interesting: it does not exist until the moment you start.

It is the charge for moving data between where your systems used to be and where they are going.

Free until it isn't

Inside your own building, systems talk to each other constantly and it costs nothing that reaches a budget. Two services exchanging millions of messages a day are using switch capacity you already bought. Nobody meters it. Nobody thinks about it.

Over years, architectures become chatty precisely because nothing penalises chattiness. There is no feedback signal telling anyone to reduce it.

Then you move one of those systems to a cloud provider. The traffic is identical. But now it crosses a boundary, and cloud providers charge for data leaving their network — priced per unit, billed monthly, scaling with volume.

Nothing about the architecture changed. Someone drew a line through the middle of it, and the line has a price.

This is why the charge is so consistently underestimated. It is not that people estimate badly. There is no historical figure to estimate from, because the cost never previously existed. You cannot extrapolate from zero.

The plan that makes it worse

Here is the part worth understanding, because it is counterintuitive.

The standard approach is to move one application at a time. Small steps. Each one schedulable, reversible, easy to explain. Practically every migration plan is built this way, and every framework recommends it.

Now think about what that does to a group of systems that depend on each other. One moves. The others stay. Every exchange between them now crosses the charged boundary. Then another moves, and depending on the order, some traffic crosses twice.

The approach that minimises the risk of each individual step maximises the volume and duration of charged traffic. You have optimised for what is visible in a status meeting and worsened what appears on a bill three months later.

And this period always lasts longer than planned. Not sometimes — reliably. The last systems to move are invariably the ones with unclear ownership, awkward vendor contracts, or business units whose busy season collides with every proposed date. A migration planned for twelve months typically spends eighteen to twenty-four in a split state.

Move groups, not individuals

The alternative is to identify systems that talk to each other frequently and move them together as a unit.

This is harder. Each step is bigger, coordination is heavier, and it looks riskier when presented.

It is also cheaper — and, less obviously, often safer overall. A larger move with a clean boundary has fewer parts sitting across the divide than six small moves that each split something in half. You trade a collection of small ongoing risks that nobody fully understands for one larger, well-defined event you can plan and rehearse.

In practice this single choice affects total migration cost more than any amount of tuning how big the servers are — which is where most cost attention goes, because it is easy to measure and fits neatly on a dashboard.

Data is the same argument, but permanent

Everything above applies more strongly to data, because data does not move cheaply even once.

Applications can be relocated again if you get it wrong. It is a nuisance, but it is possible. Large volumes of data are a different matter — moving them costs real money, takes real time, and is realistically something an organisation does once.

After that, everything that reads the data is anchored to wherever it sits. Not by any technical limitation, but by economics and physics: reading from somewhere else costs a transfer fee every time, and distance costs speed.

So the location of your data quietly determines where everything else has to live.

The common mistake is migrating applications first and dealing with data later. Teams that do this often find one connected business system split across two providers, with information crossing continuously and a charge applied on every pass. Nobody chose that. It emerged from the order things happened in, and the remedy is a second migration that nobody funded.

Why AI makes this sharper

If AI is part of where you are heading, this matters considerably more.

Conventional applications read a record when someone asks for it. AI systems read large volumes repeatedly — processing an entire document collection to make it searchable, then reading continuously for every question anyone asks.

If your documents sit with one provider and your AI service with another, you pay a transfer charge on every one of those passes. And unlike most infrastructure costs, that line grows as the feature becomes popular rather than staying flat.

Which inverts a familiar assumption. Traditional infrastructure costs roughly the same whether busy or idle. AI costs rise with use. A successful feature becomes proportionally more expensive, and that needs to be understood before someone in finance asks why the bill grew forty per cent in a month.

What to do about it

Four things, none complicated.

Decide where your main data collections will live before any system moves, and treat that as close to permanent.

Sequence waves by groups of connected systems rather than one application at a time.

Estimate the split-state period at fifty per cent longer than planned, because that is what happens, and price cross-boundary traffic against that duration.

Make sure someone can tell you which feature is driving which cost, from the first day of the first deployment. Adding that later is painful, and the question always arrives urgently.

Frequently Asked Questions

Why is data transfer cost so hard to estimate?

Because it has no equivalent on-premises. Internal traffic in your own building is free, so there is no historical figure to extrapolate from — the cost simply did not exist before.

Is moving one application at a time really worse?

For cost, yes, clearly. It keeps connected systems split across a charged boundary for the whole transition, which runs longer than planned. Moving connected groups together reduces that exposure.

Why can't data just be moved again later?

It can, technically, but the expense and time involved mean organisations realistically do it once. Everything reading that data then becomes anchored to its location.

How long do these split periods actually last?

Typically fifty per cent longer than planned or more, because the final systems are the ones with ownership disputes and contract complications.

Does AI really change the cost picture?

Yes. AI reads data repeatedly rather than occasionally, and its costs scale with usage rather than staying fixed, so placement mistakes compound as adoption grows.

What is the single most important early decision?

Where your main data will live. It is the least reversible choice and it constrains everything else about where systems can sensibly run.

---

The full technical article is at Cloud Migration Best Practices for AI-Era Workloads.

We help organisations plan migrations properly — custom software development and contact us.