A cloud migration preparation checklist for IT leaders
The operational prep before a migration starts: application inventory, the pre-flight checklist, and the infrastructure plan you need signed off.
This is the preparation work, in the order an IT leader has to do it, with the artefacts each step has to produce.
It assumes the decision to migrate is already made. If you are still deciding, Switzerland’s cloud moment: is your business ready? is the readiness assessment; this is what happens once the answer is yes.
Step 1 — Write down the objective, with a number
Before any inventory work, one sentence with a measurable outcome and a date. Not “migrate to the cloud” — something that can be true or false at a point in time.
Three shapes that work:
- “Reduce fully-loaded infrastructure cost per environment by X% by Q3”
- “Cut provisioning time for a new test environment from three days to under two hours by Q2”
- “Move to a documented recovery time of under four hours for the three business-critical systems by year end”
The artefact: one sentence, agreed with the business sponsor, that every later trade-off is decided against.
Step 2 — Inventory and categorise applications
The single most laborious step and the one everything else depends on. The unit is the application or workload, not the server.
Per application, capture:
| Field | Why it matters |
|---|---|
| Business owner | Someone has to decide and sign off |
| Users and volume | Distinguishes critical from forgotten |
| Load profile across a year | Determines sizing and whether elasticity helps |
| Data classification | Sets the regulatory constraint |
| Dependencies, both directions | Determines what moves together |
| Cost of an hour down | Sets the wave it belongs in |
| Fully-loaded current cost | The baseline every later claim needs |
Then categorise. The standard six — retire, retain, rehost, replatform, refactor, replace — with a named reason each.
Two findings this step reliably produces. First, several applications have no users at all; retiring them is the cheapest win available. Second, the dependency map is wrong, because some connections were never documented. Better to learn that now than during a cutover.
The artefact: a spreadsheet with one row per application, a disposition, and a named owner. Nothing proceeds without it.
Step 3 — Settle the regulatory questions
These constrain architecture, so they come before design, not after.
- Data residency per class. Which data must stay in Switzerland, which may sit in the EU, which is unconstrained. Most estates have less constrained data than the blanket assumption suggests.
- Access control. Who can reach the data — including provider support staff in other jurisdictions, and sub-processors behind them. This is the question that gets audited under revDSG/nDSG and GDPR; storage location is not.
- Retention. Minimums and maximums per data class, and how the new environment will enforce them.
- Exit. For FINMA-supervised businesses a documented, demonstrable exit is a requirement. For everyone else it is the difference between a supplier and a dependency.
The artefact: written answers, reviewable by whoever signs off compliance. If these live only in someone’s head, they do not exist.
Step 4 — The pre-flight checklist
Per wave, before anything moves:
- Baseline metrics captured — performance, cost, availability
- Rollback plan written and executed at least once
- Backups verified by restoring, not by checking a green tick
- Owner identified for each application in the wave
- Cutover window agreed with the business, including who decides to abort
- Communication plan — who is told what, and when
- Success criteria defined before the move, not chosen afterwards
The rollback line is the one most often assumed rather than done. A rollback plan that has never been executed is a hypothesis, and the first time you find out is the worst time.
Step 5 — The infrastructure plan
What the landing zone contains, agreed and signed off before the first workload arrives:
Network and identity — segmentation, how access is granted, how it is reviewed, and by whom.
Observability — what is logged, retained how long, who reads it, and what triggers an alert. Do not economise here; it is the evidence you need during an incident and, for regulated workloads, part of what you are obliged to keep.
Backup and recovery — recovery point and recovery time objectives per application class, taken from the business rather than from IT, and tested.
Cost attribution — tagging by team or product from day one. Retro-fitting tags across a live estate is genuinely miserable work.
Guardrails — budget alerts, mandatory tags, default size limits. Guardrails scale; approval steps get routed around.
The artefact: a written landing-zone definition, reviewed by someone who did not write it.
Step 6 — Name the owners
Three roles, with actual names attached, before the first wave:
- Migration lead — decides sequence and go/no-go per wave
- Cost owner — reports variance monthly, from day one rather than after go-live
- Platform owner — owns the landing zone after the programme ends
The third is the one that gets forgotten, and its absence is why estates freeze in their migration-day shape. The optimisation that produces the savings happens after the programme, or it does not happen.
What “prepared” looks like
Six artefacts. If you have all six, the migration is a scheduling exercise. If you are missing two or more, the migration will discover them for you at a worse moment.
- An objective, one sentence, with a number and a date
- An application inventory with dispositions and owners
- Written regulatory answers on residency, access, retention and exit
- A pre-flight checklist per wave, with a tested rollback
- A signed-off landing-zone definition
- Three named owners
Related reading
- Cloud migration roadmap: a decision framework
- A cost-effective cloud migration strategy in five steps
- Ten cloud migration mistakes mid-market companies still make
If you want these six artefacts produced for your estate, book a call. No obligation.