Good writing on the problems, I think it is just missing the "what is the right approach then?"
Approach that I've seen working is the divide and conquer: It's similar to the new system next to the old (greenfield) but incrementally (avoiding the monolith substitute). Get a manageable slice of the business and develop a substitute system for that slice, old system continues to live and evolve (as needed) while you evolve the new system incrementally (getting bigger slices from the business/process).
Great comment, I have been looking at doing something like this in my own case. You target a single customer / stakeholder, and suddenly stopping the world is less damaging because you're only stopping / slowing development for a smaller segment of your business. That also means you can time it to align with that segment's needs, trying to find a good stretch of downtime where you can get to work. (This would be impossible for the whole business). If you pick the right customer, you get a good blend of reduced scope (you don't have to solve EVERY problem) without being too narrow (you can't just work on the fun parts - you have to fully solve the problem for that stakeholder, forcing you to think through all of the boring stuff that will need to be figured out).
"Recently I thought of a small tweak that might help things a little. If I rename the post to “Strangler Fig Application”, and use the term “Strangler Fig” as much as possible, then hopefully that would reduce the violent connotation by reinforcing the metaphorical link that is the whole point of the name. Because it's a small change, maybe it will spread enough to be worthwhile, and it's not much effort, so seems worth a try."
- M. Fowler
https://martinfowler.com/bliki/StranglerFigApplication.html
In addition to the strangler pattern, look at the tools from Michael Feathers's "Working Effectively With Legacy Code." along with refactoring. If you can get all pieces under test, you can have the confidence to replace and refactor larger pieces of the system without replacing the entire system.
In systems software I've often seen/done this on a micro scale, where you build the new system inside the old system, think feature flagging but something so fundamental that it's almost the whole thing.
