Skip to content

PATTERN Cited by 1 source

Scoped migration with fast-follows

Scoped migration with fast-follows is the pattern of deliberately constraining a migration's scope to only the substrate being swapped — and pipelining all the improvements you want along with the migration as a sequence of fast-follows after the migration stabilizes, not bundled into it.

The shape:

  1. Define the tight scope: change only the substrate; keep the abstraction above identical (concepts/tight-migration-scope).
  2. Accept two explicit exceptions to the tight-scope default:
  3. Matching old behavior is more expensive than absorbing the second-order effect of changing it.
  4. The decision is a one-way door — retrofitting later is expensive enough to warrant the scope hit now.
  5. List the out-of-scope improvements as "fast-follows" — tracked, prioritized, scheduled for right after the migration stabilizes.
  6. Pipeline: migrate in parallel with shipping fast-follows. Each fast-follow lands on the new substrate after the primary cutover moves through the fleet. Both streams compound.

Why pipeline rather than bundle

  • Risk additivity. Bundling N changes into one migration N-multiplies the failure modes. Pipelining makes each failure isolated.
  • Pace of value. Fast-follows deliver customer-visible wins during the period when the migration is still in progress.
  • Organizational focus. The migration team stays focused on the substrate cutover; a separate workstream or a de-risked team picks up each fast-follow.
  • Real data informs fast-follows. Once the substrate is live, fast-follows benefit from actual production behavior shaping their design.

Figma's instantiation (ECS → EKS, 2024)

In-scope (the substrate itself and one-way doors):

Fast-follows (deferred, shipped after migration stabilized):

  • Keda horizontal pod auto-scaling.
  • Vector sidecar replacing the Lambda-based CloudWatch log forwarder.
  • Graviton migration of the most expensive service.
  • Service-mesh adoption (Envoy-based) for internal networking reliability / observability.
  • Moving more resources out of Terraform into AWS Controllers for Kubernetes.

Figma's framing: "This pipelining of workstreams ended up being an effective way to provide incremental benefits to our users and the company without upscoping the migration process."

When the pattern fails

  • Fast-follows never happen. If the organization doesn't actually schedule and staff the deferred improvements, "fast-follow" becomes "permanent tech debt." Counter: explicit fast-follow list with owners and dates at the time the deferral is made.
  • The migration would regress without the improvement. If the new substrate performs worse without a deferred improvement, defer is wrong — the improvement is in-scope. (Figma judged Karpenter as this class.)
  • The deferral creates a second migration. If the deferred improvement will require re-migrating or re-shaping data, it's a one-way door and belongs in-scope.

Signals the deferral list is right

  • Each fast-follow is independently implementable on the new substrate without touching the substrate choice.
  • Each fast-follow has a clear customer-visible win.
  • The migration-scope + fast-follow-list together cover what a single bundled migration would have tried to do.

Contrast with incremental delivery

  • concepts/incremental-delivery (EBS framing) is the multi-year, multi-project posture: never-big-bang, always-a-direction.
  • Scoped-migration-with-fast-follows is the within-a-migration posture: same principle, smaller time horizon. A single migration plus its fast-follows is one instantiation of incremental delivery.

Seen in

Last updated · 200 distilled / 1,178 read