I've actually been through a fairly significant refactoring three times in my career. Code has a tendency to decay, so if your code base is around long enough, a large refactor is pretty much unavoidable. All my examples were on private code bases, which might explain why public examples are hard to find.
The first time was an application which, believe it or not, had a fundamental architecture that made it only work with dot matrix printers. When my company could no longer find a vendor to supply the ribbons, they assigned me to make it work with a laser printer.
The second time was a migration of several hundred automated test scripts from C to Java, partly because we needed better cross platform capability, and partly because it was getting difficult to hire new C developers.
The third time I am still in the middle of, which is modularizing a huge monolithic application to allow unit testing by reducing coupling, and for cross platform purposes.
I compare the effort to climbing a mountain. You have this huge goal ahead of you, but you don't tackle it at the macro level. You take it one handhold at a time, always having a close fallback position, never disconnecting the previous safety until the next one is in place. You start out just making small incremental improvements, and after a while you turn around and there's suddenly this beautiful view.
Let's say you have 60,000 files of highly coupled code, for example. You want to start putting it under unit test, but the dependencies make it impossible. How do you fix it? You decouple one file. You add automated tests. You get back to stable ground before moving on. Repeat 59,999 times.
If that sounds simple, that's because it is simple. It's not easy, but it's simple. It's hard to notice any progress at first. We are two years into what seemed an impossible refactor, and likely have years ahead of us until we're finished, but looking back we suddenly realize how much better the code has gotten already, and we have been able to continue to deliver new functionality to our customers in the mean time.
The other two times worked the same way. You find the smallest safe step you can take, and you take it, always keeping the application in a working state. You only worry about the big picture to make sure you're heading in the right direction. All your actions are small, steady, and incremental.