In addition to this, there are all the horror stories of re-writes being a waste of resources. I've done it myself, and wish I hadn't. Having said that, I thin

In addition to this, there are all the horror stories of re-writes being a waste of resources. I've done it myself, and wish I hadn't. Having said that, I think this is one of the great benefits of micro-service architecture. You can re-write piece by piece as you add functionality or create a measure of improvement. But don't use the "we need to write this as micro-services" as an argument. You say "re-write large parts", so I assume that means not the whole thing, and not a new language. If that is the case, I'd suggest tackling the "re-write" as a piece by piece upgrade rather than a re-write, and look for a business case for each component you plan on re-writing. The engineer wants a beautiful system, the business wants a system that works. The business pays the engineer. So buy "selling" the business the benefits of specific improved functionality, you may get a new beautiful system. Is there a part of the system that is particularly expensive part of the app from a services (DB, API requests, etc) stand-point? Can you quantify for the business the benefit they'd get from re-writing that part of the app, and the cost savings they'd expect to get? If you're close with the design team (which I hope you are, or suggest you become), are there business goals they are designing for which would allow you to sandbox a part of the app to be re-written? Do that 20 times, and you've got a new app, and you didn't do a 're-write', you just kept adding great functionality and cleaning up as you went. So, I'd suggest getting the idea of a 're-write' out of your head, and instead approach it from a "how can we improve this tiny piece of the app while pushing the business forward".