Cloud migration cost is the number that decides whether a move to the cloud is judged a success or an embarrassment, and it is almost always quoted too low. Not dishonestly — quietly and structurally, because the figure a supplier puts on a slide covers the act of moving servers and very little else. The real total also includes the discovery work before anything moves, the parallel running while two estates stay alive, and the twelve months afterwards when nobody has switched the old kit off.
This guide is written for UK businesses planning a move in 2026 or 2027, and it deliberately avoids the marketing arithmetic. You will find realistic budget bands by company size, a phase-by-phase timeline you can put in front of a board, the expenses that never appear in the original estimate, and the levers that actually reduce spend rather than just deferring it.
The pressure to move is real. Windows Server 2016 leaves extended support on 12 January 2027, Broadcom’s VMware licensing has reset renewal quotes for thousands of UK firms, and the hardware bought during the 2020 remote-working scramble is now six years old. Those three deadlines are converging, which means a lot of organisations are about to price a migration programme under time pressure, often before the wider cloud migration plan has been agreed. That is precisely when budgets get set badly.
Table of contents
- Why Cloud Migration Cost Is So Hard to Pin Down
- The Six Buckets Inside Every Cloud Migration Cost
- Cloud Migration Cost Benchmarks for UK Businesses
- A Realistic Migration Timeline, Phase by Phase
- Hidden Expenses That Wreck a Cloud Migration Cost Estimate
- The Bills Nobody Quotes: Egress, Licensing and Support
- How to Build a Cloud Migration Cost Model You Can Defend
- Questions That Expose a Weak Cloud Migration Cost Estimate
- Nine Levers That Genuinely Reduce Cloud Migration Cost
- Cloud Migration Cost Mistakes UK Businesses Keep Repeating
- Frequently Asked Questions About Cloud Migration Cost
Why Cloud Migration Cost Is So Hard to Pin Down
Cloud pricing is transparent to the penny and almost useless as a planning tool. You can look up the hourly rate of any virtual machine in seconds, but nobody can tell you how many of them you will need until the workloads are running under real load. That gap between published rates and actual consumption is where most estimates fall apart.
The quote covers the move, not the change
A migration quote prices a defined scope: so many servers, so many mailboxes, so many terabytes. It does not price the application changes that make those workloads behave properly once they land, and it rarely prices the operating-model shift underneath. Your team stops racking hardware and starts managing consumption, identity and policy. That is a change management exercise with a real cost attached, and it is almost never in the original number.
Your current bill is not your baseline
Most businesses compare a cloud quote against what they think on-premises costs, and that comparison is usually flattering to the old estate. The on-premises figure often omits floor space, power, cooling, the refresh sinking fund, the hypervisor licences and the engineer time spent on patching. Until you build an honest total for the current on-premises data centre, any cloud migration cost you calculate is being measured against a number that is too low.
Two estates, one budget
For a period measured in months, you pay for both. The old servers keep running because something still depends on them, and the new platform is live because users have already been moved. Every credible cloud migration cost model has a dual-running line in it. Leaving that line out is the single most common reason a project that looked affordable in January is over budget by June.
The Six Buckets Inside Every Cloud Migration Cost
Break the number into buckets and it stops being a guess. Almost every UK migration, from a five-server SME to a regulated mid-market business, spends money in the same six places. The proportions shift, but the buckets do not.
Discovery and assessment
Two to six weeks of dependency mapping, application inventory and consumption profiling. Expect £2,000 to £12,000 depending on estate size. Skipping this is the fastest way to double your eventual cloud migration cost, because unmapped dependencies surface mid-wave when the fix is most expensive.
Landing zone and platform build
Networking, identity, subscription structure, policy guardrails, logging and backup. This is where your future cybersecurity posture is decided, and it is a one-off build of roughly £4,000 to £30,000. A rushed landing zone gets rebuilt within eighteen months, which is a cost you pay twice.
Workload movement
The part everyone thinks of as the migration: replication, cutover, testing, rollback plans. Priced per workload rather than per server, typically £400 to £2,500 each. A straightforward file server sits at the bottom of that range; a clustered database with a strict recovery objective sits at the top.
Application remediation
Old applications rarely move cleanly. Hard-coded IP addresses, licence keys tied to hardware, and dependencies on protocols that no longer belong on an open network all need fixing. This bucket has the widest variance of any part of the cloud migration cost and is the one most often discovered late.
Parallel running and dual licensing
Both estates live at once, and in many cases both are licensed at once. Budget three to six months of overlap. For a mid-sized estate that overlap alone can reach £15,000, and it is entirely predictable if you plan for it.
Run-state optimisation
The first ninety days after go-live, when consumption is measured, resources are right-sized and commitments are bought. Treat this as funded work rather than something the team will fit in. Businesses that skip it typically overspend by 25 to 40 per cent in year one.
Cloud Migration Cost Benchmarks for UK Businesses
Published benchmarks vary wildly because they compare different scopes. The bands below assume a full engagement — discovery, landing zone, movement, remediation and ninety days of optimisation — priced at UK market rates rather than offshore rates.
Under 50 staff, a handful of servers
A business with four to eight servers, a file share, a line-of-business application and Microsoft 365 already in place should expect a one-off cloud migration cost of roughly £12,000 to £35,000. Monthly run-rate afterwards typically lands between £600 and £2,500. The dominant variable is not the number of servers but whether the line-of-business application will run on a modern operating system.
50 to 250 staff with line-of-business applications
This is the band where estimates break down most often. Twenty to sixty workloads, at least one database that matters, and usually a bespoke application nobody fully documented. Realistic range is £35,000 to £120,000 one-off, with £2,500 to £12,000 per month afterwards. Remediation and parallel running together often account for half the total.
250 plus staff and regulated data
Financial services, healthcare and legal firms carry evidence obligations that add genuine cost rather than paperwork. Data residency decisions, audit logging, encryption key management and a documented exit plan all sit inside the cloud migration cost. Budgets here start around £120,000 and rise quickly. Firms holding ISO 27001 certification will need their statement of applicability revisited as part of the move.
A Realistic Migration Timeline, Phase by Phase
Timelines slip for predictable reasons: discovery finds more than expected, a supplier contract has a notice period nobody checked, or a single application blocks an entire wave. The schedule below is deliberately unhurried, because compressed migrations cost more, not less.
Weeks one to six: discovery and design
Inventory every workload, map dependencies, profile consumption and agree the target architecture. Nothing moves in this phase and it is the phase most often cut. It is also where the accuracy of your entire budget is determined.
Weeks four to ten: landing zone build
Networking, identity federation, policy, monitoring, backup and the first non-production workload. Overlaps with discovery deliberately. By the end of this phase you should be able to deploy a workload and see it appear in logging and backup without anyone touching a console.
Weeks eight to twenty: migration waves
Move in waves grouped by dependency, not by convenience. Start with the workloads that fail safely — internal file shares, test environments, reporting servers. Keep the highest-risk application for a wave of its own, with a rehearsed rollback. Most mid-sized UK estates run four to six waves.
Weeks twenty to thirty: decommission and optimise
Switch the old estate off, cancel the circuits and licences it consumed, and start the optimisation cycle. Decommissioning is a task with an owner and a date, not an assumption. The savings case in your business plan does not begin until this phase completes.
These are the items that turn a well-planned budget into an awkward board conversation. None of them are exotic. All of them are routinely left out.
Egress charges on the way out
Moving data out of an existing cloud or hosting platform is charged per gigabyte. As of mid-2026 the major hyperscalers still list internet egress around $0.09 per GB, so a 40 TB estate leaving a public cloud carries a four-figure transfer bill before a single workload runs anywhere. Free-exit programmes exist but require notice, approval and completion inside sixty days.
Licence mobility and Windows Server
Licences bought for physical hardware do not always travel. Windows Server, SQL Server and many third-party products price differently on shared infrastructure, and Software Assurance or a hybrid benefit is often the only thing that keeps the numbers sane. Check this before the design is fixed, because it changes which instance families you should buy.
Backup, disaster recovery and the second copy
Cloud platforms protect their infrastructure, not your data. Backup, retention and a tested recovery path are separate purchases, and for anything with a real recovery objective a second copy in a second region is not optional. This routinely adds 10 to 20 per cent to the monthly run-rate and belongs inside the cloud migration cost from day one.
Skills, training and the new operating model
Your team needs to learn a different discipline. Budget training, certification time and a period of lower productivity while people build confidence. Some organisations bridge this with co-managed support rather than hiring; either way it is a real number, and pretending otherwise simply moves the cost into overtime and staff turnover.
The Bills Nobody Quotes: Egress, Licensing and Support
Three recurring charges deserve their own scrutiny because they are structural rather than one-off, and because they are the charges most likely to change during the life of your contract.
Data transfer out is priced per gigabyte
Inbound data is generally free; outbound is not. Any architecture that regularly pulls large volumes back on-premises, or serves heavy media to users, will accumulate egress. Model it against real traffic figures rather than a guess, and design to keep chatty workloads on the same side of the boundary.
The switching rules are changing
The regulatory direction of travel is towards free switching. The EU Data Act removes cloud switching and egress charges outright from January 2027, and the UK competition authorities have been examining the same behaviour. Providers have already begun waiving exit fees under conditions. Write a clause into your contract now rather than assuming today’s terms will still apply in three years.
Support plans are a percentage, not a line item
Enterprise support from a hyperscaler is typically priced as a percentage of monthly consumption, which means it grows silently as you grow. Decide early whether you are buying that support directly or through a partner, because the difference over three years is material and it is rarely in the original cloud migration cost comparison.
How to Build a Cloud Migration Cost Model You Can Defend
A defensible model survives contact with a finance director. It shows the assumptions, separates one-off from recurring, and states plainly what would have to be true for the number to be wrong.
Start from a workload inventory, not a server list
Servers are an implementation detail. Workloads are what the business actually pays for, and they are what you will migrate, test and cut over. A workload inventory also exposes the applications that should be retired rather than moved, which is the cheapest saving available anywhere in the project.
Model three years, not twelve months
Cloud economics are back-loaded. Year one carries the migration spend and an unoptimised run-rate; years two and three carry the savings. A twelve-month model makes almost every migration look poor. Three years is the minimum honest horizon and matches the commitment terms you will be offered.
Separate one-off from run-rate
Keep project spend and consumption spend in different columns and never blend them into a single monthly figure. Blending is how businesses end up believing the run-rate is permanently higher than it is, and it makes the post-migration savings impossible to demonstrate.
Put contingency in writing
Fifteen per cent on a well-discovered estate, 25 per cent where legacy applications are involved. A named contingency that is visible and governed gets spent carefully. An unnamed one gets spent anyway, without anyone deciding to.
Questions That Expose a Weak Cloud Migration Cost Estimate
Comparing two proposals side by side is difficult because they rarely price the same scope. These questions surface the difference quickly, and a supplier who answers them clearly is usually the one whose number will survive.
What is explicitly out of scope?
Ask for the exclusions in writing. Application remediation, third-party licence uplift, out-of-hours cutover work and post-migration support are the four items most often quoted separately later. A cheaper proposal is frequently the same proposal with more exclusions, and the eventual cloud migration cost converges once those items reappear as change requests.
How many months of parallel running are assumed?
If the answer is a number, the supplier has thought about it. If the answer is a shrug, you have found the gap that will consume your contingency. Dual running is the most predictable overrun in any cloud migration cost estimate and the easiest to price honestly.
What consumption assumptions sit behind the monthly figure?
The monthly run-rate should be traceable to measured CPU, memory, storage and egress, not to a spreadsheet of like-for-like instance sizes. Ask which workloads were profiled and for how long. A run-rate derived from a week of sampling in a quiet month will be wrong by the time the invoices arrive.
Who owns the decommissioning plan?
Someone must switch the old estate off, cancel its circuits and end its maintenance contracts. If that work is not in either party’s scope, it will not happen, and the savings half of the business case never lands.
Nine Levers That Genuinely Reduce Cloud Migration Cost
Not every saving is real. Some simply move spend from one budget line to another. These are the levers that hold up when the invoices arrive, and most of them make the biggest difference when applied before the move rather than after it.
Right-size before you move, not after
Physical servers were bought for peak load five years ago and are usually two to four times larger than they need to be. Profile actual CPU, memory and disk over a full month and provision for that. Rehosting an oversized server as an oversized instance simply converts wasted capital into a permanent monthly charge, which is the single most expensive mistake in the whole cloud migration cost picture.
Retire and consolidate instead of rehosting
Most estates contain workloads nobody needs. Reporting servers that duplicate a live system, test environments abandoned two years ago, applications with three users who have a better alternative. Every one you retire removes migration effort, licence cost and run-rate simultaneously.
Use reservations and savings plans deliberately
Commitment discounts of 30 to 60 per cent are available, but only for steady-state workloads you are confident about. Buy them after ninety days of measured consumption, not on day one, and stagger the terms so you are not renegotiating everything in the same quarter.
Claim the migration funding you are entitled to
The major providers operate partner-led funding programmes that can offset a meaningful share of assessment and migration effort. Most smaller UK businesses never claim them because the process runs through a partner and nobody asks. Ask before the engagement starts — it cannot be applied retrospectively.
Fund ninety days of cloud cost optimisation
Treat the first quarter after go-live as funded engineering work: right-size, schedule non-production shutdowns, tier storage, remove orphaned disks and unattached addresses. Businesses that formalise cloud cost optimisation as a named workstream consistently land 20 to 30 per cent below those that leave it to goodwill.
Cloud Migration Cost Mistakes UK Businesses Keep Repeating
These patterns show up again and again in post-migration reviews. They are cultural and contractual rather than technical, which is why better engineering alone does not prevent them.
Treating it as an infrastructure project
A migration that is owned entirely by IT will move the servers and change nothing else. The savings and the resilience benefits come from decommissioning, from process change and from retiring what is no longer needed — and none of those are within an infrastructure team’s authority to decide alone. This is a digital transformation exercise with an infrastructure component.
Signing a three-year commitment on day one
Commitment discounts are attractive and the sales cycle encourages you to lock in early. Before you have run a single month at real load, you do not know what to commit to. Committing to the wrong instance family for three years costs far more than the discount saves.
Leaving the old estate running
Decommissioning is unglamorous, nobody is measured on it, and there is always a reason to wait one more month. Six months later the old kit is still powered, still licensed and still in the maintenance contract. Put a date and an owner against every decommission before the first wave starts.
No owner for spend after go-live
Consumption without ownership grows. Somebody needs a monthly report, the authority to act on it and a target to hit. Without that, the year-one overspend becomes the year-two baseline and the business case quietly disappears. Sound data protection and access governance need the same continuous ownership, for the same reason.
Frequently Asked Questions About Cloud Migration Cost
How much does cloud migration cost for a small UK business?
For a business under fifty staff with a handful of servers, budget £12,000 to £35,000 one-off and £600 to £2,500 per month afterwards. The main variable is whether your line-of-business application runs cleanly on a supported platform or needs remediation first.
How long does a migration actually take?
Six to eight months end to end for a typical mid-sized UK estate, including decommissioning. Discovery is four to six weeks, the landing zone build overlaps it, migration waves run over three months, and the final phase is switching the old environment off.
Is cloud always cheaper than on-premises?
No. On a pure like-for-like rehost with no right-sizing, cloud is frequently more expensive. It becomes cheaper when you retire redundant workloads, right-size properly, use commitment discounts and stop buying hardware refresh cycles. The saving is earned, not automatic.
What is the biggest hidden cloud migration cost?
Parallel running. Paying for two estates for longer than planned quietly consumes the contingency, and because it accrues weekly rather than as a single invoice it rarely triggers an escalation until it is large.
Should we lift and shift first, or refactor?
Rehost the workloads where the platform is the problem and modernise the ones where the application is the problem. A blanket policy in either direction wastes money — refactoring everything delays the deadline, and rehosting everything imports every existing inefficiency onto a meter.
Who should own the budget after go-live?
One named person with a monthly consumption report and the authority to change resources. The NCSC’s cloud security guidance makes the same argument for security ownership, and the reasoning is identical: shared responsibility without a named owner becomes nobody’s responsibility.
