A cloud migration runbook: the steps in the order they matter

Published lists of cloud migration steps tend to describe a programme: assess, plan, migrate, optimise. That sequence is correct and it is not operational. A runbook is a different document. It covers one move, in enough detail that someone who did not design it can execute it under time pressure, and it says explicitly what happens when a step fails. This article sets out the steps in the order they matter, the decision gate that belongs at the end of each phase, and the parts that are routinely written after they were needed.

Step 0: a scope that names systems, not programmes

Before anything is sequenced, the scope has to be expressed as a list of systems with a disposition attached to each. Rehost, replatform, refactor, repurchase, retire, retain. A scope expressed as a business unit or a data centre is not yet a scope, because it does not say what gets done to what.

The retire decision deserves attention here, since it is the cheapest outcome available and the most often skipped. In most estates a measurable share of running systems has no current user. They are kept because switching them off requires a decision and leaving them running does not. A migration is the one moment where that asymmetry reverses, because migrating a system costs visible money. Ask the question per system, in writing, with a named owner giving the answer.

We treat this disposition list as the input to everything else, and the reasoning behind each choice is covered in our article on cloud migration strategy.

Gate: every in-scope system has a disposition, an owner, and a target wave. Systems without an owner do not proceed; they go back for an owner.

Step 1: discovery that produces an observed map

The inventory comes from a CMDB or a discovery tool. The map comes from observation. The gap between them is where cutover incidents live.

What the step contains:

• Network flow capture over a full business cycle. Long enough to include month-end and, where they exist, quarter-end processes. A two-week capture misses everything that runs monthly.
• Database connection audit by account. Which accounts connect, from where, how often, and which of them belong to a person who has left or a system nobody has mentioned.
• Scheduled job inventory across every scheduler in use. Enterprise schedulers, cron on individual hosts, Windows task scheduler, application-internal timers. They are rarely in one place.
• Interviews with operators. Not the system owners on the org chart, the people who handle it daily. They know about the file drop, the manual step at month-end and the workaround from 2019.

The output is a dependency graph where each edge has evidence behind it. That graph, not the application list, determines the waves.

Gate: every in-scope system has its inbound and outbound dependencies documented with an observed source. Unexplained flows are resolved before wave planning, because an unexplained flow is a dependency you have not yet found.

Step 2: the landing zone, before the first workload

This is the step most often compressed, and it is the one that is expensive to redo. The landing zone is the set of foundations every migrated workload will sit on, and retrofitting any of them across a populated estate is a separate project with its own budget.

The minimum contents:

• Identity and access. The target model, federated with the corporate directory, with roles defined and a joiner-mover-leaver process that works. Applications migrate onto this, not alongside it. Where a central identity provider has to be introduced as part of the move, we treat that as its own workstream under IAM and Keycloak, because every subsequent wave depends on it.
• Network topology and connectivity. Address planning that does not collide with the on-premise estate, the connection back to it, segmentation, and egress control.
• Logging and monitoring. Centralised, in place before the first workload, so that the first incident has evidence behind it.
• Tagging and cost allocation. A tagging standard enforced at provisioning time. Tags applied retroactively across several hundred resources is work nobody schedules and everybody needs.
• Guardrails. Policy that prevents the configurations you have already decided are unacceptable, applied automatically rather than reviewed in a meeting.

Gate: a pilot workload of no business consequence runs end to end in the landing zone, is monitored, appears correctly in cost allocation, and is reachable by the right people and only them.

Step 3: wave planning from the dependency graph

Waves are formed from the graph, not from the org chart. Systems that share a dataset move together, because a split state means every query crosses the boundary, with latency and egress attached for as long as the split lasts.

Three practical constraints shape the order:

Evidence early. The first wave should contain something visible enough that its success is credible to the people funding the programme, and small enough that its failure is survivable. Pure back-office systems are good candidates. The billing platform is not a first wave.

Business calendar. No wave lands on a period close, a peak trading window, a regulatory reporting date or a seasonal peak. This sounds obvious and it is the constraint most often discovered late, because the migration team and the business calendar live in different documents.

Licensing and vendor answers. Systems whose licensing position under the target infrastructure is unresolved do not enter a wave. They wait, with a date and an owner on the question. A wave that starts while this is open is a wave that stops halfway.

Gate: each wave has a date, a system list, a business owner who has confirmed the window, and no open licensing question.

Step 4: build and data seeding

The target environment is built from code, not from a console. This is not a preference about tooling, it is what makes the environment reproducible for the test run, the rehearsal and the real cutover, and what allows the rollback path to exist.

Data seeding runs in parallel and is usually the long pole. Bulk transfer of the historical volume happens well before cutover, with ongoing replication carrying the delta. The number that matters is not the size of the initial load, it is the rate at which the delta accumulates against the bandwidth available, because that ratio sets the length of the final catch-up and therefore the downtime window.

Two things belong in this step and are often deferred:

• Reconciliation logic. How you will prove, after the move, that the target holds the same data as the source. Row counts are a start. Checksums on business-relevant aggregates are better, because they catch encoding, timezone and precision problems that counts do not.
• The performance baseline. Measure the current system under production load before the move. Without it, every post-migration complaint about speed is unarguable, and there will be complaints.

Gate: target environment provisioned from code, initial data load complete, replication running with a measured lag, reconciliation reporting green on a full run.

Step 5: the rehearsal

The rehearsal executes the cutover runbook end to end, on the real target, with production-like data, timed. It is the step most often cut for schedule reasons, and cutting it moves the first execution of an untested procedure to the night when it has to work.

What it produces beyond confidence:

• A timing for each step, which turns the downtime estimate into a measurement.
• The list of steps that were missing from the runbook, which is never empty.
• A tested rollback, executed at least once, from the point of no return backwards.

That last point deserves emphasis. A rollback path that has been written but never run is an assumption. Its first execution will happen under the worst conditions available: at night, late, with a business deadline approaching and a room full of people watching. Run it once when nothing is at stake.

Gate: rehearsal completed, runbook updated with observed timings, rollback executed successfully.

Step 6: cutover

The cutover runbook is a numbered sequence with, for each step, the person executing it, the expected duration, the check that confirms it worked, and what to do if the check fails. It is written to be executed by someone tired.

The shape is consistent across most moves:

1. Freeze changes in the source system, announced in advance and enforced technically rather than by request.
2. Stop the inbound interfaces in a defined order, so that nothing is written to the source while the final delta is carried.
3. Complete the final data synchronisation and measure the residual lag to zero.
4. Run reconciliation and hold at the result.
5. The go or no-go decision. A named person, against written criteria, with the authority to say no. This is the point of no return and it needs to be a real gate.
6. Repoint the interfaces, DNS and integrations to the target.
7. Execute a smoke test that follows a business process end to end, not a health-check endpoint.
8. Release to users, with the operations team already on the target monitoring.

Step 5 is the one that decides whether the runbook is real. A cutover with no defined abort condition converts every problem discovered on the night into pressure to continue, and continuing with a known unresolved defect is how a technical problem becomes a business incident.

Step 7: stabilisation, then optimisation

The wave is not finished at go-live. A defined hyper-care period, typically two to four weeks with the delivery team still on hand, absorbs the defects that only production traffic finds.

The source environment stays available and unchanged during that period. Decommissioning is a separate, scheduled decision, taken after the rollback window closes and after reconciliation has been repeated at least once on live data. Decommissioning early to save infrastructure cost removes the option you paid for.

Optimisation comes after stabilisation, and it is a different exercise: rightsizing against observed rather than provisioned load, reserved capacity commitments once the shape is known, and the storage tiering that only makes sense with real access patterns to look at. Doing it before stabilisation optimises a system whose behaviour you have not yet observed.

What the runbook is for

The value of writing the steps down in this order is not documentation. It is that each gate is a place where a no is possible, and that possibility is what keeps a migration from being a sequence of commitments that can only move forward.

We work through this with teams as part of our cloud migration practice, usually starting at the discovery step, because the wave plan and everything after it inherits whatever the dependency map got wrong.