The safest way to modernize a large system is usually to replace one capability at a time while the old and new coexist.

Why it matters in real Java systems

A big-bang rewrite of ordering or payments is rarely the responsible path for a running business. Incremental extraction lets the team learn boundary quality, production behavior, and data migration realities one capability at a time without betting the whole platform on one cutover date.

The main design idea

The Strangler Fig pattern surrounds an old system with a new boundary layer, then gradually redirects requests or events to new implementations. Over time, the legacy surface shrinks until the old capability can be retired. This approach lowers migration risk and creates feedback loops that a rewrite cannot provide.

It works best when the extracted capability has a clear boundary, well-understood data ownership, and measurable traffic. It works poorly when teams try to strangler everything at once or when no one can define what the legacy system actually owns.

Key ideas to keep in mind

Migration sequence

Java example in the Order Management domain

package org.javaomnibus.migration;

public final class OrderRoutingFacade {
    private final LegacyOrderSystem legacyOrderSystem;
    private final NewOrderService newOrderService;

    public OrderView findById(String orderId) {
        return isMigrated(orderId)
            ? newOrderService.findById(orderId)
            : legacyOrderSystem.findById(orderId);
    }

    private boolean isMigrated(String orderId) {
        return orderId.startsWith("N-");
    }
}

Step by step

1. The façade lets old and new implementations coexist behind one stable caller boundary.
2. Real migrations use more sophisticated routing logic, but the pattern is the same.
3. The migration becomes incremental and observable instead of all-or-nothing.
4. This is modernization through controlled replacement rather than one-shot reinvention.

Where this helps in practice

• Modernizing monolith modules one capability at a time
• Replacing legacy order, payment, or inventory subsystems safely
• De-risking platform migration with progressive traffic movement

Trade-offs and when to be careful

• Strangler Fig lowers migration risk, but it creates a temporary coexistence period that requires discipline and cleanup.
• Teams must avoid letting temporary routing and duplicate logic become permanent architecture.

Frequent mistakes to watch for

• Trying to strangler too many capabilities at once
• Choosing seams that are not true business boundaries
• Leaving dual-write and dual-read paths undocumented and unobserved
• Never retiring the legacy path after confidence is achieved

Related concepts