Strangler Fig Modernization: Replace Software in Stages

Replacing a customer portal in one launch means every important behavior must work at the same moment. A staged replacement can narrow that risk: one capability moves, its behavior is checked, and the next capability follows after the team learns from the first.

The strangler fig pattern gradually replaces parts of an existing system. A routing boundary directs work to the old or new implementation until the old capability can be removed. The difficult decisions concern business boundaries and data ownership, not the routing rule alone.

Check whether the pattern fits

You need a way to direct work between implementations and a capability small enough to validate independently. Shared session state, deeply coupled database writes or unavailable source access can complicate that boundary.

A small application with a controlled replacement window may not justify a long coexistence period. Compare the operational cost of running both systems with the risk and effort of a complete switch.

Microsoft's strangler fig guidance describes incremental replacement through a facade. Treat it as an architectural option that needs application-specific investigation.

Choose a business capability

Start with a capability people can name and accept: customer profile changes, delivery tracking or a pricing inquiry. Avoid splitting merely by technical layer if that leaves the useful workflow dependent on unfinished work everywhere else.

Document the inputs, outputs, side effects and consumers. Identify the behavior that must remain compatible and the intentional changes users will notice.

An illustrative profile migration might preserve customer identifiers while moving address validation into a new service. Its boundary must include updates sent to billing and delivery systems, not just the profile screen.

Make ownership unambiguous

For every record or operation, specify which implementation is authoritative during each stage. Distinguish the system that accepts a change from systems that receive copies.

If both implementations can write the same information, define conflict handling and prove it under failure conditions. Do not introduce dual writes as an automatic requirement; they create additional consistency and recovery work.

A simpler transition may keep one writer while providing compatible reads or controlled replication. Our data migration guide explains how to validate records across that transition.

Build the routing boundary for operation

Test the boundary itself. A new facade can become a bottleneck or an additional failure point if it is treated as incidental infrastructure.

Verify behavior before expanding traffic

Create representative scenarios from the existing workflow. Include invalid input, retries, corrections, authorizations and downstream failures. Compare outcomes using business rules rather than pixel-for-pixel screen similarity.

Where comparison traffic is useful, ensure it cannot create duplicate real-world actions such as payments, emails or stock reservations. A read-only observation approach has different requirements from replaying writes.

Define a release gate and recovery condition for the first user group. Expand only after the evidence supports the next step.

Prevent permanent coexistence

Assign each retained dependency an owner and removal condition. Track old scheduled jobs, direct database consumers and compatibility adapters as delivery work.

A capability is not fully migrated while operators still correct it in the old system or reports silently depend on the old tables. Include those activities in acceptance and retirement reviews.

Revisit the boundary after each slice. The temporary facade may still provide value, or it may be safe to remove once all relevant consumers have migrated. Make that choice deliberately.

Start with a boundary investigation

Tranz Technologies' software modernization service can help assess whether progressive replacement is feasible. Bring one critical workflow and the systems it touches so the first slice can be scoped around a complete business outcome.