Choose the migration strategy per workload
A cloud program should not force every system into the same pattern. Assess each workload against business value, technical debt, dependencies, data sensitivity and change tolerance. Select among rehost, replatform, refactor, repurchase, retain and retire. Record the decision and the expected business outcome before implementation begins.
Phase 1: discovery and assessment
- Inventory applications, servers, databases, integrations, certificates and data stores.
- Map upstream and downstream dependencies using traffic and configuration evidence.
- Classify data by sensitivity, residency, retention and recovery requirements.
- Capture baseline performance, availability, cost and incident metrics.
- Define workload migration waves based on risk and dependency groups.
- Create a rollback condition and accountable owner for every workload.
Phase 2: landing zone and security foundation
Organization design
Separate production, non-production, security and shared services with account, subscription or project boundaries.
Identity
Federate the enterprise identity provider, require MFA, remove standing privilege and create emergency access procedures.
Network
Plan IP ranges, DNS, inspection, private endpoints, egress controls and connectivity to remaining data centers.
Guardrails
Encode encryption, region, logging and public-access policies so unsafe resources are prevented or detected quickly.
Phase 3: migration and validation
Build environments with infrastructure as code and test the repeatable deployment before moving production data. Validate functional behavior, performance under representative load, recovery objectives, observability, vulnerability posture and operator runbooks. Data migration needs reconciliation checks that prove source and destination records match.
| Gate | Evidence required | Owner |
|---|---|---|
| Security | Threat model, vulnerability scan, IAM review, encryption proof | Security lead |
| Reliability | Backup restore test, failover test, capacity and dependency review | Service owner |
| Operations | Dashboards, alerts, runbooks, support rota and escalation path | Operations lead |
| Business | User acceptance, maintenance notice and rollback approval | Business owner |
Phase 4: cutover and day-two operations
- Freeze conflicting changes and verify the final synchronization window.
- Run automated pre-cutover checks and record the go/no-go decision.
- Monitor customer journeys, errors, latency and data consistency during cutover.
- Keep the rollback path intact until explicit acceptance criteria are met.
- Decommission legacy resources only after retention and compliance approval.
- Review cost, performance and incidents after 7, 30 and 90 days.
Common migration mistakes
Programs lose momentum when they migrate without dependency evidence, reproduce legacy network complexity, postpone identity design, or declare success at cutover rather than after stable operations. A smaller first wave with measurable acceptance criteria is more valuable than a large wave built on assumptions.
Plan your migration with fewer surprises
We design landing zones, migration factories and secure operating models across AWS, Google Cloud and Microsoft Azure.
Plan a migration assessment