Phase 1 is never 'lift and shift.' Here's the framework that keeps production stable throughout the entire move.
After leading migrations for organizations ranging from 200 to 4,000 engineers, I've distilled it into 6 phases that keep production alive and teams sane.
Phase 1: Discovery & Dependency Mapping
Before touching a single VM, audit everything.
Inventory all services: apps, databases, middleware, integrations
Map inter service dependencies including the undocumented ones (ask the engineers who've been there longest)
Tag everything by criticality, data sensitivity, migration complexity
Identify the "spiders in the web" services everything else depends on
Tools: AWS Application Discovery Service, Cloudamize, or a structured spreadsheet + interviews.
Phase 2: Cloud Foundation & Landing Zone
Build the platform before you migrate anything.
Set up your VPC architecture (hub spoke or flat decide now)
Implement IAM roles, SCPs, and guardrails
Deploy centralized logging, monitoring, and alerting
Establish your IaC standard (Terraform modules, Pulumi stacks — standardize before day one)
Set cost budgets and alerts BEFORE anything runs
Never skip this. Teams that migrate first and "sort out governance later" always regret it.
Phase 3: Pilot Migration (Noncritical workloads)
Start small. Build confidence.
Choose a non-critical, low traffic service
Run full migration lifecycle: move → validate → monitor → optimize
Document everything. This becomes your runbook for every subsequent migration
Identify gaps in tooling and process while the stakes are low
Phase 4: Wave Based Migration
Organize workloads into migration waves by complexity:
Wave 1: Stateless apps (easiest)
Wave 2: Stateful apps with managed DB alternatives
Wave 3: Complex integrations and legacy services
Wave 4 (optional): Services that require refactoring before migration
Run each wave over 2–4-week sprints. Include a 2-week stabilization window after each wave before proceeding.
Phase 5: Cutover & Traffic Management
Zero-downtime means dual running, not big-bang.
Use feature flags and DNS-based traffic shifting (Route 53 weighted routing or equivalent)
Implement a circuit breaker to instantly roll back traffic if error rates spike
Keep on prem running in parallel for 30–60 days post cutover
Don't decommission anything until you've run at least one full billing cycle on cloud
Phase 6: Optimize & Decommission
The migration isn't over when the apps are running.
Right-size instances based on real usage data (wait at least 2 weeks)
Implement autoscaling where you were running fixed capacity
Set up FinOps dashboards cloud spend will be surprising at first
Decommission on prem systematically, not in a rush
Run a migration retrospective with every team involved
The Rule I Never Break
No service goes to production without observability in place (logs, metrics, traces), a documented runbook, an on-call rotation assigned, and a tested rollback procedure.
Save for your next migration kickoff
Top comments (1)
Excellent framework. The point that "Phase 1 is never lift and shift" deserves more attention. Many migration challenges can be traced back to incomplete dependency mapping and insufficient planning before execution begins.
At LogicEra, we've found that organizations achieve smoother cloud transitions when discovery, observability, governance, and rollback planning are treated as foundational requirements rather than post-migration tasks. The emphasis on wave-based migration and stabilization periods is particularly valuable for reducing operational risk.
Thanks for sharing this practical playbook.