Most cloud migration budgets are wrong in the same way. They cost the destination, and sometimes the work of moving, and they leave out the phase in the middle where you are paying for everything twice.
A migration has three distinct phases of spend, and the expensive one is the overlap: the months where the old estate is still running because it must be, while the new bill has already started. Budget for that properly and a migration is a manageable project. Leave it out and you will be explaining an overrun that was not an overrun at all, it was a forecast that omitted a third of the cost.
The three phases of cloud migration cost
| Phase | What happens | Illustrative cost |
|---|---|---|
| Discovery and design | Finding out what you actually run, which frequently differs from what anyone believes. Dependencies, licences, who owns what, what can move and what cannot. Then designing the destination rather than copying the source. | $8,000 to $35,000, or 5 to 15 per cent of the total. The phase people try to skip, and skipping it is what causes the expensive surprises later. |
| The move | Building the new environment, moving data, testing, cutting over, fixing what the testing missed. Usually done in waves rather than all at once. | $30,000 to $200,000 and upwards. Driven by how many systems, how old they are, and how much downtime you can tolerate. |
| The overlap | Running both estates at once. Old hardware still there, still depreciating, possibly still under a support contract you cannot exit, while the new subscription has begun. | Both bills, for one to six months. On a modest estate this is often the largest single line, and it is the one most often missing from the plan. |
Illustrative ranges from the kind of work we quote, not a price list. A useful sanity check: if a proposal does not name the overlap as a cost, it is not a budget, it is an estimate of the fun part.
Why it costs more during the move
The overlap is not waste and it is not bad planning. It is what safety costs, and the alternative is worse.
You cannot switch off the old system the moment the new one appears. You need the old one running while the new one is tested with real traffic. You need somewhere to fall back to if the cutover goes badly, and that fallback is only real if it is still working. Systems have dependencies on each other, so they move in waves, and while wave three is being moved, waves one and two are already costing money in their new home and waves four onwards are still costing money in the old one.
Then there are the things that end more slowly than you expect. A support contract with a year left. A lease. A licence bought for three years. Hardware that has value only if someone buys it, and often nobody does. A colocation agreement with a notice period. None of these care that you have finished migrating.
Compressing the overlap is possible and it is a trade rather than a saving: shorter overlap means less testing, less fallback and more risk on cutover night. Teams that cut it aggressively are the teams we most often meet afterwards.
The surprises that are not in the quote
- Data leaving. You pay for data moving out and often between regions or zones. It is not a resource you provisioned, so nobody estimates it. In your own building this traffic was free and invisible. Applications that chat constantly across a boundary produce a startling line.
- The initial data transfer. Moving years of accumulated data in the first place takes time and, above a certain size, a physical shipping option rather than the network. Plan it early because it can be the longest single task.
- Licences that change price. Some software is licensed differently on rented infrastructure than on hardware you own. Check every commercial product before committing, not after.
- Two sets of skills for the duration. Someone has to keep the old estate alive while others learn the new one. Usually the same people, working harder.
- Testing that finds real problems. Something always behaves differently, and the fix is scheduled work nobody planned. Budget contingency for this specifically rather than generally.
- The fortnight after cutover. Something needs attention. Treat this as part of the project rather than as a failure, and staff it deliberately.
When it is not cheaper at all
Worth stating plainly, because the industry does not: moving your servers as they are and paying standard rates usually costs more per month than running them did. The savings come from changing how things run, not where, and if nothing changes about your usage then nothing changes about your cost except that it goes up.
That is the whole argument in the cloud is not automatically cheaper, and it matters here because it changes what a good migration plan looks like. A plan that copies your current estate one for one has quietly committed you to a permanent rental at retail. A plan that resizes to real usage, switches off what is idle, commits on the steady baseline and replaces self-managed components with managed ones is buying you something. Ask which kind you have been given.
What a sensible budget looks like
- Cost all three phases, with the overlap as its own named line and its own duration. If someone cannot tell you how many months it will be, the plan is not finished.
- Model twelve months after cutover, not month one. Month one is the worst it will ever look, because nothing has been optimised and everything is still running everywhere.
- Include the exit costs of what you are leaving. Contracts, leases, licences, disposal, and the residual value of hardware you will probably not sell.
- Put contingency on discovery findings specifically. The most common overrun is not the move, it is discovering a system nobody documented that everything depends on.
- Decide in advance what you will not move. Some things should be retired instead, and a migration is the best excuse you will ever get to switch off something nobody has been willing to kill.
- Agree the optimisation phase before starting. If the plan ends at cutover, the bill stays at its worst level indefinitely, because the savings all live in work nobody has scheduled.
That last point is where most of the disappointment comes from. A migration finished at cutover is a migration finished halfway. The month after go-live is when resizing, switching off and committing on the baseline become possible, and it is exactly when everyone wants to move on to something else. Our migration work treats that as part of the project, and cost optimisation is what it looks like as a standalone piece when nobody did.
The four ways to move a workload
Not everything should move the same way, and the choice per system is where a good plan differs from a lazy one. Deciding this workload by workload during discovery is precisely what discovery is for.
| Approach | What it means | When it is right |
|---|---|---|
| Move it as it is | The same machine, the same configuration, rented instead of owned. Fastest and least risky on the day. | When a deadline is driving you, such as a lease or support contract ending. Accept that the bill will be higher until it is optimised afterwards, and schedule that work rather than hoping for it. |
| Move it and tidy it | Same application, but resized to real usage, with the database or storage swapped for a managed equivalent. | The default for most systems. Modest extra effort, and it is where most of the running-cost saving actually lives. |
| Replace it | Retire the system and use a product instead. Email, file sharing, and increasingly line-of-business tools. | More often than people expect. Migrating something you should have stopped running is the most avoidable cost in any programme. |
| Rebuild it | Re-architect the application to suit how the platform charges and scales. | Rarely, and only for the small number of systems where the running cost or the growth genuinely justifies it. Expensive, slow, and frequently proposed for systems that do not warrant it. |
A healthy plan usually has most systems in the middle two rows, a few in the first, and almost none in the last. If a proposal puts everything in one row, ask why.
The third row deserves more attention than it gets. Every estate contains something that exists because it always has: a reporting server nobody reads, a tool two people use, an application whose vendor now offers the same thing as a service. A migration is the one moment when switching those off is politically possible, and every one retired is a system you never pay to move, test, or run again.
Timelines, roughly
| Estate | Discovery to cutover | Typical overlap |
|---|---|---|
| A handful of servers, one or two applications | 6 to 12 weeks | 1 to 2 months |
| A dozen or so systems with real interdependencies | 4 to 8 months | 2 to 4 months |
| A full data centre exit with legacy systems | 9 to 18 months | 4 to 6 months, sometimes longer |
The overlap scales with the number of waves rather than with the number of servers, which is why a small estate with tangled dependencies can overlap for as long as a larger tidy one.
One further scheduling point that saves money rather than costing it. If your hardware refresh, your support contract and your colocation agreement all end at different times, work backwards from the earliest of them rather than picking a date that suits the project. Every month you migrate ahead of an expiry is a month of overlap you are paying for voluntarily, and every month you run past one is either a renewal you did not need or a system running without support. Aligning the plan to those dates is free, and it routinely removes a month or two of the most expensive phase.
Not for you if
One question worth asking any supplier before you sign: how many months of overlap have you assumed, and what happens to the budget if it takes twice that? The answer tells you whether you are looking at a plan or at a hope.