Replace the system nobody wants to touch

Almost never, and avoiding it is the central design goal. The strangler pattern puts the new system alongside the old one and moves a single workflow at a time, so the business keeps running throughout and each step is small enough to reverse. Brief downtime is sometimes needed for a final data cutover on one specific workflow, but that is measured in minutes and scheduled, not a weekend of everyone holding their breath. The scenario worth avoiding is the big-bang replacement, which is where migration horror stories come from.

This is extremely common and it is a solvable problem, just a slower one. The system itself is the documentation: the code describes what it does, the database describes what it stores, and the people who use it daily know the behaviours that matter even if they cannot explain the internals. Discovery in this situation involves more reading and more observation, and the estimate reflects that. What genuinely helps is access to the running system with real data — behaviour that is invisible in the code is often obvious in the data.

Yes, and that is frequently the right commercial answer. Not every part of a legacy system is equally risky — often one module handles something compliance-sensitive or blocks a business capability, while the rest is old but perfectly stable. Modernising selectively means spending on the part that actually creates risk. The discovery sprint ranks components by risk and by what each one blocks, so the spend goes where it changes something. Replacing stable, boring code that nobody needs to change is rarely worth it.

It gets treated as the irreplaceable asset it is, and it is addressed first rather than last. That means establishing a reliable export from the old system early, building a validated migration path, and running automated reconciliation so discrepancies are caught by a script rather than by a customer. Historical data that is no longer operationally needed gets archived in a format that will still be readable in five years — not left inside a system that is about to be switched off. Nothing is deleted from the old system until the new one is demonstrably correct.

Get the quote, and read it against an independent view of what the system actually does. The original vendor has genuine knowledge of the system, which is worth something real. They also have an incentive to propose a rewrite on their own stack, and they are the party least likely to tell you that half the system should simply be retired rather than rebuilt. A discovery sprint from someone with no stake in the outcome gives you a second opinion — and sometimes the finding is that the incumbent’s proposal is sound.

Longer than a greenfield build of the same functionality, because the new system has to match behaviour that was never written down and the business has to keep running throughout. A single workflow typically moves in weeks; a full system with many interlocking workflows is a multi-phase programme measured in months. The phased structure exists so this is not one long wait — each phase delivers something usable, and you can pause between phases without leaving the system half-migrated. The discovery sprint produces the phase map, so you see the sequence and the checkpoints before committing to the first phase rather than being asked to approve an open-ended programme.