Strangler Migration Needs Route Ownership and Data Authority, Not Just a Proxy

A strangler migration succeeds when every request and data mutation has one authoritative owner at each stage. The proxy is only the switch. Define route ownership, data authority, comparison evidence, cutover conditions, and rollback before moving traffic. Avoid dual writes unless you can prove ordering, idempotency, and reconciliation.

Slice by behavior and authority

Choose a vertical capability such as customer address management, including reads, writes, validation, events, and operational support. Moving only a controller while the monolith retains hidden business rules creates a distributed call chain without transferring ownership. Inventory entry routes, background jobs, direct database access, reports, and internal callers before declaring the slice.

AWS’s strangler fig pattern guidance describes using a proxy layer to route requests during incremental migration between a monolith and new microservices, and notes that introducing such a layer can reduce transformation risk and business disruption. The key design work is the routing rule: method, path, tenant or feature cohort, caller, and fallback behavior. Put rules in versioned configuration and make the chosen destination visible in telemetry.

Start with reads when they can be compared safely. Shadow a request to the new service, discard its response, and compare normalized results offline. Remove volatile fields, but never normalize away meaningful differences. Shadow traffic must be authorized, rate-limited, and prevented from causing side effects. Measure mismatch type, latency, error rate, and the inputs that trigger divergence.

Choose one data authority

A new service can initially read through the monolith’s API, use a replicated view, or own a newly separated schema. Each option needs a freshness and failure model. Directly sharing tables creates coupling around schema, transactions, and deployment, so treat it as a temporary phase with an exit condition.

Dual writes are attractive because they appear reversible, but they can leave systems inconsistent under partial failure. If both stores must receive a mutation, prefer one authoritative commit followed by an outbox or change stream to update the derived store. Make consumers idempotent and track lag. If synchronous dual write is unavoidable, define which write wins, how retries are keyed, and how reconciliation finds missing or conflicting records.

Microsoft’s Strangler Fig pattern emphasizes incremental replacement through a façade that routes requests between the legacy and new systems, and it explicitly calls out shared data stores and cross-system dependencies as migration concerns. Find bypass paths early: scheduled tasks, stored procedures, file imports, and staff tools often evade the proxy. Route or retire each one explicitly.

Cut over with evidence and a rollback clock

Set quantitative entry criteria: shadow mismatch below a reviewed threshold, latency within budget, error handling exercised, support tooling ready, and reconciliation clean. Move a small cohort, then increase by reversible steps. Record the configuration revision with every request so incidents can identify which implementation served it.

Rollback means routing new requests back, but data written during the cutover must still be understandable to the old path. Keep schemas and events backward compatible for the rollback window. Define whether queued work follows the routing decision at enqueue time or execution time. Stop the rollout if ownership becomes ambiguous, not only when error rate rises.

After full cutover, observe through a bounded soak, remove legacy writers, archive reconciliation evidence, and delete the route only when no callers remain. A permanent proxy branch and duplicate data pipeline are not completed migration.

Rehearse failure modes

Test new-service timeout, partial data propagation, duplicate event, stale read, rollback after new writes, a bypassing background job, and concurrent updates across the cutover. Verify user-visible behavior and authoritative data with independent queries.

The next step is to create a one-page route-and-data table for the first capability: caller, route rule, read source, write authority, shadow signal, cutover threshold, and rollback limit. Review it before the first cutover and at each migration phase change.