Strangler Fig Pattern Examples & Case Studies

Across this series we built the strangler fig pattern from the ground up: the facade that routes, the anti-corruption layer that translates, the loop that runs it slice by slice, the failure modes that stall it, and the parallel-run-flag-rollback discipline that keeps each step safe. This last part puts it in motion. The pattern is one of the most widely documented incremental-migration approaches in the industry — Martin Fowler described it in 2004 from real client projects, and it has since become a default for migrating off monoliths, mainframes, and forms-based systems. The walkthroughs below are illustrative system shapes, not named client engagements, but they show how the machinery reads as a migration you could actually run.

Example 1: a web monolith behind a reverse proxy

The most common shape. A large web application — years of accreted routes, one deployable, one database — that’s slow to change and risky to touch. The seam is the cleanest one available: HTTP.

How it unfolds. A reverse proxy is placed in front of the monolith as the facade. On day one it forwards every route to the monolith unchanged. The team picks a first slice — say, a self-contained reporting endpoint: low blast radius, a clean seam, enough realistic complexity to exercise the whole apparatus. They build a modern service for it, with an anti-corruption layer translating between the monolith’s database shapes and the service’s clean model. The facade mirrors live traffic to the new service (parallel run), divergences are resolved, and once parity holds, a flag ramps that route’s traffic from the monolith to the service — canary, step, full. The legacy route is deleted. Then the next route.

Over the program, the proxy’s routing table shifts from “everything to the monolith” to “everything to services,” and the monolith is emptied route by route until it can be retired. This is the textbook application of the pattern, and the one Fowler’s original description maps onto most directly.

Example 2: a mainframe batch system

A harder shape, and core territory for business-critical legacy. A mainframe runs a nightly batch — dozens of COBOL jobs orchestrated by a scheduler, reading and writing shared datasets, closing the books or settling transactions. There’s no HTTP seam. The seam is the job.

How it unfolds. Rather than reroute requests, the facade here is at the orchestration layer: the scheduler still drives the batch, but individual jobs are peeled off to modern services one at a time. A job is reimplemented as a modern service, fronted by an anti-corruption layer that reads and writes the legacy datasets (or a relational store kept in sync) in the shapes the rest of the batch expects. The modern job runs in parallel against real production data, its outputs reconciled against the legacy job’s — the parallel run, adapted to a batch cadence where “shadow” means a comparison run rather than mirrored live requests. When the reconciliation is clean across real cycles, including period-end, the scheduler is pointed at the modern job and the COBOL job is retired.

One caveat, consistent with the pattern’s limits: batch side effects and shared datasets make isolation genuinely hard, and the observation window has to span the system’s real periodicity — a settlement job has to survive a real month-end, not a quiet Tuesday. This is slower and more careful than the monolith case, by necessity. (Stack-specific guidance lives in the modernization guides.)

Example 3: a forms-based application

A third common shape: an Oracle Forms, PowerBuilder, or similar forms-based application — business logic and UI fused together, a thick client over a database, screens that encode workflows nobody fully documented. The seam is the workflow.

How it unfolds. The facade fronts the data and service layer, and the application is migrated one workflow at a time. A single screen’s workflow — order entry, say — is reimplemented as a modern UI talking to a modern service, with an anti-corruption layer over the legacy schema so the new workflow reads and writes data the old screens still depend on. Both UIs coexist during the ramp: some users (or some workflows) on the new screen, the rest on the legacy forms, with sticky assignment keeping each user coherent. Parity here is checked on both the data effects and the workflow’s outcomes. As each workflow moves over, the forms application loses screens until it’s an empty shell to retire.

The hard part in this shape is untangling logic that lives in the form from logic that lives in the database — a slicing problem, which is exactly why slice boundaries are a discovery-phase decision.

What the three examples share

Different seams — route, job, workflow — but the same skeleton every time:

	Web monolith	Mainframe batch	Forms application
Seam	HTTP route	Scheduled job	Screen workflow
Facade	Reverse proxy	Orchestration layer	Service/API front
Parallel run	Mirrored live requests	Reconciled comparison runs	Mirrored + dual-run UIs
Retire when	Route emptied	Job replaced and reconciled	Workflow moved over

In every case: old and new run side by side, the legacy system keeps the business running, each slice is proven before it carries load, any slice can roll back, and the legacy system is retired only when it’s empty — not amputated, outgrown.

Examples are illustrations, not promises

These walkthroughs are composites of common system shapes, not case studies with named clients or guaranteed numbers — and presenting them as anything more would betray the standard this series holds to. Every real system has specifics that move the plan: how clean the seams are, how entangled the data is, how much of the behavior the spec actually captured. The pattern is well-proven and widely documented; the timeline and effort for your system are knowable only after reading your actual code. ModernLift’s published figures — discovery in three to four weeks, first slice to production in six to ten — are based on engineering modeling, with early engagements underway. Treat them as a shape to expect, not a quote.

Where to go from here

If your system looks like one of these — a monolith you can’t change quickly, a mainframe batch nobody wants to touch, a forms application fused to its database — the strangler fig pattern is very likely the right shape, and the next step is to find the seams in your code. A few concrete starting points:

• See whether the runtimes underneath your system are still supported with the software EOL checker — unsupported runtimes are often what turns a “someday” migration urgent.
• Put numbers on the cost of waiting versus acting with the legacy cost calculator.
• Read the stack- and industry-specific modernization guides for COBOL, mainframe, Oracle Forms, .NET, and more.
• When you’re ready to map your system’s seams, book a 30-minute discovery call — no deck, just a look at your actual constraints.

The systems that built your business deserve a future as serious as their past. The strangler fig pattern is how you give them one without betting the business on a cutover date.