How Strangler Fig Migrations Go Wrong
The pattern is sound, but implementations fail for predictable reasons. Knowing these anti-patterns helps you avoid them before they become expensive.
1. The Eternal Strangler
The migration starts strong — the first two services are extracted successfully. Then momentum dies. The remaining 80% of the monolith stays forever, now with the added complexity of a proxy layer and multiple services. You've made the architecture worse, not better. The team is now maintaining two systems indefinitely.
Prevention: Set a timeline. Define "done" upfront. Track migration progress on a dashboard visible to leadership. Assign a dedicated migration owner who is accountable for completion, not just progress.
2. The Distributed Monolith
New services are extracted but remain tightly coupled to the monolith — they call back into it for data, share the same database, and must be deployed in lockstep. You now have the complexity of microservices with none of the benefits. Incidents are harder to diagnose because failures cascade across service boundaries.
Prevention: Each extracted service must own its data. Define a "Definition of Done" for extraction: the service must function (even in degraded mode) when the monolith is completely unavailable.
3. The Proxy Bottleneck
The proxy becomes a single point of failure or a performance bottleneck. Every request now has an extra network hop, and the proxy's routing table becomes a complex, fragile configuration file that only one person understands.
Prevention: Use battle-tested proxy technology (Envoy, NGINX). Run the proxy in a highly available configuration (multiple instances behind a load balancer). Implement health checks. Store proxy configuration in version control with code review. Consider a service mesh for complex routing scenarios.
4. The Data Swamp
CDC pipelines are set up but never cleaned up. Data flows in multiple directions. Nobody knows which database is the "source of truth" for a given entity. Schema changes in the legacy DB break CDC connectors silently, and the team only discovers the problem days later when the new service's data is weeks out of date.
Prevention: For each data entity, explicitly document which system is the "system of record" at each phase of migration. Monitor CDC pipeline consumer lag and alert if it exceeds a threshold. Treat CDC pipeline health as a production SLO.
5. The Scope Creep Extraction
While extracting a service, the team decides to also redesign the data model, add new features, switch programming languages, and adopt a new framework — all at once. The extraction takes 6 months instead of 6 weeks, and the risk profile approaches that of a Big Bang rewrite.
Prevention: The first version of the extracted service should be a faithful reproduction of the monolith's behavior, not an improvement. Improvements come after the extraction is complete and the service is stable. Separate "extract" from "enhance."