Cloud migration and the service wrapped around it
Cloud migration is the movement of applications, data, workloads and the infrastructure under them out of on-premises or legacy environments. It takes in movement between clouds as well, and movement from one cloud service model to another, as CACI explains in its 2026 guide to migration risks and strategy. A cloud migration service is the commercial wrapper around that movement: assessment, design, execution, testing, and the operating model that remains once the temporary effort is packed away.
A service that deals only with the cutover is not a migration service. BCN lays out its own process as five stages: assessment, design, migration, testing and evolve. That sequence is useful as a skeleton, because it forces a provider to say what it delivers at each point, and it shows where the selling gets thin. Evolve is the period after cutover when the environment is right-sized and the security posture reviewed, and it is the first thing to disappear when a fixed-price bid is squeezed.
Placement is decided workload by workload
The NHS Cloud Centre of Excellence, in its cloud migration guidance, says plainly that cloud-first does not mean the whole data centre moves, and that on-premises stays the right choice where cloud computing cannot meet a regulatory or latency requirement. The same guidance requires an assessment of each workload against three attributes before placement: risk, technical fit and value. Risk is how much damage a move that goes wrong would do. Technical fit takes in operating systems, licensing, whether the application keeps session data between requests, and the changes needed to run in cloud. Value is business criticality, and therefore how much transformation spend the workload justifies.
We treat that three-attribute assessment as the minimum bar. A provider that opens with a target architecture and a fixed cutover day, and reaches the workload register later, has the order backwards.
A placement record should contain all of it, one entry per workload, and it should be readable by whoever will run the rollback:
workload: claims-processing-api
service-team: digital-operations
risk-score: 3 # 1 low, 5 severe; fixes the order of tranches
technical-fit: partial # as-is, partial, or needs redevelopment
value: tier-1 # tier-1 to tier-3 business criticality
dependencies:
- billing-oracle-19c
- identity-broker
approach: replatform
target-tier: paas
regulatory-constraints:
- uk-gdpr
- fca-operational-resilience
rollback: blue-green with 30-minute drain
Five routes, and the cloud tier each one reaches
These five routes are the working vocabulary of the subject. The NHS Cloud Centre of Excellence guidance aligns them to cloud tiers and adds that the alignment is a tendency rather than a rule: a re-architecture can still land on infrastructure as a service where no platform meets the regulatory requirement.
| Route | What changes | Usual target tier |
|---|---|---|
| Rehost | Almost nothing; the workload moves as it is | IaaS |
| Revise or replatform | Small changes, often to a managed database or runtime | IaaS or PaaS |
| Rearchitect | The application is redesigned for cloud-native services | PaaS |
| Rebuild | Recoded from scratch | PaaS |
| Replace | Retired in favour of software as a service | SaaS |
Speed of migration pushes you towards rehost and replace. Scalability and modernisation push you towards rearchitect and rebuild. The choice also fixes your exit cost, because rehosted workloads stay portable and rearchitected ones do not.
Published overrun figures, and the cause behind them
CACI reports that organisations spend on average 14% more on a migration than they planned, and that 38% of migrations run more than three months late. The same guide reports survey data showing that 84% of organisations struggle to manage cloud spend. The shape behind those numbers is not technical failure. It is a business case drafted before the workload register existed, and a cost model built on list prices rather than on data egress, observability, and the platform team you now have to hire.
Ten risks to put to a provider before you buy
DigitalOcean's list of cloud migration risks is a competent starting register, and we use it when we weigh providers. It takes in infrastructure compatibility, cloud cost management, security and compliance, architecture design, application compatibility, data migration and integration, network performance and connectivity, organisational change and training, governance, and monitoring with incident management. Each of those is a question you can put to a provider and expect a firm position on. Ask which of them the provider accepts contractually, which stay with you, and what evidence it hands over at the end of each tranche.
Compliance duties that do not pause for a cutover
For UK organisations the regulatory layer is not optional and it does not begin at go-live. Suffescom's 2026 analysis of migration risk lays out the frameworks that most often apply: UK GDPR and the Data Protection Act 2018, FCA operational resilience expectations, Cyber Essentials and ISO 27001. The same analysis identifies the failure mode we meet most often in reviews, configuration drift, where security settings move over time through manual changes and automation errors until the running environment no longer matches the approved design. Suffescom also reports that a personal data breach in the UK must be reported to the Information Commissioner's Office within 72 hours, which means your incident route has to survive the migration weekend intact.
What a paid assessment delivers
ANS runs a Cloud Navigator assessment and publishes what it delivers: a cloud readiness assessment, an application migration roadmap, return on investment and total cost of ownership modelling, a target architecture, a phased transition plan, and board-ready recommendations. ANS also makes the point most service pages leave out, which is that workload suitability cuts both ways, and that some workloads are better kept on-premises or in a hybrid arrangement. If a provider's assessment cannot return a do-not-migrate verdict, it is not an assessment.
Cost, exit, and the case for private cloud
Akita's cloud migration practice treats cost management as a governance problem rather than a billing one, and recommends agreeing key performance indicators and projections before the move rather than reconciling after it. Akita also runs its own private cloud and presents it as materially cheaper than Microsoft Azure, AWS or Google for suitable workloads. We do not treat that claim as settled, and we say so, but it is the right kind of claim to test. For a steady-state workload with predictable demand, a private or hybrid placement can beat a hyperscale one on total cost, and the route that keeps the option open is rehost or replatform, not rearchitecting.
Rehosting costs the least and locks in the least. That trade is the one most buyers get backwards, and it is why we treat portability as a line in the assessment rather than a footnote in the contract.
Which reader needs which part
A buyer drafting a tender wants the routes table, the overrun figures and the ten risks. A technology lead wants the placement record and the compliance duties. Whoever approves the business case wants the cost section and the exit trade. A team already part-way through a move wants the configuration drift paragraph and the incident route. Each page below this one takes one of these areas and goes further into it.
