Service Extraction Cutover Checklist

When to Use This Checklist

Use this checklist during the cutover phase of extracting a service from a monolith, when live traffic moves from the old code path to the new service. Cutover is where extractions most often fail, because it touches both routing and data at the same time. The goal is a gradual, reversible shift with no downtime or data loss.

How to Use This Checklist

Confirm the service has passed its production-readiness review first. Put a strangler-fig routing layer or feature flag in front of the endpoints so traffic can move in controlled steps. Optionally run the service in shadow mode to compare outputs before any real traffic shifts. Migrate the owned data with a clear source of truth and verify consistency before cutover. Then shift traffic in stages with explicit go/no-go thresholds, keeping a fallback to the monolith until the new path is proven.

Rehearse rollback before the window, not during it.

What Good Looks Like

A clean cutover shifts traffic gradually behind a router, with golden-signal dashboards and alerts watching the new path. Data is consistent between stores, a fallback or dual-write protects against errors, and on-call ownership is clear. The monolith code path is decommissioned only after a soak period confirms stability, and rollback has been rehearsed.

Common Pitfalls

The worst pattern is a single all-at-once switch with no fallback. Teams cut over routing before data is consistent, causing lost or stale writes. Decommissioning the old path too early removes the safety net. Missing dashboards on the new path mean problems go unnoticed until users report them.

Related Resources

See the strangler-fig pattern, feature flag best practices, and canary release practices for staged shifts. The expand-and-contract pattern guides data migration, and the four golden signals define what to monitor.