Manu's Vault

Technical-Migrations-De-risk-Enable-Finish

4 min readStatus:Seedling

Technical migrations are one of engineering’s most persistent unsolved problems: teams begin a migration with enthusiasm, reach 80–90% completion, then maintain two parallel systems indefinitely. Larson’s De-risk → Enable → Finish framework treats this as a structural sequencing problem, not a willpower 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. Yet this is the default outcome of unstructured migrations. Each unmigrated system represents a form of Organizational-Debt: a structural liability that compounds interest through operational overhead, precisely because no one team owns the cost of the stall.

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 (not all edge cases)
  • Goal: answer “can the new system work?” with confidence
  • 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
  • Goal: answer “can teams migrate without our help?” with confidence
  • Deliverable: runbooks, automated migration scripts, support channels, migration guides

Phase 3 — Finish

  • Retire the old system entirely
  • Migrate every remaining holdout team — including complex and resistant cases
  • 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

Finish fails due to motivation asymmetry: the central platform team bears the benefit of decommissioning while each holdout team bears the cost of migrating. Teams that haven’t migrated usually have genuine reasons — tight delivery schedules, complex integrations, atypical usage patterns. No one is being unreasonable; the incentives simply don’t align.

Without a hard mandate, migrations settle at 80–90% complete indefinitely. The last 10–20% of unmigrated systems often represent the highest operational overhead — the unusual cases requiring the most edge-case handling in the old system.

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 the tail cases
  3. Offer white-glove migration support for complex holdouts — meet teams where they are
  4. Track progress publicly — a visible migration dashboard creates accountability without confrontation

Connection to Systems Thinking

The stalled migration is a reinforcing trap in Systems-Thinking-Stocks-Flows-Feedback terms: each unmigrated system reduces urgency to finish, which reduces investment in migration tooling, which makes migration harder, which lowers migration rate further. Only an external forcing function (the decommission deadline) breaks the loop.

Sources

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

    • Chapter 3.4: Three-phase De-risk → Enable → Finish migration framework; motivation asymmetry; four-point guidance for completing migrations

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

    • Named for the strangler fig tree that grows around a host tree and eventually replaces it; foundational pattern for incremental technical migration with explicit decommission goal; parallels the Enable and Finish phases directly

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

    • Comprehensive treatment of migration execution; identifies “getting stuck at 80%” as the most common failure mode; advocates for hard cutover deadlines and migration support teams for complex holdouts

  • 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.

    • Research demonstrating that maintaining parallel legacy systems is a direct drag on deployment frequency and change lead time; empirical grounding for the cost of the stalled migration problem

  • Kim, Gene, Jez Humble, Patrick Debois, and John Willis (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. ISBN: 978-1-942788-00-3.

    • Part V discusses managing legacy system transitions and the importance of explicit decommission plans; notes that 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