Every established organization has at least one system that everyone depends on and nobody wants to touch. It is old, it is customized, the people who built it have left, and it works. Replacing it is the project that keeps getting deferred, because the risk of a failed cutover is larger than the cost of living with it for another year.
The deferral is rational. Big-bang replacements of core systems fail often enough that caution is warranted. The mistake is treating replacement as the only option.
Replace in stages, not in one night
The alternative is to grow new capability alongside the old system and move work across one process at a time. The old system stays in place as the system of record while new services take over the functions around it: intake, routing, reporting, the interfaces to other platforms. Each move is small enough to test properly and reverse if needed. By the time the core is retired, most of the business has been running on the new services for months.
This approach costs more in connection work and less in risk. It also produces something a cutover never does: a documented map of what the old system actually did, written while the people who use it are still there to confirm it.
What it requires
Three disciplines make staged modernization work. The first is a clear sequence, chosen by business value and dependency, with a decision point before each stage. The second is reconciliation: every stage proves that nothing was lost or duplicated before the next begins. The third is ownership: the client's team learns each new service as it goes live, so there is no handover cliff at the end.
The business keeps running throughout. That is the point.