Legacy to cloud-native: a practical migration playbook for US enterprises

US mid-market enterprises often run critical revenue on systems built 10–20 years ago — monolithic .NET or Java apps, on-prem SQL Server or Oracle, batch jobs on scheduled servers. Lift-and-shift to EC2 saves datacentre rent but not operational pain. A cloud-native playbook focuses on incremental modernisation with measurable risk reduction at each step.

Step 1 — Inventory and classify

Before touching infrastructure, catalogue applications by business criticality, technical debt, and dependency map. Classify each system into one of four paths:

• Retire — unused or duplicate; decommission.
• Retain — keep on-prem or hosted as-is for now; set review date.
• Replatform — move to managed service (e.g. RDS, Azure SQL) with minimal code change.
• Refactor / rebuild — strangler pattern or full rewrite for cloud-native targets.

Executive sponsorship matters here: without agreement on what can retire, migrations stall on “we might need it someday.”

Step 2 — The strangler fig pattern

Big-bang cutovers fail. The strangler approach routes traffic incrementally from the legacy monolith to new services behind an API gateway or load balancer. Start with read-only APIs or low-risk features — reporting, notifications, admin tools — then tackle core transactions once observability proves stability.

Containerise new services (ECS, EKS, or Azure Container Apps) from day one. Use managed databases with automated backups and point-in-time recovery. Keep the legacy database as system of record initially; sync or dual-write only where you have tested rollback.

Step 3 — Data migration discipline

Data is where migrations slip. Plan explicit migration windows, validation queries (row counts, checksums, sample business invariants), and a rollback path. For US firms with state privacy laws, track personal data residency — which tables hold PII, and whether the target region meets contract and regulatory requirements.

Event-driven sync (change data capture) often beats overnight batch dumps for systems that must stay online during transition.

Step 4 — Cutover and hypercare

Define go/no-go criteria: error rates, latency p95, support ticket volume. Run parallel operation for at least one business cycle where feasible (e.g. two pay periods for payroll-adjacent systems). Staff hypercare — dedicated engineers on call for 2–4 weeks post-cutover with authority to roll back without committee approval.

What good looks like at 12 months

A successful US mid-market migration delivers: lower mean time to deploy (from weeks to hours), autoscaling for seasonal demand, infrastructure as code for every environment, and a documented roadmap for the next tranche of legacy systems — not a single heroic weekend and silence.