To pick a small part of your comment: I think that retaining developers for a legacy codebase is doable as long as you have strong technical leadership. If I c

To pick a small part of your comment: I think that retaining developers for a legacy codebase is doable as long as you have strong technical leadership. If I come on board a new team and there's a ton of legacy code, the main question I'll have is "what's your plan here?". If the answer is "no plan, ignore it until it's a problem, then make the smallest possible fix," then of course you'll get new devs immediately jumping ship. But there are lots of other potential plans. "We're incrementally replacing each of these components, targeting one of them per quarter." "We've put this really solid interface between the legacy components and the new stuff." "We've been investigating, writing documentation, and writing tests that cover our legacy code so that we can maintain it alongside newer stuff." As long as there's some kind of plan in place and the team is executing on that plan, most developers I've worked with will stick around. The issue comes when either there's no plan or there's nobody willing to put resources towards the plan.