A replacement program can spend a year rebuilding behavior before a customer sees any benefit. Meanwhile, the existing system keeps changing. The team inherits two backlogs and a moving definition of parity.
Martin Fowler’s Strangler Fig approach offers a practical alternative: move selected behavior into new components while the existing system continues to operate. The difficult work is finding a boundary that can hold during the transition.
Choose a slice with an observable benefit
Start with a capability whose current limitations have a business consequence: quote amendments that require manual re-entry, a customer journey blocked by a nightly batch, or a release that needs coordination across several teams. Set a baseline for the delay, error rate, or operating cost.
Then test whether the capability can be separated. Map its reads, writes, callers, and less visible consumers such as regulatory extracts. A clean API at the front can conceal a shared database underneath. If every change still requires a coordinated release, the boundary has not bought much independence.
Design the period when both systems exist
Decide which system is authoritative for each record during migration. Avoid casually introducing writes to both stores: one can succeed while the other fails. Where replication is necessary, specify ordering, retries, reconciliation, and the recovery procedure.
Route a bounded set of traffic to the new component and compare behavior where it is safe to do so. Shadow reads can expose differences without changing customer outcomes. Writes need more care because replay can duplicate a business action.
Rollback must cover state as well as code. If the new component creates records the old system cannot understand, redirecting traffic is not a complete recovery plan. Rehearse the path back before increasing traffic.
Pay for retirement, not indefinite duplication
Give transitional components an owner and an exit condition. Retirement should cover remaining consumers, historical records, audit obligations, support procedures, and licenses. Until those are resolved, the old system still costs money and carries operational risk.
Review each slice on both business benefit and reduced dependency. Did quote changes get faster? Can the new component be released independently? Has any infrastructure actually been retired? Workloads moved is a useful activity count, but it does not answer those questions.
Incremental replacement is not always the cheapest option. A small, well-understood application may be easier to replace outright. Use the approach where coexistence reduces risk enough to justify the temporary complexity.
THE PRACTICAL TAKEAWAYA modernization slice is complete when it delivers a useful change and has a credible path to retiring the behavior it replaces.