Cloud migration roadmap: A decision framework
The decisions a migration roadmap has to settle before any workload moves: goals, cloud model, adoption framework and how to segment workloads into waves.
There is a difference between a migration plan and a migration roadmap. A plan lists workloads and dates. A roadmap settles the decisions that determine whether those dates mean anything.
This covers the four decisions, and deliberately not the cost arithmetic — that sits in the cloud migration roadmap for European SMEs.
Decision 1 — What the migration is for
The most common cause of a disappointing migration is that it had no stated purpose beyond moving.
Three purposes are legitimate and they lead to different architectures:
- Cost reduction. Implies aggressive right-sizing, scheduled shutdowns, commitment pricing, and tolerance for some re-engineering.
- Speed of change. Implies investment in automation, environment provisioning and deployment pipelines — which may not reduce cost at all in year one.
- Risk reduction. Implies redundancy, tested recovery and geographic separation, which costs more, not less.
Picking all three produces a design optimised for none. Picking one, and saying so, makes every later trade-off decidable.
Write it as a sentence with a number and a date, or it will not constrain anything.
Decision 2 — Assess what you actually have
An inventory of servers is not an assessment. The unit is the workload, and per workload you need:
- Usage pattern across a year, not a week — the peak and the trough
- Data sensitivity and the regulatory constraint that follows from it
- Dependencies in both directions: what it needs, what needs it
- Cost of an hour of downtime
- Fully-loaded cost today, including operations hours
The output is a disposition per workload:
| Disposition | When it applies |
|---|---|
| Retire | Nobody has used it in a year |
| Retain | Stable, on hardware not yet depreciated, or constrained to stay |
| Rehost | Move as-is; fastest, least benefit |
| Replatform | Minor changes to use managed services |
| Refactor | Structural change to gain elasticity |
| Replace | A product does this better than your build |
Retire is the highest-value disposition and the least used. Most estates carry systems with no users, each consuming licences, hosting and attention.
Decision 3 — Which cloud model
This is usually decided by habit or by whoever spoke last. It should follow from decision 1 and the regulatory constraints found in decision 2.
Single public cloud — simplest to operate, deepest discounts, one set of skills to build. The right default for most mid-market estates.
Hybrid — parts stay on-premises or in Swiss colocation because of regulation, latency or un-depreciated hardware. Frequently the correct end state rather than a transition, as argued in why the DACH market prefers evolution.
Multi-cloud — genuine independence, at roughly double the operational burden and halved depth in both platforms. Justified by a specific requirement, not by a general preference for optionality.
The question that settles it: what constraint forces anything other than a single platform? If none, the answer is one.
Decision 4 — The adoption framework
The landing zone is the environment everything arrives into, and it is where the next three years are decided. Settle before the first workload moves:
- Network and identity — segmentation, access model, how permissions are granted and reviewed
- Logging and monitoring — what is captured, retained how long, and who reads it
- Backup and recovery — with the recovery actually tested, not assumed
- Cost attribution — tagging by team or product from day one, because retro-fitting it across a live estate is miserable
- Guardrails — budget alerts, mandatory tags, default size limits
Two regulatory items belong here rather than later. Under revDSG/nDSG and GDPR you need documented answers on data residency and access — separate questions, and access is the audited one. For FINMA-supervised businesses, a documented exit path is a requirement.
Segmenting workloads into waves
With dispositions and a landing zone, sequencing becomes mechanical:
Wave 1 — prove the process. Something that matters to the business but whose failure is survivable. Not the regulated workload; you want the process proven first. Test the rollback here, while the stakes are low.
Wave 2 — the bulk. Ordered by business impact. Tightly coupled systems move together; splitting a dependency across waves means building a temporary integration you will throw away, and that cost belongs in the plan or the split does not happen.
Wave 3 — the constrained. Regulated workloads, the ones with the deepest dependencies, and anything waiting on a hardware refresh date.
Then optimise. The savings come from what changes after landing — right-sizing, scheduling, clearing orphans, committing to capacity for what is steady. In that order, with commitment last.
What a finished roadmap contains
- One stated purpose, with a number and a date
- A disposition for every workload, including the ones being retired
- A chosen cloud model with the constraint that forced it
- A landing-zone definition, including the access and exit answers
- Waves, with wave 1 small enough to prove the process
- An optimisation phase with its own budget and a named owner
If any of those six is missing, what you have is a plan.
Related reading
- A cost-effective cloud migration strategy in five steps
- Ten cloud migration mistakes mid-market companies still make
- Cloud & DevOps
If you want these four decisions worked through for your estate, book a call. No obligation.