For a large enterprise, the hardest part of replacing a monolithic application is rarely building the new services. It is changing an application that processes real transactions, supports customer journeys, connects to dozens of downstream systems, and still needs releases every week.
A complete rewrite creates an uncomfortable trade-off. Engineering teams can spend months rebuilding the platform while product teams wait for capabilities, or they can continue modifying the legacy system and increase the gap between the old and new architectures.
The Strangler Fig pattern offers another path.
Instead of replacing the monolith in one release, teams progressively move capabilities outside it. New services run alongside the existing application. Traffic shifts incrementally. The monolith gets smaller until nothing important depends on it.
AWS describes the approach as a way to reduce transformation risk and business disruption while allowing legacy and modernized systems to coexist.
For enterprise engineering leaders, however, the important question is not whether the pattern works. It is whether their organization can execute it without converting one complicated monolith into fifty tightly coupled services.
Why is the Strangler Fig pattern safer than rewriting a monolith?
A big-bang rewrite concentrates risk around one cutover.
Authentication, pricing logic, reporting, transactions, integrations, customer data, batch processing, and operational workflows may all change simultaneously. Testing every interaction before switching traffic becomes difficult, particularly when years of undocumented behavior exist inside the application.
Strangler Fig reduces the size of each migration decision.
Consider an insurance platform containing policy management, document generation, payments, customer profiles, claims, and notifications. The engineering organization might first extract notifications because the capability has relatively clear boundaries.
A routing layer sits in front of the application. Requests for notifications move to the new service, while other requests continue to the monolith.
The same process can later be repeated for documents, customer profiles, or another domain.
The architecture therefore changes through controlled production increments instead of one replacement event.
That distinction matters because modernization can continue while product delivery continues.
AWS specifically recommends the pattern when a big-bang migration is too risky, the business needs new features during modernization, and user disruption must remain minimal.
It also creates a practical rollback mechanism. If the extracted service misbehaves, routing can return traffic to the legacy implementation, provided the organization has kept its data contracts and rollback strategy compatible.
What architecture is required to migrate without downtime?
The pattern is sometimes described as putting an API gateway in front of a monolith and gradually redirecting endpoints. That explanation is technically correct but incomplete.
Enterprise implementations usually require several architectural controls working together.
- A routing layer must separate old and new functionality without changing the customer-facing contract. API gateways, reverse proxies, service meshes, or application-level routing can direct requests toward either implementation. Initially, almost everything reaches the monolith. As capabilities move, individual routes switch to new services. This routing infrastructure needs production-grade availability because it becomes part of the critical request path.
- Service boundaries must follow business domains rather than convenient code modules. Extracting arbitrary packages often creates network calls between functions that previously communicated in memory. Teams should identify bounded contexts, ownership boundaries, transaction requirements, scaling characteristics, and dependency patterns before deciding where a service begins. Domain-driven design and event storming can help reveal those boundaries. AWS similarly warns that premature decomposition can produce incorrect service boundaries.
- An anti-corruption layer should protect the new architecture from legacy assumptions. The monolith may represent a customer, transaction, or account differently from the new service. An adapter can translate between models so the extracted service does not inherit every historical interface. AWS recommends this approach when existing components still need to communicate with functionality that has already moved outside the monolith.
- Data ownership must move deliberately. Extracting application code while leaving every service permanently connected to one shared database usually preserves the original coupling. A service should eventually own the data required for its domain. During transition, change-data capture, events, synchronization processes, backward-compatible schemas, or temporary replication may be necessary. These mechanisms should have an expiration plan rather than becoming permanent architecture.
This is why zero downtime is primarily a coexistence problem, not a deployment trick.
How can teams move data without breaking production transactions?
Data is usually where Strangler Fig migrations become difficult.
Code can be routed. Database ownership cannot always be switched overnight.
Suppose an enterprise extracts customer profiles from a monolith. The new profile service receives production traffic, but billing, reporting, fraud systems, and older applications still read the original customer tables.
Deleting those tables immediately would break the estate.
The migration therefore needs a temporary data bridge.
One approach makes the new service the system of record and publishes changes through events. Legacy consumers receive synchronized copies until they migrate to the new contract. Another uses change-data capture while the old database temporarily remains authoritative.
Dual writes should be approached carefully because failures can leave two systems disagreeing about the same transaction.
Schema evolution also matters. Database changes should remain backward compatible while both application versions operate. DORA specifically highlights backward-compatible data and schema changes as an important requirement when teams use rolling or blue-green deployment approaches to achieve little or no downtime.
Engineering leaders should therefore treat each extraction as a reversible migration with explicit checkpoints: traffic, application logic, data ownership, downstream consumers, observability, rollback, and finally deletion of the legacy implementation.
Removing the old code is important. A modernization program that continually creates services but never eliminates legacy functionality simply expands the technology estate.
What commonly goes wrong when enterprises adopt microservices?
The most expensive failure is creating a distributed monolith.
The organization technically operates dozens of services, but teams still need synchronized releases, shared test environments, coordinated database changes, and approvals from several other teams before deploying.
The architecture changed. The delivery model did not.
DORA’s research on loosely coupled teams emphasizes that architecture should allow teams to test, deploy, and modify services independently. It also notes that adopting microservices does not automatically produce those outcomes.
That gives technology leaders a useful test for every extraction.
Can the owning team deploy the service during normal working hours without coordinating releases across six other teams?
Can it test most changes without recreating the entire enterprise application?
Can a failure remain isolated instead of cascading through the platform?
If the answer remains no after several migration waves, the program may be moving complexity rather than reducing it.
Observability must evolve at the same time. A monolith may offer one application log and one transaction trace. A distributed architecture introduces network failures, queue delays, retry storms, partial transactions, dependency failures, and service-level latency.
Metrics, distributed tracing, structured logs, correlation IDs, SLOs, circuit breakers, timeouts, and dependency dashboards therefore become part of the modernization architecture itself.
Which consulting companies can support a Strangler Fig modernization program?
Organizations with large application estates sometimes bring in external engineering or modernization specialists for estate assessment, domain decomposition, platform engineering, migration execution, or capability augmentation.
Three companies illustrate different engagement profiles.
GeekyAnts works across digital transformation, architecture assessment, legacy application modernization, refactoring, platform migration, and system integration. Its positioning can suit organizations looking for engineering-oriented modernization work where implementation sits close to architecture decisions.
Accenture operates at a broader enterprise transformation level, including application-estate assessments, modernization strategy, architecture, decomposition, migration sequencing, cloud enablement, and patterns such as microservices and Strangler Fig. This can fit programs where modernization spans substantial organizational and technology portfolios.
IBM is another established option for enterprises evaluating hybrid-cloud and application-modernization programs, particularly where modernization intersects with complex infrastructure and long-standing enterprise technology estates.
The better selection criterion is not simply company size. Engineering leaders should ask whether the partner can work through domain boundaries, legacy dependencies, data migration, platform engineering, production observability, rollback design, and service ownership rather than only rebuilding application screens or moving workloads to containers.
How should engineering leaders decide where to start?
The first target should rarely be the largest module.
A better candidate combines meaningful business value with a manageable dependency surface.
Architecture teams can map domains by release frequency, incident rate, scaling constraints, change demand, coupling, business criticality, database dependencies, and engineering effort. That map reveals components where independent ownership could materially improve delivery.
The first extraction should then prove more than technical feasibility.
It should prove that a team can independently build, test, deploy, observe, operate, and roll back a production service while the rest of the organization continues using the monolith.
From there, modernization becomes a sequence of measurable changes rather than a multi-year promise of a future platform.
That is ultimately the value of the Strangler Fig pattern. It does not eliminate migration risk. It breaks that risk into smaller decisions that engineering teams can observe, reverse, and improve.
For a VP of Engineering evaluating a large modernization program, the useful starting conversation is therefore not, “How quickly can the monolith become microservices?”
It is: Which domain can be separated first, what dependencies prevent independent operation today, and what architecture would allow that capability to move without interrupting customers?
Answering those questions through an architecture and modernization assessment before committing to a migration roadmap can expose whether Strangler Fig is the right approach, where the first boundary should sit, and what needs to change in the platform before production traffic starts moving.
