Legacy modernisation without the big-bang rewrite

Why rewrites stall

A full rewrite promises a clean slate, but the legacy system encodes years of business rules — many undocumented. Rebuilding them all before going live means months without visible progress, while the old system keeps changing underneath you. Rewrites stall not because teams are weak, but because the target keeps moving.

Wrap, then replace

A steadier approach is to place a modern layer around the old system. New APIs expose its data; new interfaces sit on top; and individual capabilities are rebuilt one at a time behind those APIs. Users see improvements early, and each replaced piece can be tested against the old behaviour before it is switched over.

Engineers often call this the strangler pattern, after vines that gradually replace the tree they grow around. The image is apt: at no point does the business stand without support.

The old system is not the enemy. It is the specification nobody wrote down.

Pick seams carefully

The art lies in choosing where to cut. Good seams are areas with clear inputs and outputs, high change frequency and visible pain — reporting, customer-facing portals, integrations with partners. Core transaction logic with intricate rules is often best left until the team understands it deeply.

Make the data move first

Almost every modernisation succeeds or fails on data. Establishing reliable synchronisation between old and new stores early — with reconciliation checks — turns each subsequent migration step into a routine release rather than a leap of faith.