The system everyone wants replaced is also the system the business runs on. That's the whole difficulty — it has to keep working perfectly throughout the years it takes to retire it.
Big-bang rewrites fail at a rate that ought to have ended the practice. The alternative is slower on paper and far more likely to finish: replace behind a facade, one capability at a time.
What the system does, what still matters, and what's been dead for years. Old systems typically carry a great deal of functionality nobody uses.
Identifying where the system can be cut — the boundaries where a piece can be lifted out and served by something new without the rest noticing.
Capturing what the old system actually does, including the bugs people now depend on, before anything replaces it.
New capability behind a facade that routes each request to old or new, so the switch happens per feature rather than per system.
Moving decades of records with their inconsistencies handled deliberately, rather than discovered during the first month of live running.
Both systems processing the same work and their outputs compared until the numbers reconcile — then, and only then, the old one goes.
One of these can be stopped at any point with value already delivered. The other can only be judged at the end, which is also the only moment it can fail.
The replacement itself is usually enterprise software development, and the sequencing decisions belong in IT strategy.
Tell us what the system is, what it still does, and what's stopping you replacing it. We'll come back with the seams and a first phase worth doing on its own.