Manu's Vault

Technical Migrations De risk Enable Finish

3 min readStatus:Seedling

Core Idea

Technical migrations stall at 80–90% because of motivation asymmetry — the platform team bears the benefit of decommissioning while each holdout team bears the migration cost. De-risk → Enable → Finish treats this as a structural sequencing problem, not a willpower problem.

Technical migrations are one of engineering’s most persistent unsolved problems: teams reach 80–90% completion, then maintain two parallel systems indefinitely. Larson’s framework treats this as a structural sequencing problem.

The Core Problem: Dual-System Overhead

Running two systems simultaneously is expensive: two codebases to maintain, two sets of failure modes to monitor, two mental models for every engineer. Each unmigrated system represents Organizational-Debt that compounds through operational overhead.

The Three Phases

Phase 1 — De-risk

  • Build the new system to functional parity with the old one
  • Prove it handles a representative slice of production load
  • Deliverable: a working new system validated against real load; no production traffic migration yet

Phase 2 — Enable

  • Build tooling, documentation, and migration guides for self-service adoption
  • Make migrating the path of least resistance for product teams
  • Deliverable: runbooks, automated migration scripts, support channels, migration guides

Phase 3 — Finish

  • Retire the old system entirely; migrate every remaining holdout team
  • Goal: eliminate the old system and its maintenance burden completely
  • Deliverable: old system decommissioned; all traffic on the new system

Why Finish Is the Hardest Phase

Motivation asymmetry: the central platform team bears the benefit of decommissioning while each holdout team bears the migration cost. Teams with genuine reasons — tight schedules, complex integrations — don’t migrate. Without a hard mandate, migrations settle at 80–90% indefinitely.

Larson’s Four-Point Guidance for Finishing

  1. Set a hard decommission date with executive backing — soft deadlines are reliably ignored
  2. Build automated migration tooling specifically for tail cases
  3. Offer white-glove migration support for complex holdouts
  4. Track progress publicly — a visible migration dashboard creates accountability without confrontation

Connection to Systems Thinking

The stalled migration is a reinforcing trap: each unmigrated system reduces urgency, which reduces investment in tooling, which makes migration harder. Only a hard forcing function (the decommission deadline) breaks the loop. See Systems-Thinking-Stocks-Flows-Feedback.

Sources

  • Larson, Will (2019). An Elegant Puzzle: Systems of Engineering Management. Stripe Press. ISBN: 978-1-7322651-8-9.

    • Chapter 3.4: De-risk → Enable → Finish migration framework

  • Fowler, Martin (2004). “StranglerFigApplication.” Martin Fowler’s Blog. Available: https://martinfowler.com/bliki/StranglerFigApplication.html

    • Foundational pattern for incremental technical migration with explicit decommission goal

  • Newman, Sam (2019). Monolith to Microservices. O’Reilly Media. ISBN: 978-1-4920-4750-4.

    • Identifies “getting stuck at 80%” as the most common failure mode; advocates for hard cutover deadlines

  • Forsgren, Nicole, Jez Humble, and Gene Kim (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. ISBN: 978-1-942788-33-1.

    • Maintaining parallel legacy systems is a direct drag on deployment frequency and lead time

  • Kim, Gene, Jez Humble, Patrick Debois, and John Willis (2016). The DevOps Handbook. IT Revolution Press. ISBN: 978-1-942788-00-3.

    • Brownfield maintenance costs compound without a forcing function to complete migrations

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks