The costliest form of failure in a cloud migration begins long before any workload moves, at the moment a business case is approved with nothing in it that would justify pausing the work. The case argues for the move, the steering group approves it, and nothing downstream can later say that a particular workload should stay where it is or be switched off. The result is a migration that is technically complete and commercially wrong: applications that should have been retired are lifted into cloud infrastructure, a platform is bought before placement is understood, and the opening ninety days after go-live go into discovering that the baseline was never measured.
Read this page as a checklist. It is for the executive who approves the business case, the architect who places workloads, and the service manager who runs the result. It lays out the circumstances under which a cloud migration repays its cost and its risk, ordered by the point at which each item is checked: before the business case, before the platform and tier decision, before a workload enters a migration stage, during the cutover window, and across the first ninety days in the cloud. Every line below can be checked against your own infrastructure, and a line you cannot respond to is itself a finding. Each line stays short on purpose, because the working behind it appears on the page it references.
Checked before you commit to a business case
You can name the constraint that cloud computing removes, and cost alone is the weakest version of it. The Google Cloud account of the migration process lays out the change as a move from capital expenditure to operational expenditure, where CapEx is a large one-time purchase of physical assets that lose value over time and OpEx is an ongoing subscription for the capacity actually used. That alters the shape of the bill before it reduces it, and a case resting on the shape alone is fragile the first time finance asks what leaving would cost.
Your baseline is measured rather than estimated: power, cooling, floor space, hardware refresh cycles, software licensing tied to physical cores, and the loaded cost of the staff who keep the infrastructure running. Without a current annual figure you cannot show afterwards that the migration improved anything.
You have a record of what would make migration the wrong decision. The NHS cloud migration guidance says that cloud-first does not mean the entirety of an on-premises data centre has to be migrated, and that on-premises data centres can be the right choice where cloud computing cannot meet regulatory or latency requirements. A business case with no such clause has assumed a decision it never tested.
You can score every workload on risk, technical fit and value. The same NHS guidance details those three as the basis for placement: risk governs how much damage a mistake can absorb, technical fit governs whether an application moves as it stands or needs changes, and value governs how much benefit the organisation should expect from moving it. Starting with low-risk applications lets an organisation absorb mistakes without jeopardising the wider effort.
You accept that some workloads will stay where they are. AWS lists retaining, or revisiting, as a strategy for applications that have recently been upgraded or whose reasons for migration are unclear. A checklist with no route to retention leaves risk unmanaged.
You have a response for the UK compliance layer, because data residency, records management, clinical safety where it applies, and the expectations of the regulator constrain placement before they constrain configuration. Handled as a later workstream, compliance rewrites placement decisions after the business case has already been approved.
Checked before you choose a platform or a tier
Placement comes before provider. The NHS guidance includes a workload migration assessment that identifies applications which cannot be deployed using cloud computing, picks out the strongest candidates for cloud deployment, and prioritises the move away from the on-premises data centre. Choosing a provider first reverses that order and converts a placement decision into a procurement one.
You have chosen a cloud tier with the control and benefit trade understood. The NHS guidance lists the tiers as IaaS, PaaS, SaaS and FaaS, and observes that a SaaS-first stance delivers most of the benefits of cloud computing with the lowest barrier to adoption while shifting most of the control and the risk to the provider. Custom applications need a platform able to run their code, which points at PaaS, while older applications may not fit existing PaaS offerings and end up on IaaS. The tier decides who bears the operational burden.
You have tied each migration approach to the tier it implies. The NHS guidance says that rehost and revise are usually executed at IaaS, rearchitect and rebuild on PaaS, and replace on SaaS, and adds that the rule is not strict: a rearchitect that finds no compliant PaaS platform drops to IaaS, and a replacement that cannot be found for a customised commercial package reverts to rehost. An approach laid out without its tier is half a decision.
You treat lift and shift as a stage with an exit, and you have said what the exit is. The NCSC cloud security guidance calls lift and shift a pure IaaS solution that places most of the management and security burden on you, and recommends avoiding it where possible. It recognises exceptions: moving at pace when a data centre contract is expiring, an opening stage in a wider modernisation effort, monolithic or legacy systems that are unfeasible to refactor, and black box applications with limited serviceability. A reason outside that list is a choice made knowingly against the guidance.
You have a landing zone or an equivalent secure baseline. The NCSC says landing zones broadly share the principle of creating a secure scalable baseline for cloud resources to be deployed onto, and usually consist of an organisational structure, security monitoring and logging, identity services, and platform guardrails. A migration without that baseline moves a problem from one data centre to another.
You have decided whether to move snapshots or rebuild. The NCSC warns that moving snapshots brings existing issues into the cloud, security issues included, and recommends recreating fresh virtual machines so the infrastructure lands on a known good configuration. Where a workload cannot be rebuilt, the migration approach changes.
You have simplified permissions before migration. The NCSC says a permissions model can become too complex to be understood correctly, that usability has to be excellent, and that security only needs to be good enough. A migration that preserves every exception from the old infrastructure preserves the exposure as well.
Checked before a workload enters a migration stage
Your inventory is complete enough to respond to what is moving. The NCSC advises taking an inventory and simplifying it, identifying end-of-life or vulnerable products, and avoiding unnecessary customisation, and it warns that a migration can go wrong either by moving something the organisation no longer needs or by leaving behind something the migrated system relied on. Its value lies in the dependencies it exposes.
You have analysed application dependencies and interdependencies. IBM lays out the assessment stage as listing and categorising applications and data, analysing dependencies, evaluating security and compliance requirements, assessing performance and scalability needs, establishing goals, and identifying challenges. Where two applications share a database and only one of them is in the stage, the migration has a hidden dependency to manage.
You have a tested rollback for the workload, and you can execute it within the cutover window. The NCSC says that if issues arise after migration, rolling back to the previous state can be complex and time-intensive, so a rollback that has not been rehearsed is an intention rather than a control.
You have measured the data transfer time and the bandwidth required, and you know what happens if the transfer overruns. AWS says that transferring large data volumes can be time-consuming with limited bandwidth, and that some interdependent migrations may temporarily require applications to be offline.
You have a cutover runbook with explicit steps and the roles responsible for each. IBM lays out the migration step as setting up the target cloud environment, provisioning resources, replicating data, and deploying and configuring applications, followed by testing and validation.
You have a maintenance window agreed with the business, and the business has accepted the downtime. Azure lists business downtime as a common challenge and says that while moving massive amounts of data can be done quickly, it requires careful planning to minimise downtime during the move.
You have validated that the target environment meets the workload's latency and regulatory requirements. The NHS guidance says that on-premises data centres can be the right choice when cloud computing cannot meet certain regulatory or latency requirements.
You have a plan for the dual-run period and its cost. During the dual-run window, both the old and new environments are live, and the metered charges for the new environment accrue before any decommissioning savings arrive.
You have mapped the security controls from the on-premises environment to the cloud. The NCSC says you need to confirm that the security protections around your application still exist in the cloud system, and that this may be difficult if a system has developed over time and the security boundaries are no longer clear.
Checked during the cutover window
The cutover lead has the decision rights to pause or abandon the move. A cutover without an identified decision point will proceed past the evidence that should have paused it.
Monitoring and logging are live in the new environment before any production traffic moves. The NCSC advises turning on the cloud logging, monitoring, and alerting tools and ensuring a designated role is monitoring the dashboards, because mistakes are most likely during that first move to the cloud.
The DNS switchover is planned and reversible. A DNS change that cannot be reverted within the cutover window is a one-way door.
Data synchronisation is current, and the delta to be applied at cutover is measured. AWS says replication-based data migration keeps both databases in sync as it duplicates data from source to target.
The security controls are active in the target environment. The NCSC says access control is your responsibility, not the cloud provider's, and that a lack of restrictions in the cloud can mean the data is accessible to anyone.
The performance baseline is measured in the new environment before traffic is shifted. Google Cloud says core systems and applications typically perform better and more reliably in the cloud, but that claim needs a measurement to support it.
The incident response plan is active, and the on-call rota is staffed for the cutover. Azure lists business downtime as a challenge and says that careful planning is required to minimise downtime during the move.
Checked across the first ninety days
The run cost is measured monthly against the business case. Google Cloud says migrating to the cloud can help organisations move spending from capital expenditure to operational expenditure, but the operational expenditure has to be managed or it grows.
The old environment is decommissioned on the planned schedule. A dual-run period that extends without a decision point becomes a permanent cost.
The security controls are reviewed against the NCSC's guidance. The NCSC says you should resolve any warnings unless you are certain the warning is harmless.
Backup and disaster recovery are tested in the new environment. Azure says most cloud providers offer built-in backup recovery capabilities, but the recovery has to be exercised to be trusted.
The team running the environment has the skills to operate it. IBM says the skills required for cloud operations are different from those for on-premises environments, and organisations should either hire new employees or retrain existing staff.
Cost governance is in place. AWS says you only pay for the cloud resources you use, which makes it easier to scale up or down, but without governance the scaling is uncontrolled.
The migration is not treated as finished at go-live. Google Cloud says once migrated, systems might remain as is or go through ongoing optimisation and modernisation.
