Cloud Migration Checklist

Part 7 closed the architecture. This part turns the whole series into a sequence you can run. A cloud migration checklist is not a flat to-do list. It is a set of phases, each one gating the next, so that nothing proceeds on faith. The discipline that separates a migration that lands from one that overruns is exactly this: discovery proves the plan before strategy commits to it, the landing zone proves out before workloads land on it, each workload proves parity before it carries live traffic, and the source is retired only after the target has earned it. Here is the sequence, phase by phase.

The checklist at a glance

Phase	What you do	The gate that must pass before the next phase
1. Discovery	Map every workload, its data, dependencies, and undocumented behavior	You understand the estate well enough to plan against evidence, not guesses
2. Strategy	Assign each workload an R and sequence the waves	Every workload has a chosen move, a success measure, and a place in the order
3. Landing zone	Build secure, observable, cost-governed cloud foundations	Identity, network, security, observability, and cost controls are live and tested
4. Data migration	Move and reconcile data per dataset	Source and target agree on counts, checksums, and totals
5. Migration and cutover	Move workloads in waves behind a facade	Each workload clears the parity gate before it carries live traffic
6. Decommission and optimize	Retire the source and tune the target	Each source system is gone only after its target is validated in production

The rule the table encodes is the one that separates migrations that land from migrations that overrun: no phase starts on faith. Each row’s gate is the evidence the next phase is allowed to build on. The sections below are the detailed version of each row.

Phase 1. Discovery: map before you move

Nothing safe happens before this. You cannot migrate what you don’t understand, and the dependencies that wreck migrations (Part 5) are the undocumented ones.

• Inventory the workloads. Every application, service, and batch job, with its owner and business criticality.
• Map the data. Datasets, sizes, where they live, and which workloads depend on each. Data gravity drives sequencing.
• Map the integrations. Internal feeds, partner connections, scheduled jobs, hard-coded assumptions about network and timing.
• Recover undocumented behavior. Read the codebase, configuration, and data directly to surface the rules nobody wrote down, and capture them as durable documentation. This is where AI-accelerated analysis turns weeks of manual archaeology into a usable map.
• Establish a baseline. Current performance, cost, and reliability, so you can prove the migration improved things rather than hope it did.

Phase 2. Strategy: assign and sequence

With the map in hand, decide what happens to each workload and in what order.

• Assign an R to every workload. Retire, retain, rehost, replatform, repurchase, refactor, or rebuild (Part 2). Default to the cheapest adequate move, and reserve the expensive ones for where the business needs new capability.
• Settle lift-versus-refactor on the middle-band workloads from what the business needs, not from instinct (Part 3).
• Sequence the waves. Prove on something low-stakes first, then migrate to unblock, then tackle the hardest, highest-value systems last.
• Model the target run cost before committing. The cost of the destination architecture, not the source (Part 4’s surprise bill).
• Define success per workload. The specific, measurable outcome that means this migration was worth doing.

Phase 3. Landing zone: build the foundation

Before workloads arrive, the cloud environment they land in has to be secure and well-architected. Migrating into a weak foundation just relocates your problems and adds new ones.

• Identity and access. Least-privilege roles, central identity, no shared credentials.
• Network and segmentation. The secure boundaries workloads will sit inside, and the controlled bridge to anything staying on-prem.
• Security baseline. Encryption in transit and at rest, secrets management, logging and audit from day one.
• Observability. Metrics, logging, and tracing wired before the first workload, so you can see what’s happening during cutover.
• Cost guardrails. Budgets, alerts, and tagging so spend is visible and attributable as it grows, not discovered in a quarterly invoice.

Phase 4. Data migration: move and reconcile

Data is the heaviest, riskiest part (Part 4). Treat it as its own phase with its own gate.

• Choose the data strategy per dataset. One-time move, ongoing sync, or a period of dual-write while both systems run.
• Migrate with a method matched to the data’s size and sensitivity.
• Reconcile as a gate. Record counts, checksums, financial totals, sampled row-level diffs. The migration is incomplete until source and target agree.
• Validate behavior on the data. Where the workload is changing, run the new system on shadow traffic and compare outputs to the source before it owns the data of record.

Phase 5. Migration and cutover: prove, then shift

Now the workloads move. Never all at once, never on faith. This is the heart of the method.

• Stand up the strangler facade. The cloud workload runs beside the source, and a routing layer controls which one serves traffic.
• Clear the parity gate. Functional parity, data integrity, and non-functional parity (performance, security, accessibility) verified against the source’s actual behavior. A workload that fails the gate goes back for fixing. It is not promoted on a schedule. See parity validation.
• Shift traffic gradually. Route a fraction to the cloud, watch the telemetry, increase as confidence grows. Cutover is a dial, not an event.
• Keep rollback ready. Until a workload is fully validated under production load, reverting is a routing change, not a recovery operation. The cutover playbook covers the mechanics.
• Keep the business running. No roadmap freeze, no downtime window. The source carries the rest while each workload proves out.

Phase 6. Decommission and optimize: finish honestly

A migration isn’t done when the workload runs in the cloud. It’s done when the source is gone and the target is earning its keep.

• Decommission the source. Workload by workload, only after each is validated in production, so the data center shrinks on evidence.
• Right-size and optimize. Tune the now-real cloud workloads against the baseline from Phase 1. This is where the wasted-spend problem (Part 4) gets caught and cut.
• Confirm the success criteria. Measure against the per-workload outcomes you defined in Phase 2. Did the migration deliver what it promised?
• Capture the learnings. Feed what each wave taught you into the next.

The mistakes that break the sequence

Most failed migrations don’t fail because a phase was done badly. They fail because a phase was skipped to save time, and the skip surfaces two phases later when it is expensive to fix. The recurring ones:

• Skipping discovery to “start moving.” The undocumented dependency you didn’t map is the one that breaks a partner integration at cutover. The time you save at the front is repaid with interest in the middle.
• Costing the source, not the destination. A workload that was cheap on-prem can be expensive in the cloud if it was never sized against cloud pricing. Model the target run cost in Phase 2, not in the first quarterly invoice.
• Migrating into an unfinished landing zone. Standing up identity, security, and observability after workloads land means retrofitting them under load. Phase 3 exists so the foundation is proven before anything sits on it.
• Treating cutover as an event. A hard switch with no gradual shift and no rollback turns a routing decision into a recovery operation. Parity gate, dial, rollback, in that order.
• Calling it done at “it runs in the cloud.” If the source is still powered on and the target was never optimized against the baseline, you are paying for two estates and capturing the benefit of neither.

Not every workload needs every gate

This checklist is calibrated for the migrations that carry real risk. Critical, data-heavy, knowledge-laden estates where the failures in Part 4 are expensive. A handful of simple, stateless workloads with no complex data and no undocumented behavior don’t need every gate, and running the full apparatus on them is ceremony for its own sake. Scale the rigor to the stakes. The phases are a framework for not skipping the steps that matter. They are not a mandate to apply maximum process to every workload regardless of what it would cost you to get it wrong.

Where this leads

A checklist tells you what to do. The question every executive sponsor asks next is what will it cost. Cloud migration cost is genuinely hard to estimate, because it spans the one-time migration spend and the ongoing run cost that outlives it. Part 9, Cloud Migration Cost, breaks down both, the traps that inflate each, and how to build a number a CFO will trust.