Why cloud migrations overrun, and how to avoid it
Staying put gets harder every year. IT staff are harder to recruit for ageing hardware, and clients and regulators expect resilience you cannot easily evidence from a cupboard full of servers.
Moving badly is worse than not moving at all. We are often called in after a migration has gone wrong: email outages, missing files, applications that stopped working because nobody tested them in the new environment. None of that is a technology problem. It is a planning problem.
If you are working toward ISO 27001 or another framework, that planning matters twice over — the migration documentation becomes your evidence.
The cloud migration runbook, written before anything moves
Every migration starts with an assessment. We document what you run today: servers, applications, data volumes, dependencies and integration points. Then we agree what moves, what stays on-premise and what should be replaced rather than carried over.
From that, we write the runbook. It covers every workload, every user and every risk, with testing milestones, rollback procedures and a communication plan for your team. Nothing moves until you have reviewed and approved it.
Azure migration is our most common engagement. File servers go to SharePoint and OneDrive. Email goes to Exchange Online through our Microsoft 365 management services. Line-of-business applications go to Azure Virtual Machines or App Services, and backups go to geo-redundant cloud storage. Where you have specific compute or AI requirements, we deploy on AWS instead.
Azure or AWS: choosing on what you already own
Most London firms asking this question already have the answer in their existing stack. The decision is rarely about raw capability — both platforms will run your workloads — and almost always about what you already own and who has to support it.
| Your situation | Usually the right call | Why |
|---|---|---|
| Already on Microsoft 365, Entra ID, Windows Server | Azure | Single identity, single admin console, licence portability (Azure Hybrid Benefit) cuts VM cost materially |
| Heavy Linux, containers, or a dev team already using AWS tooling | AWS | Deeper container and serverless maturity; your engineers stay productive |
| GPU or AI workloads with variable demand | Either, priced per workload | Availability and spot pricing differ month to month in the UK regions |
| Trading or low-latency systems | Hybrid, often neither | Colocation near the exchange usually beats both on latency |
| Under FCA or DORA scrutiny | Azure, typically | Not technically superior — but the audit trail and UK data residency story is easier to evidence |
In practice, platform choice matters less than migration discipline. We are certified on both, so we can weigh the decision against the estate you already run.
What a cloud migration actually costs
Migration cost is dominated by labour and complexity, not licences — though the July 2026 Microsoft 365 price rise has changed the recurring side of that equation, so budget against your renewal date rather than last year’s invoice. For a 50-person London firm, a straightforward lift-and-shift of file servers, email and one or two line-of-business applications typically runs £8,000–£20,000 in project work, spread across 4–8 weeks.
What moves that number:
- Application count and age. Three modern applications are simple. One custom-built 2009 system with no vendor support is often more work than everything else combined.
- Data volume and shape. Two terabytes of files migrate fine. Two terabytes with 400-character paths, duplicate permissions and twelve years of nested shares does not.
- Identity debt. If Active Directory has never been cleaned up, that cleanup is part of the migration whether you budget for it or not.
- Downtime tolerance. Weekend cutovers with parallel running cost more than a Friday-night switch. Regulated firms usually need the former.
Ongoing cloud spend is the number people underestimate. Unmanaged Azure and AWS environments routinely run well above what they need, because nothing gets switched off and nothing gets right-sized. That waste recurs every month, which makes it worth more attention than the one-off migration saving.
Six failures that break cloud migrations
These are the failure modes we are most often called in to fix after a migration has gone wrong:
- Nobody tested the line-of-business application. Email and files move cleanly. The practice management or portfolio system is the one that breaks, and it is discovered on Monday morning.
- Permissions were migrated as-is. Twelve years of accumulated folder permissions get copied into SharePoint, and suddenly everyone can see the payroll folder. This is also the single most common way a Copilot rollout leaks data.
- No rollback plan. The cutover fails at 2am and there is no tested route back to the old environment.
- Licensing was an afterthought. Firms pay for Azure VMs at full rate when Hybrid Benefit would have applied, or buy per-user licences they already owned.
- Bandwidth was not checked. A 500GB initial sync over an office connection that also carries Teams calls does not end well.
- The old servers stayed on. Decommissioning slips, and the firm pays for both environments for months.
Every one of these is a planning failure, not a technology failure. That is why the runbook exists.
How long a cloud migration takes, phase by phase
| Phase | Typical duration | What happens |
|---|---|---|
| Assessment | 1–2 weeks | Full inventory of servers, apps, data, dependencies and identity |
| Design and runbook | 1–2 weeks | Target architecture, migration sequence, rollback procedures, comms plan |
| Pilot | 1 week | A representative group of users moved and monitored before anyone else |
| Bulk migration | 2–4 weeks | Data pre-seeded and synced; users moved in waves |
| Cutover | 1 weekend | Final sync and switchover, typically under 30 minutes of user-visible downtime |
| Hypercare | 2 weeks | Elevated support, issue triage, decommissioning of old infrastructure |
Larger or more regulated environments stretch the assessment and pilot phases rather than the cutover. Complex migrations run 3–6 months in total.
Where your data sits, for DORA and ISO 27001
For FCA-regulated firms, DORA turned cloud concentration risk into a board question rather than an IT one. You now have to evidence where data physically sits, what happens if the provider has an outage, and how you would leave that provider if you had to.
We deploy into UK regions by default and document the data flows as part of the migration pack. We also check that your provider contracts carry the exit and audit clauses your regulator expects to see.
If you are working toward ISO 27001, that same documentation doubles as Annex A evidence. Producing it during the project costs far less than reconstructing it a year later.
Hybrid cloud for regulated workloads
Many of our financial services clients, particularly private equity firms and asset managers, cannot move everything. Data sovereignty rules, legacy trading platforms and low-latency connections keep some workloads on-premise or in a London colocation facility.
We design hybrid architectures that give you the cloud where it helps and local control where you need it. Azure Arc and site-to-site VPN tunnels keep the whole estate connected and manageable from one console.
Cloud cost and security after go-live
Migration is the beginning, not the end. We monitor your cloud environment continuously, manage patching and updates, tune costs and keep your security posture current as threats change.
Our backup and disaster recovery service keeps those cloud workloads protected and recoverable. Every month you get a report showing spend, utilisation and what we recommend next — no surprises. For the wider argument, read what IT downtime actually costs.