Introduction
Somewhere in the last two years, cloud migration stopped being a question of if and became a question of how badly are we doing this. Across UK enterprises, boardrooms have signed off on migration programmes that are running over budget, behind schedule, or both -often because the initial planning treated it as a purely technical exercise.
If you’re a CTO, IT Director, or operations leader currently evaluating a cloud migration or trying to rescue one already in motion, this piece is for you. Not a primer on what the cloud is -you know that. This is about the parts that actually go wrong, what they cost, and how to make better decisions from the outset.
Why Cloud Migration Projects Underestimate the Real Cost
The cloud migration cost UK businesses actually incur rarely matches what was on the business case slide. Not because vendors are dishonest -though opaque pricing doesn’t help -but because most cost estimates focus on infrastructure and ignore everything around it.
The visible costs are well-understood: compute, storage, data transfer, licences. The real problem sits in everything that surrounds them.
Legacy application estates in most UK enterprises weren’t built to run in the cloud. They were built to run on-premises, often over a decade or more, with assumptions baked into the architecture -about network latency, file system access, session handling -that simply don’t hold in a cloud environment. Refactoring even a moderately complex application to be cloud-native can take months of engineering time, and it’s rarely scoped accurately at the outset.
Then there’s data. Moving large volumes of data between environments costs money in egress fees, takes longer than expected, and often surfaces compliance questions -particularly around UK GDPR -that nobody had fully mapped before the project started.
Labour is usually the biggest hidden cost. Skilled cloud engineers are expensive and in short supply. If your internal team lacks deep cloud expertise, you’re either paying premium day rates for contractors or you’re learning on the job, which carries its own cost in mistakes and delays.
What Does Cloud Migration Actually Cost for a UK Enterprise?
There’s no honest single answer to this, and anyone who gives you one without understanding your environment is guessing. But there are useful ranges.
For a mid-size UK enterprise -say, 300 to 1,000 users, with a mix of on-premises infrastructure, a handful of legacy applications, and some SaaS already in place -a full migration programme typically runs anywhere from £200,000 to over £1 million. Larger organisations with complex, regulated environments can spend significantly more.
The split tends to look roughly like this:
- Professional services and implementation: 40–50% of total programme cost
- Application refactoring and remediation: 20–30%
- Data migration and validation: 10–15%
- Training, change management, and internal resource time: 10–20%
- Ongoing cloud spend post-migration: variable, but often higher than projected in year one
That last point deserves attention. Many organisations find their cloud spend in the first 12 months exceeds their on-premises costs, not because the cloud is more expensive per se, but because reserved instances haven’t been optimised, unused resources haven’t been decommissioned, and the FinOps discipline hasn’t been embedded yet.
The Risks That Derail Programmes
Cost overrun is often a symptom of something else. The underlying causes are usually one of the following.
Scope That Grows Without Anyone Noticing
Cloud migrations have a way of expanding. You start with a defined set of workloads, then someone in security flags a dependency you hadn’t mapped. A compliance team raises questions about data residency. An application owner surfaces a third-party integration that isn’t cloud-compatible. Each item feels small in isolation. Collectively, they add weeks and significant cost.
This isn’t a reason to avoid migration -it’s a reason to invest properly in discovery before committing to a fixed timeline or budget.
Security and Compliance Exposure During Transition
The period between decommissioning on-premises infrastructure and fully bedding in cloud security controls is when organisations are most exposed. In regulated sectors -financial services, healthcare, legal -this window carries real risk. Misconfigured cloud storage, incomplete IAM policies, and gaps in audit logging have all led to data incidents during migration programmes.
UK GDPR obligations don’t pause during a migration. Neither do FCA or ICO expectations for organisations under those frameworks.
Underestimating the Human Side
This is the one that catches organisations most off guard. Staff who have used the same systems for years need retraining. IT teams need upskilling. Processes that worked on-premises need rethinking. If change management is treated as an afterthought -a few webinars and a communication email -adoption suffers, and so does productivity in the months after go-live.
Realistic Timelines: What to Plan For
A common mistake is planning cloud migration like a software deployment -a defined end state, a fixed delivery date. In practice, migration is a programme with phases, dependencies, and decision points that shift based on what you find.
For a mid-size enterprise, a reasonably scoped migration programme typically runs 12 to 24 months end to end. That includes discovery and planning (often 2–3 months and frequently under-resourced), the migration itself in waves, a period of parallel running, and a stabilisation phase post-cutover.
Faster is possible -particularly for organisations with simpler environments or those migrating to a lift-and-shift model rather than re-architecting. But lift-and-shift has its own trade-offs: you move the problem rather than solve it, and you often don’t realise the cost or performance benefits that justified the business case.
Any programme planning for under six months for a complex enterprise environment should be treated with scepticism unless the scope has been very clearly bounded.
Common Mistakes Worth Calling Out
These come up repeatedly, across industries and organisation sizes.
Treating the cloud provider’s migration assessment as the plan. AWS, Azure, and Google all offer migration tooling and assessment services. These are genuinely useful. They are also, understandably, oriented toward getting workloads onto their platform. They won’t tell you whether this is the right time to migrate, which applications should be retired rather than moved, or how to manage the organisational change. That thinking has to come from you or a genuinely independent adviser.
Migrating everything. Not every workload belongs in the cloud. Some applications are end-of-life and should be retired rather than lifted. Some are deeply integrated with on-premises hardware that makes migration disproportionately complex. A migration programme should include a clear rationalisation exercise -not just a mapping of what exists, but a decision about what should actually move.
Underinvesting in post-migration optimisation. The go-live is not the finish line. Cloud environments require ongoing management: cost optimisation, security posture reviews, performance tuning. Organisations that don’t plan for this phase often find their cloud spend drifts upward and the expected benefits don’t materialise.
Conflating speed with progress. Pressure from senior stakeholders to show quick wins can push teams to cut corners on architecture decisions, security controls, or testing. Those shortcuts tend to be expensive to fix later.
A More Grounded Approach to Planning
If you’re at the early stages of evaluating a migration, or trying to reset a programme that’s already in trouble, a few principles hold consistently.
Start with a rigorous discovery phase. Before any workloads move, you need an accurate picture of your current environment -applications, dependencies, data flows, compliance obligations, and technical debt. The quality of your discovery directly determines the reliability of your cost and timeline estimates. Skimping here is the most reliable way to guarantee a difficult programme.
Define what success looks like before you start. Is the goal cost reduction? Scalability? Exit from a data centre? Each objective leads to different architectural decisions and different trade-offs. Migrations that try to achieve everything simultaneously tend to achieve nothing well.
Plan in waves, not a single big bang. Migrating everything at once amplifies risk. A phased approach -typically starting with lower-risk, less-complex workloads -builds team experience and confidence, surfaces issues at a manageable scale, and gives the business time to adapt.
Build FinOps capability early. Cloud cost management is a discipline, not a dashboard. The organisations that control their cloud spend are the ones that embed cost accountability into engineering teams from the beginning, rather than bolting on a cost review six months after go-live.
Retain independent oversight. Whether that’s an internal programme director or an external partner, someone on your side needs to be asking the difficult questions -about scope, about risk, about whether the programme is actually on track. That role is different from the delivery team, and it matters.
Where Carmatec Fits
Carmatec Digital UK works with enterprise organisations across the UK on cloud migration programmes -from initial strategy and discovery through to delivery and post-migration optimisation. The work isn’t templated; it’s shaped around the specific environment, constraints, and objectives of each organisation.
For businesses evaluating whether to migrate, trying to build an honest business case, or looking to course-correct a programme that’s drifted, the starting point is usually a structured assessment of what’s actually there and what a realistic programme looks like. That conversation is typically more useful than a proposal.
Closing Thoughts
Cloud migration done well is genuinely transformative for enterprise organisations -in terms of operational flexibility, resilience, and long-term infrastructure cost. Done poorly, it’s expensive, disruptive, and difficult to recover from.
The gap between those two outcomes usually isn’t technical. It’s in the quality of planning, the honesty of the business case, and the discipline of execution. Most of the organisations that struggle with migration had the right technology choices -they just underestimated what it would actually take to get there.
The cloud migration cost UK enterprises should be planning for is not just a number on a spreadsheet. It’s a reflection of how seriously the programme was scoped and how realistically the risks were understood from the start.
Ready to assess your current infrastructure and build a realistic migration plan? Speak with the Carmatec team to start the conversation.
