Development, maintenance and operations are three fundamentally different and often opposing forces that no management is ever going to tackle right.
As a result you’ll have developers who build programs and then move on to build other things. You’ll have operations that’ll have enough know how to operate and error-handle but not enough to re-develop when the real world changes. By then, the developers have either moved on, are too busy or have forgotten enough of the project that no one is actually available to change the system to match the new reality. If by some happenstance, you actually do have someone who can redesign and reimplement the system, they will be given too little time to do a proper job, because developer resources are expensive. When the real world has changed enough times, you’ll have technical depth.
The only projects that can avoid it, are those big enough, to have their development team never leave and management willing enough to let the developers spend 1/5 of their time on maintaining the system.
That’s not to say that you should do nothing. Often it’s proven itself valuable, for us at least, to design systems with the full intention of throwing them away 5-10 years down the line. By not applying any sort of best-practices that are meant to make the systems easier to readjust during their life times, building them takes maybe 40% of the time, and if they are simple enough, you’ll never have an issue with them. Then 5-10 years later. You build their replacement. Which by theoretical means, would be a terrible business case after 15-30 years, but ask yourself how many smaller systems your enterprise organisation has, that are 15 years old. Out of the 300+ (and I say + because we don’t have the full picture) systems we operate, less than ten of them are that old, and every one of those systems is large enough to have full time developers working on them, often with a 9/10 focus on maintaining them, and only 1/10 on building stuff like more modern APIs for them.