Skip to main content
Catalog
T029
Technology

Migration Halfway House

HIGH(80%)
·
February 2026
·
4 sources
T029Technology
80% confidence

What people believe

Incremental migration reduces risk compared to big-bang migration.

What actually happens
-35%Migration completion rate
+300%Migration timeline
-50%Feature velocity during migration
+150%Operational complexity
4 sources · 3 falsifiability criteria
Context

Teams plan incremental migrations — move from monolith to microservices, from REST to GraphQL, from one database to another — one piece at a time. The plan sounds responsible: reduce risk by migrating gradually. But incremental migrations create a prolonged state where both old and new systems coexist. This halfway house is the worst of both worlds. Engineers must understand and maintain two systems. Data flows through compatibility layers that add latency and bugs. New features must work in both paradigms. The migration stalls at 60-70% completion because the remaining 30% is the hardest, least-rewarding work. The organization lives in the halfway house for years, paying the tax of dual systems while getting the benefits of neither.

Hypothesis

What people believe

Incremental migration reduces risk compared to big-bang migration.

Actual Chain
Dual-system maintenance for extended period(Both old and new systems must be maintained simultaneously)
Engineers must understand both systems
Compatibility layers add latency and bugs
Operational complexity doubles during migration
Migration stalls at 60-70% completion(Remaining 30% is hardest and least rewarding)
Easy migrations done first, hard ones deferred
Business pressure redirects engineers to features
Migration champion leaves, momentum dies
New features must work in both paradigms(Feature development 40-60% slower during migration)
Every feature requires dual implementation or compatibility
Testing matrix doubles across old and new systems
Impact
MetricBeforeAfterDelta
Migration completion rate100% planned60-70% actual-35%
Migration timeline6-12 months estimated2-4 years actual+300%
Feature velocity during migrationBaseline-40-60%-50%
Operational complexityOne systemTwo systems + compatibility layer+150%
Navigation

Don't If

  • You don't have a hard deadline and dedicated team for completing the migration
  • The migration doesn't have executive sponsorship that survives priority changes

If You Must

  • 1.Set a hard completion deadline and cut scope rather than extending timeline
  • 2.Dedicate a team to migration — don't split engineers between migration and features
  • 3.Migrate the hardest components first, not last
  • 4.Define 'done' clearly — what gets turned off and when

Alternatives

  • Strangler fig patternRoute new traffic to new system, let old system die naturally
  • Big-bang with rollbackMigrate everything at once with a tested rollback plan
  • Don't migrateSometimes the cost of migration exceeds the benefit — invest in the existing system
Falsifiability

This analysis is wrong if:

  • Incremental migrations consistently complete within 150% of their estimated timeline
  • Dual-system operation during migration doesn't measurably reduce feature velocity
  • Migration completion rates exceed 90% without dedicated migration teams
Sources
  1. 1.
    Martin Fowler: Strangler Fig Application

    Pattern for incremental migration that avoids the halfway house problem

  2. 2.
    Charity Majors: The Migration Tax

    Analysis of how migrations consume engineering capacity for years beyond estimates

  3. 3.
    Shopify: Modular Monolith Migration

    Shopify's experience with a multi-year migration that required dedicated teams

  4. 4.
    Uber Engineering: Microservice Migration Lessons

    Uber's documentation of the prolonged dual-system state during their migration

Related

This is a mirror — it shows what's already true.

Want to surface the hidden consequences of your engineering decisions?

Try Lagbase