“The old system needs to go” may be true. It is still an incomplete brief.
Imagine a business where a change to customer pricing takes weeks to release. A new system promises flexibility, cleaner architecture, and a better developer experience. Before committing to the replacement, we would want to understand what makes that particular pricing change difficult.
The answer might justify a rewrite. It might also reveal a smaller boundary that can be changed first.
Describe the obstacle in product terms
A legacy assessment should connect technical constraints to the work the business wants to do. “The code is old” says little about the cost of keeping it. “We cannot add a pricing rule without changing three applications and manually reconciling their results” gives the team something concrete to investigate.
Map one representative change through the current system. Include approvals, data ownership, release steps, and the people who perform manual corrections. Some of the delay may come from architecture; some may come from unresolved responsibility. A replacement that preserves the latter may preserve much of the frustration.
Find a boundary you can actually separate
Incremental replacement can be useful when a meaningful capability can move independently. Martin Fowler's original description of the Strangler Fig approach describes gradually replacing an existing system rather than making a single wholesale switch.
For the pricing example, the candidate boundary could be the calculation itself. But that is only credible if the team can identify its inputs, outputs, consumers, and historical behaviour. A box on a diagram is not yet an independent capability.
Test the proposed boundary against real variations. Which callers depend on undocumented behaviour? What happens to older records? How will you compare results while both implementations exist? The transition work belongs in the estimate, even if some of it will later be removed.
Make the alternative explicit
A full replacement can still be the right decision. The current system may be unsupported, impossible to operate responsibly, or too tightly coupled for a useful intermediate step. State that case using evidence rather than frustration.
Compare the options against the same product goal. For each, explain when the first useful improvement becomes available, which risks remain during the transition, and what has to happen before the old system can be retired.
Include a stopping rule. If an incremental approach cannot establish the necessary separation within the agreed investigation, revisit it. If a replacement programme keeps expanding to reproduce low-value behaviour, revisit that too.
The aim is not to preserve old code at any cost or to make new code the reward. It is to give the business a better way to change its product, with a transition it can operate.