A credible legacy migration plan for the first 90 days should not pay for broad replacement or polished architecture diagrams. It should prove that one bounded workflow can run safely in coexistence, with clear write ownership, measurable output parity, segmented traffic, and a rollback path that still works when production pressure shows up. If the team cannot show who owns writes, how parity is checked under live traffic, and how traffic switches back without improvisation, budget should stay gated until those controls exist.
The real risk is rarely the new code. It is the old estate around it: shared tables, batch jobs, support-side fixes, partner feeds, and customer notifications that nobody treated as interfaces. The first quarter needs to answer one question quickly: can you move one slice with limited blast radius, or is the system too coupled for phased cutover?
Use a 30-60-90 legacy migration plan to force real decisions
The value of a 90-day window is simple: it forces three decisions teams often blur together. By day 30, you need runtime evidence and a viable first slice. By day 60, you need coexistence controls that can survive live traffic. By day 90, you need production proof from a limited cohort, not another architecture review.
Days 1-30: map runtime dependencies from logs, query traces, job schedules, API records, and support tickets. Name the business owner for the workflow in scope. Reject any first slice with destructive writes, unclear ownership, or no practical rollback switch.
Days 31-60: build the transition controls. That means versioned contracts, telemetry by failure domain, reconciliation rules, and a replay or shadow path that can process real traffic without owning final writes. If support cannot identify the owning system for a failing transaction within minutes, the design is not ready.
Days 61-90: move a limited cohort, validate outputs, rehearse rollback with a timer running, and decide whether the next wave should expand, pause, or change shape. If traffic cannot be segmented by tenant, endpoint, cohort, or feature flag, phased cutover is mostly fiction.
The first slice should be small enough to reverse and important enough to expose real coupling. One workflow with one bounded entity set is usually enough. A slice that looks impressive on a roadmap but depends on shared writes, undocumented jobs, or manual operator fixes is a bad first move.
| Factor | Low risk signal | High risk signal | Decision effect |
| Coupling | Clear interfaces, few consumers | Shared tables, hidden jobs, many side effects | High risk usually means wrap or delay |
| Test coverage | Trusted regression checks exist | Little reliable coverage | High risk requires replay and tighter rollout |
| Business criticality | Failure is inconvenient | Failure blocks revenue or regulated operations | High risk makes it a poor first slice |
| Reversibility | Traffic can switch back cleanly | Writes are destructive or hard to unwind | High risk should usually stop the slice |
Be blunt about the result. Teams often want the first migration slice to look transformational. That is the wrong buying signal. The first slice exists to validate control, not impress a steering committee.
By the end of month two, diagrams should have turned into operating controls. Public guidance from AWS Prescriptive Guidance and the Microsoft Azure Cloud Adoption Framework lands in roughly the same place: readiness, wave planning, and operational ownership matter more than target-stack enthusiasm when old and new systems must coexist.
Reconciliation rules need thresholds, not vague promises of parity. If the workflow publishes order status, customer-visible status and message may need an exact match, while timestamp variance can sit within an agreed tolerance. If the workflow generates documents, totals and tax fields may require exact match even if formatting differences are acceptable after business approval.
Rollback triggers should be just as explicit: sustained error-rate increase over baseline, unreconciled mismatches above threshold, duplicate customer notifications, queue lag that breaks downstream expectations, or support teams missing recovery targets. A rollback plan that depends on debate during an incident is not a rollback plan.
By day 90, one bounded workflow should have survived controlled production use. Business owners should have validated normal and exception outcomes. Rollback should be rehearsed and timed. If the proposal still leans on architecture diagrams, staffing plans, and confidence in the target platform, it is too early to fund a larger wave.
Data ownership and rollback planning decide whether phased cutover is real
The hardest migration question in month two is usually not framework choice or cloud target. It is who owns writes while both systems are active. In real coexistence failures, the damage usually shows up as duplicate writes, reconciliation gaps, or support teams unable to tell which platform is the system of record for a broken transaction.
There are only a few workable transition models. The legacy system remains the system of record while the new service reads or mirrors data. Or the new service becomes the owner for one bounded domain and publishes changes outward. The dangerous model is dual write without strict sequencing, idempotency, and reconciliation. It looks efficient in planning and becomes forensic cleanup in production.
For each entity in scope, define four things: authoritative writer, propagation path, reconciliation rule, and recovery method. If one of those is vague, the team is not ready to move live traffic. This is basic work. It still gets skipped because teams would rather fund feature rebuild than migration control.
