A cloud migration quote prices the provider's work. It rarely prices the rest: the period when the old and new environments run side by side, your teams' time during the cutover waves, the licences to revisit, the datacentre contracts that do not stop the day the last application leaves. That rest is what pushes budgets off course, because nobody wrote it down anywhere.
This post lists what a move to the cloud really costs, and answers the question that is usually asked too late: who carries each of those costs.
What sets the price of a migration
The cost of a migration depends on the number of applications and how tightly they are coupled far more than on the size of the infrastructure. A hundred servers hosting independent applications are easier to migrate than twenty servers sharing a database, file flows and scheduled jobs that nobody documents any more.
The path chosen for each application weighs next. Rehosting as-is is the fastest route and the cheapest to carry out. Replatforming, which moves the database or storage onto managed services, takes more work but removes part of the operations. Refactoring costs the most, and is only justified for applications that still have a long life ahead of them. A well-prepared cloud migration prices those paths application by application, not as one block.
Six cost lines that do not appear in the quote
Parallel running. A progressive cutover runs source and target side by side, long enough to move traffic in stages and keep a rollback possible. It is the right method, and it has a price: for weeks, you pay for both. That cost has to be budgeted, not discovered.
Your teams' time. Even when a provider runs it, a migration takes up your developers and application owners: mapping dependencies, acceptance testing, signing off each wave. Meanwhile, changes to the applications concerned are frozen. It is often the heaviest line, and the only one nobody invoices.
Licences. Some software licences do not carry over to the cloud on the same terms; others change model. The subject is settled before the cutover, with the contracts in front of you, not on the first bill.
Data transfer. The volumes to move, temporary network links, replication services during the transition: this line is measured before, not after.
Leaving the datacentre. Rack rental, hardware maintenance contracts, carrier links: those commitments have notice periods. A migration that finishes ahead of contracts that are still running costs twice. The cutover schedule has to be built alongside the termination schedule.
The bill afterwards. Rehosting as-is often costs more than the original datacentre. Savings come later, once sizing is adjusted, non-production environments are switched off at night, and managed services replace machines maintained by hand. Until that work is done, the cloud bill stays above budget, as we explain in who owns the cloud budget at month six.
Who carries what
The question is not only how much, but who pays and who takes the risk.
The provider carries the priced work: the audit, the path, the cloud foundations, running the cutovers. Insist that the quote separates those stages, and says what is fixed-price and what is time and materials.
The cloud provider can carry part of the effort. The AWS MAP programme, for example, covers part of the assessment and of the cutover from a datacentre; other providers have comparable schemes. That funding is prepared up front: it covers part of the cost, never all of it, and it assumes a committed scope and schedule.
Your IT leadership carries parallel running, the teams' time and the cutover decision. These are internal costs, which is why they vanish from the spreadsheets.
Your finance function carries the datacentre exit and the change in the nature of the spend: a depreciated investment becomes a monthly consumption that moves. It needs to know before month one, not find out in month three.
The business carries the freeze on changes during the waves. It must have agreed to it before launch.
One last role cannot be shared: a single owner of the migration, who holds the paths, the order of the waves, the data plan and the cutover criteria. Without one, each team migrates its own way, and the cost of the inconsistencies adds to all the others.
How to build a budget that holds
- Start from a real inventory, applications, dependencies and contracts included, rather than a list of servers.
- Price one path per application, with the target run cost in the cloud next to today's cost.
- Budget for parallel running over the planned length of the waves, with a margin.
- Put a value on internal time, even if nobody invoices it: it is what shifts the schedule.
- Align cutovers with terminations, so you do not pay for an empty datacentre.
- Plan cost optimisation from the first month after cutover, as a step of the migration and not a later project.
Where to start
A free cloud audit sets out the inventory and the first estimate of the paths. For an estate still hosted on premises, our page on moving a datacentre to the cloud describes the method. And if the question is what operations will cost once the cutover is done, the page on managed-services costs sets out the billing models.