Strangler Fig in a regulated codebase

The phrase “Strangler Fig” gets thrown around in modernization pitches without a lot of discipline. Most teams hear it and picture two codebases running side by side for six months, slowly handing traffic from old to new, with someone at a whiteboard explaining which routes are on which version. That is the silhouette of the pattern, but it is not the pattern.

The pattern is more disciplined: it routes individual capabilities through a thin facade that decides, per request, whether the call goes to the old monolith or the new module. The facade is the only piece both versions agree on. The old code keeps shipping until the new code is ready to take over. Cutover happens per route, not per release.

In an unregulated codebase, Strangler Fig is a useful pattern. In a regulated codebase, it is often the only safe pattern available. The rest of this post is what changes when the audit team is in the room.

What “regulated codebase” actually constrains

Engineers who have not shipped in regulated finance often underestimate what the audit constraint does to a migration. The constraint is not “we have to write more tests.” The constraint is that every state of the system, at every point in time, must be explainable in writing to a regulator with a clipboard. A migration that produces a “mixed estate” of half-old, half-new code is exactly the kind of state that is hard to explain. The regulator’s question will not be “is the new code working?” The regulator’s question will be “during the period of mixed deployment, can you tell me which version handled customer X’s transaction Y on date Z, and what version of your audit log was in effect?”

That question is answerable, but only if the migration was designed with it in mind from day one. Strangler Fig is the pattern that lets you answer it.

What changes in a regulated context

Four things change when you apply Strangler Fig under regulatory pressure.

1. The seam matters more than the pattern

In an unregulated codebase, the seam between old and new can be drawn wherever the code is easiest to split. In a regulated codebase, the seam has to align with the audit boundaries. Each capability you migrate has to be a complete audit-relevant unit. You cannot have a Strangler Fig migration that handles half of a regulated workflow on the new code and half on the old, because the audit trail for that workflow has to be coherent.

In practice this means the seams are coarser than engineers usually want them. The migration team will draft a seam map at week one and the compliance lead will redraw half of it. That is the expected work. A seam that the engineering team finds awkward is much cheaper than a seam that produces a 14-month-of-mixed-audit problem.

2. Feature flags are per-tenant, not per-build

The usual Strangler Fig setup ramps traffic by percentage. Ten percent of users see the new code, then twenty, then fifty. In a regulated codebase, percentage-based ramping fails the audit question above: which version handled which customer.

The right pattern is per-tenant or per-account flagging. The decision of which version handles a customer’s transaction is recorded explicitly, stored durably (because that decision becomes part of the audit data), and is reversible by compliance, not just by engineering. The flag system is heavier than the toggle libraries most teams already use. It has to be: it has become part of the audit surface.

3. Telemetry reconciles the old and new paths

Every request that goes through the facade emits a telemetry event identifying which path served it. The telemetry has to be reconciled against the audit trail. This is more work than it sounds, because the old code path’s telemetry is often inconsistent with what the new code path emits. The reconciliation step is what catches the cases where the migration “looked clean” in dashboards but produced an audit gap.

We tend to build a small reconciliation job that runs nightly during the migration window. It compares the request volume per capability across old and new code paths to the audit log volume. Any drift, even single-digit, gets a ticket. By the end of the migration the reconciliation job has caught more issues than the test suite.

4. Cutover criteria are written and signed off by compliance

This is the part most teams skip. The decision that the new code is “ready” to take over has to be made explicit in writing, with cutover criteria signed off by compliance before the flag flips, not after. The criteria look like this:

• Eval suite at 100% pass on the cutover-day set.
• Reconciliation job at zero drift for thirty consecutive days.
• All audit-relevant edge cases enumerated by compliance are covered by an explicit test.
• Rollback path tested in production-shadow within the last seven days.

A cutover criterion that lives only in engineering-speak (“the team thinks it is ready”) will not survive a post-incident review.

Common failures

The two failures we see most often:

The mixed-audit estate. The team migrated quickly, did not align seams with audit boundaries, and produced an audit log that has to be reconstructed retroactively to answer a regulator query. This is recoverable but expensive, often a quarter of work to produce the explanation.

The eternal migration. The team set up the facade, started the migration, hit one hard seam at week eight, and never finished. Two years later the codebase has both versions in production, the facade is now load-bearing infrastructure no one wants to touch, and the original engineering benefits of the migration have been eaten by the coordination cost.

The fix for both is the same: get the seam map right in week one, and make the cutover criteria explicit early.

When Strangler Fig is the wrong pattern

Strangler Fig is overkill for codebases small enough that a single team can rewrite in less than a quarter, with a maintenance window long enough to cut over in one release. Most teams over-estimate the size of their codebase and apply Strangler Fig where a focused rewrite would have shipped faster. The honest test: if the codebase is less than 30,000 lines of code, has fewer than 10 audit-relevant workflows, and the team can give up two weekends for cutover, you do not need Strangler Fig.

You do need it when those numbers are larger, the maintenance window is shorter, and the regulator is watching. Which describes most of the engagements we take.

The summary, one paragraph

Strangler Fig in a regulated codebase is not the unregulated version with more meetings. It is a different shape of work: coarser seams, per-tenant flags, reconciliation against the audit trail, and cutover criteria written down before the flag flips. The reward for doing it this way is that the migration produces no audit gap. The cost of skipping any of it is a regulator query you cannot answer in writing.