Cloud architecture · Platform architecture
Cloud migration: sequence decisions, not just workloads
A practical guide to cloud migration boundaries, dependency mapping, landing zones, observability, cutovers, and exit criteria.
Published · Last reviewed · 8 minute read
A cloud migration is a sequence of operating-model decisions expressed through workload moves. Moving infrastructure without changing ownership, delivery, security, and observability usually relocates existing constraints rather than removing them.
The cloud archive on this site covers public, private, hybrid, and multi-cloud models. This guide focuses on how to decide and execute a migration across those choices.
Define the outcome and boundary
State what the migration must improve: delivery lead time, resilience, regional reach, capacity, security controls, or operating cost. Set measurable acceptance criteria and constraints. A migration defined only as “move to cloud” cannot make trade-offs consistently.
Choose a boundary that can be owned and tested. A business capability or service boundary is usually more useful than a list of virtual machines because it includes data, dependencies, operations, and users.
Build a dependency map
Inventory runtime calls, data flows, identity dependencies, batch jobs, operational tooling, network paths, and organisational owners. Confirm the map with telemetry and operators rather than relying only on configuration records.
Classify dependencies by latency sensitivity, data sensitivity, availability requirement, and ease of change. This shows which workloads can move independently and which need a coordinated transition.
Establish the landing zone as a product
A landing zone should provide reusable identity, network, logging, policy, encryption, deployment, and cost-management capabilities. Version these capabilities and give teams a supported adoption path.
Validate the landing zone with a representative workload before scaling migration waves. The first workload should exercise important controls without carrying the organisation’s highest operational risk.
Select a migration treatment deliberately
For each workload, decide whether to retire, retain, replace, rehost, replatform, or redesign it. The right treatment follows the desired outcome and constraints. Rehosting can reduce data-centre dependency quickly; redesign can improve elasticity or operability but introduces more change and validation work.
Record the decision, expected benefit, required evidence, rollback path, and owner. Revisit it when dependency information changes.
Make observability available before cutover
Operators need comparable signals on both sides of a transition. Establish service objectives, logs, metrics, traces, ownership, and alert routing before production traffic moves. Test failure modes, capacity limits, backup restoration, and access recovery.
The note on cloud downtime is a reminder that provider infrastructure does not remove the need for explicit resilience and recovery design.
Use explicit cutover and exit criteria
Define traffic steps, data synchronization, freeze windows, rollback triggers, decision owners, and communication paths. After cutover, remove obsolete infrastructure, credentials, routes, and monitoring. A migration is incomplete while two environments remain operational without a deliberate reason.