Under what circumstances would you advise against using a strangler-fig migration to break up a monolith, and what would you recommend instead?

## Two decisions, easy to conflate Strangler-fig migrations are a technique for executing a decomposition safely and incrementally — they are not, by themselves, a justification for why a decomposition should happen at all. A senior engineer's judgment on this question has to separate two decisions that are easy to conflate: 1. **whether** to break a monolith into more independently deployed services in the first place; 2. and, if so, **how** to do it safely. The pattern only helps with the second question; getting the first one wrong and then executing it flawlessly still leaves the organization worse off. ## When it is the right call The strongest case for strangler-fig migration is a large, long-lived system that must keep running and evolving throughout a multi-year effort, where teams genuinely need independent deployment cadence or independent scaling, and where the organization has the **platform maturity** to support running many independently deployed services reliably: - mature CI/CD; - centralized cross-service observability; - and an on-call and incident-response process that scales with the number of deployable units. Absent that maturity, each newly extracted service adds real operational risk (new deployment pipeline, new on-call surface, new class of network-partition and partial-failure bugs) faster than it removes complexity from the monolith, and the migration makes the system objectively harder to operate for a period that can stretch to years before any net benefit is realized. ## When to advise against it There are several concrete circumstances where recommending against a strangler-fig migration is the right call. 1. **First, scale mismatch:** a small system maintained by a small team — say, tens of thousands of lines of code and a handful of engineers — with no actual scaling bottleneck and no organizational need for independent team-level deployment simply doesn't need the operational multiplication that a dozen microservices bring; the multi-year cost of routing infrastructure, dual-write handling, and N times the deployment and monitoring surface is disproportionate to any benefit gained, and a bounded, time-boxed rewrite or targeted refactoring is cheaper. 2. **Second, misdiagnosis:** teams frequently reach for microservices because their monolith's code is badly organized — tangled dependencies, unclear ownership, hard-to-test modules — but that is a problem of internal structure, not of deployment topology, and is directly solved by refactoring toward a **modular monolith**: the same discipline of clear module boundaries, explicit interfaces, and enforced ownership, but still deployed as a single artifact, avoiding network calls, distributed transactions, and per-service operational overhead entirely. 3. **Third, product lifecycle:** if a system is actively being sunset, replaced by a different product, or is otherwise near end-of-life, investing years of engineering effort restructuring its internals is close to pure waste regardless of how architecturally sound the restructuring would be. ## The reverse case A related and equally important failure mode to recognize is the reverse case: organizations that already went through a strangler-fig migration to microservices and later found the decomposition itself, not the migration technique, was the wrong call, and merged services back together. **Segment** published a widely cited engineering post in 2020 describing exactly this: they had decomposed a data-pipeline product into per-integration microservices, and after operating them at real scale found that the cross-service debugging difficulty, on-call burden, and coordination overhead of dozens of small services outweighed the isolation benefits they'd hoped for, so they consolidated most of them back into a single service. It's frequently cited precisely because it demonstrates that a technically well-executed decomposition can still be a net-negative decision if the underlying need for it wasn't strong enough to justify the ongoing operational cost — a distinction between "did we migrate correctly" and "should we have migrated at all." ## The practical recommendation The practical recommendation, then, is to treat "should we decompose this monolith" as a **distinct, earlier decision** from "how do we decompose it," gated on concrete evidence of need — actual scaling limits that a single deployable can't meet, actual organizational friction from multiple teams sharing one release train, or actual reliability requirements that benefit from independent failure isolation — and on the organization's actual platform maturity to run the result reliably. Where that evidence is present, strangler-fig is the right execution technique. Where it isn't, a modular monolith, a smaller bounded rewrite, or simply leaving the system alone are usually the better-value paths, and it takes real discipline for an engineer or an outside consultant not to default to microservices as though it were a self-evidently superior architecture in every case.