Most cloud migrations that fail were not beaten by the technology. They were beaten by the order the work happened in: a dependency nobody mapped, a cost model built on estimated usage, or security configured after go-live.
That is a planning problem, and planning problems are cheap to solve in advance and expensive to solve halfway through. This piece covers where migrations come unstuck, what to ask of whoever runs yours, how the work should be sequenced, and where to start.
Five failure modes account for most of it, and they repeat across industries and platforms.
Moving without a full dependency map. Applications do not run in isolation. A workload that looks straightforward often calls a database, an authentication service, or a third-party API that has to move or be reconfigured alongside it. Finding that out mid-migration is the expensive way to learn it.
A cost model built on estimates. Cloud costs move with usage. Compute, storage, data egress, and licence fees all vary, and a migration costed against assumed usage can produce a monthly bill that surprises the finance director who approved it more than anyone else. Cost modelling belongs before the move, and our guide to Microsoft cloud cost optimisation covers how to build one.
Security configured afterwards. Default cloud configurations are not secure configurations. Access controls, network segmentation, encryption in transit and at rest, and logging all have to be set deliberately. A migration that moves fast and secures later opens a window of exposure that is hard to size and harder to explain to a regulator.
No tested rollback. Every phase needs a defined position to return to. Organisations that skip this find out why it mattered at the worst possible moment.
Treating it as an IT project. The technical move is the visible part. What generates the complaints is usually the part nobody briefed: a finance team that loses a mapped drive, or a shared mailbox that quietly changes address. Someone has to own the communications plan, and it is rarely the engineer running the cutover.
Ask how they sequence the move before you ask what they charge. Price is easy to compare and tells you almost nothing about risk.
A cloud assessment before any migration work. A partner who goes straight to migration is not managing your risk, they are transferring it to you. The assessment is where sequencing, cost modelling, and architecture decisions get made.
Vendor-agnostic advice. AWS, Azure, and Google Cloud each have strengths. The right answer depends on your existing environment and the workloads in scope, so a partner with a commercial reason to prefer one platform is not giving you an objective view.
A named project lead. Migrations generate decisions daily. You need one person who knows your environment and your risk tolerance, rather than a queue where every query starts again from scratch.
An answer on the estate they are not touching yet. A partial migration that leaves half the environment unmanaged is one of the more common sources of the failures above.
Post-migration optimisation inside the scope. A migration that ends at go-live is half-finished. Cost and security both need reviewing once the environment is carrying real load, which is the point a migration turns into an ongoing improve efficiency programme.
What a good answer sounds like: they can name the workloads they would move first and explain why those ones, and they can describe the rollback position at each stage without going away to check. A partner who answers in platforms rather than in order has not looked at your environment yet.
We would say all of that, being one. Ask us the same questions.
Four phases, each one gating the next.
Assessment maps what exists: every application, its dependencies, its data flows, and what it currently costs. It identifies which workloads should move, which should stay where they are, and which need work before either. Our earlier piece on cloud suitability for UK businesses sets out that decision framework.
Architecture design defines the target state. Which platform or platforms, how the network is structured, how security is implemented, and what the cost model looks like. The migration approach for each workload is confirmed here.
Phased migration moves workloads in an order that manages risk. Lower-complexity applications go first, business-critical ones only once the process has been shown to work. Each phase is validated before the next begins.
Optimisation reviews cost, performance, and security against actual production load. Right-sizing resources and closing gaps found under real conditions is part of the job.
Assessment is the phase organisations most often try to compress, and it is the one worth protecting. On a mid-sized estate it runs to a few weeks rather than a few days, and every later decision depends on what it produces.
When Invicro consolidated its Microsoft 365 environment across operations in the UK and the United States, the migration ran over a single weekend with no disruption to users in either country. Two separate tenants became one, data residency was maintained, and branding was consolidated under a single domain. That was possible because assessment and architecture were finished first. The migration itself was execution.
"Our user experience across the organisation has improved dramatically since we engaged with the Highgate and CNNECT teams. They were great to deal with and delivered against all expectations set out at the start of the project." – Imran Araf, IT Manager (Invicro)
Three approaches cover most workloads, and a typical programme uses all of them.
Lift and shift moves an application to cloud infrastructure with minimal change. It is the fastest to execute, and the most likely to produce a cloud bill higher than the on-premises alternative, because the application was never designed around cloud cost models.
Re-platforming makes targeted changes to use cloud capabilities, such as moving a database onto a managed service, without rewriting the application. More work upfront, better cost efficiency and resilience afterwards.
Re-architecting rebuilds the application to run natively in the cloud. It is the highest effort, and it gets the most out of the platform. It earns its place on business-critical applications where long-term cost or resilience justify the investment.
The assessment determines which approach applies to which workload. It is the first thing we do on any cloud and infrastructure engagement.
Data in transit is the point most project plans underweight.
Encrypt everything in transit. UK GDPR requires personal data to stay protected for the whole of a transfer between environments, including the moments it is in flight.
Keep access controls active in both the source and destination environments for the entire migration window. Broadening access to make a transfer easier and then failing to close it down afterwards is a routine post-migration audit finding.
Validate data integrity at every phase. Confirming that what arrived matches what left costs far less between phases than after completion.
Know where the platform's responsibility ends. The major cloud platforms all secure the infrastructure they run. Configuring what you put on top of it stays with you. Migrations often carry an unspoken assumption that moving to a major platform is itself a security upgrade, and it is only that if someone configures it to be.
Confirm the business resilience posture of the new environment before the old one is decommissioned. Backup, tested recovery procedures, and incident response all need to be in place and tested.
The migrations that go smoothly are the ones where assessment is taken as seriously as the move. Almost every organisation we meet that has had a bad migration previously went through assessment quickly and paid for it later, usually because the dependency map was incomplete, the cost model was optimistic, or security came last.
A cloud assessment covers your current infrastructure and what it costs to run today, then produces a target architecture with a sequenced plan. It is where most organisations discover the project is either larger or smaller than they assumed. It is also where we start every engagement, through our cloud and infrastructure services, as part of a wider improve efficiency programme covering cost optimisation and infrastructure health.
We work this way with organisations across the UK. Assessment and sequencing run remotely, and on-site time gets booked for the parts that need someone in the room, such as a data centre decommission or a stakeholder workshop early in scoping.
Half an hour with an engineer before you commit to a sequence is the cheapest insurance a migration can have. We will tell you what to check, whether or not you work with us.
