Great article, this is very similar the process we use at my company.
One thing to add to the article: Measurable data helps with getting buy-in for legacy revamps, but you don't need to spend hours collecting data. If a rough estimate would convince your boss/customer, then use that instead.
Another trick to persuade people: Give exactly one good reason to do the improvements. Listing too many reasons confuses bosses/customers, which can make them feel like they're not in control. That could result in pushback on the project.
This kind of work is oddly therapeutic to me. As long as I'm actually able to change things significantly and I'm not under too much time pressure.
What really sucks is when I get a task like this and someone wants more crazy complexity added. e.g. I'm just trying to fix the code up and make the existing API fast & safe, but management wants us to also emulate the entire API of a competing product, including all its awful legacy.