Having too many legacy systems is often a symptom of a much bigger problem: IT is considered a cost center and a necessary evil to keep the business running.
And if you're a tech company and you have many legacy systems it's still a symptom of much bigger problems.
The project approach to building new systems is risky. Constantly disbanding, reshuffling and reassembling teams for new projects until the next project comes along is one of the guaranteed ways to get a legacy system landscape that slows the business down.
Writing code is easier than reading code. Context and knowledge is lost the moment you move a whole team to work on something else, or you get another team to take over.
At least make sure the system is in a good state before you hand it over, as getting up and running on a shitty code base without adequate documentation is a recipe for disaster.
And the bar for a system being in good shape is extremely high: I've never ever in my life heard a single developer say: "What a great codebase! I'm loving it"
Legacy systems are a symptom. Fix the underlying problems causing them or you will perpetually keep working on legacy systems.
I agree, Maarten. But even with product teams, it is extremely difficult to keep technical debt/ legacy systems under control. Only a small percentage of companies manage to keep “a constant pace indefinitely”. What is your opinion?