playbook.crastinating.pro
ScopeOne-way doorPublished 29 April 2026 · 5 min

Migration scope: incremental, big-bang, or strangler

Three honest shapes for any migration. The wrong shape is the most common failure mode.

When to reach for this

The shape of the problem this playbook is for.

  • Replacing a database, framework, language, or vendor that touches more than three services.
  • A 'we'll migrate as we go' has been the plan for >12 months and is still 30% done.
  • The new system is built but the old one is still doing 90% of the traffic.

Signals you're ready

If these aren't true, you're not deciding yet — you're scoping.

  • There is a defined target architecture, not just a wish.
  • You can list the services or call sites in scope.
  • You can tell the difference between 'feature complete' and 'production complete' on the new system.

The rubric

Numbered, weighted, opinionated. Walk through them in order — the first decisive answer often ends the meeting.

  1. Decisive

    Can the old and the new run side-by-side, with traffic shadowed or split?

    Yes → strangler is almost always right. No (e.g., shared mutable state, single source of truth) → incremental is risky; consider big-bang with a serious rollback plan.

  2. Heavy

    What's the longest the old and new can coexist before the cost of running both gets prohibitive?

    If <3 months: pick big-bang or accelerated incremental, write the rollback plan first. If >12 months: strangler is fine. Between: pick incremental with a hard cutover date for the long tail.

  3. Heavy

    Is the new system feature-complete on day one, or do customers care about the gap?

    Feature parity day-one is rare and expensive. If gaps exist, can the old system serve those cases until the new one catches up? If not, you're not ready to start migrating.

  4. Tiebreaker

    What's the rollback plan, and have we run it?

    If you can't roll back to the old system in under an hour, you're not migrating — you're rewriting under load. Run the rollback in staging before flipping any production traffic.

Default pick

When the meeting is going in circles, ship this — and write down what would change your mind.

Strangler-fig migration. Stand up the new thing alongside the old, route traffic by shape, and shrink the old one's footprint until it has zero callers. Pick a real end-of-life date the day you start.

Red flags

Patterns that mean the playbook isn't your real problem.

  • 'It's almost done' has been the status for more than two quarters.
  • The new system has higher latency than the old one and the team is calling it 'a regression we'll fix later'.
  • Nobody has done a rollback drill since the migration started.

Real applications

The playbook used in anger — context and outcome.

  • Context
    Rewriting the legacy monolith billing flow into three services.
    Outcome
    Strangler with traffic-shadow → 5% canary → 50/50 → 100. Took 11 weeks; rollback used in week 3 for one tenant cohort and was uneventful.
  • Context
    Postgres 11 → 16 across 6 databases.
    Outcome
    Big-bang per database, with read-replica promoted as cutover. 30 minutes of write-pause per DB. Single rollback exercised in staging twice before each production run.

Related briefs

Real decisions that used this playbook, written up in the Library.