The strangler fig pattern: gradually extract services from the monolith without a big-bang rewrite. The monolith keeps running and shrinks over time.

Phase 1: Observe (month 1–2) Map the monolith: bounded contexts, DB tables, traffic patterns Identify extraction candidates: high-change rate, clear boundaries, team ownership Add instrumentation: trace every module call (basis for SLO baseline) Phase 2: Strangle at the edges (month 3–9) Extract peripheral services first (auth, notifications, image resizing) Use API gateway to route: /auth → new service, everything else → monolith Share the DB initially — acceptable short-term compromise Phase 3: Extract core services (month 9–18) Separate DB per service (Database Decomposition pattern) Dual-write during transition → cut over → remove monolith path Beware: distributed joins now need API calls or data denormalisation Phase 4: Retire monolith (month 18–24) Shell is empty — decommission

What makes migrations fail

✗ Big bang rewrite (6 months, then nobody uses the new system) ✗ Extracting too many services simultaneously (coordination overhead explodes) ✗ Shared DB for too long (services can't evolve schemas independently) ✗ No SLO baseline before extraction (can't tell if new service is worse) ✗ Wrong first extraction (core transactional service → high risk)

Principal answer: The decision to migrate should be driven by pain, not hype. If the monolith deploys weekly with a 5-person team and has 99.9% uptime — don't migrate. Migrate when: deploy takes 2+ hours blocking all teams, a bug in billing affects the feed algorithm, or you need to scale one component 10× without scaling all. Team topology (Conway's Law) should drive service boundaries, not technical architecture.