I completely agree with your last paragraph, but you (or your management) lost me with the second: "This is one of the biggest dev complaints that we have even

I completely agree with your last paragraph, but you (or your management) lost me with the second: "This is one of the biggest dev complaints that we have even today, and one of the factors that led to management deciding to "junk it all" and start over from scratch." Starting over from scratch doesn't seem like it's going to help find the right abstraction[0]. All the nasty edge cases and such that make the existing code ugly are what you need to consider in order to know the "right abstraction", and they're usually what get ignored in the early design stages of a new rewrite. You're at the point where you've learned pretty well what aspects are both shared and stable between the systems. Seems like a perfect opportunity to start to modularize the existing codebases instead - start to split out the shared functionality so it only has to change in one central place, while allowing the two different top-level projects to have their specific quirks on top of that. [0]for most business processes, I think "finding the right abstraction" is actually a dangerous red-herring. Sometimes you have complicated processes. Sometimes clean readable well-organized code is what you need, not an abstraction over it.