I worked, once, at a large, national (US) company that will not be named.
They had an old database from the early 70s that stored _all_ of their data, everything, contacts, billing, etc.
That was accessible through a special proprietary program, that was overseen by one college kid after the rest of his team was let go.
That proprietary program was essentially an old DS prompt, which was connected to via a Java applet for an early version of Internet Explorer < 7 that emulated the old dos-like user interface.
That Java Applet was connected to via a Java web service, running on machines that had the java applet and ie installed.
The Java web service was accessed by tens, possibly a hundred thousand people nationally, through a few different interfaces.
The one I was aware of (probably the largest), connected to the Java Web service, through a C# WCF service.
The C# WCF service was built as a backend for a new javascript / html4 front end for their company.
That new UI, was intended to partially (BUT ONLY PARTIALLY) replace a strange, 100% actionscript web ui made previously.
Learning about their system architecture, was quite literally like stepping back through time. I felt like an archaeologist, uncovering layers of an ancient city.
It was also amazing how many people were employed supporting each system, each of which could have replaced the lower tiers if they had just upgraded at the time.
It was similarly amazing, how the company had laid off everyone at entire layers, when management arbitrarily decided they needed to make cuts, while other layers doing the _exact_same_thing were staffing huge quantities of people, completely unaware that a single bug in the layer beneath them was not being overseen, or supported, and could bring the whole house down at any time.
These two anecdotes (parent and grand-parent) show that there are two ways to manage legacy systems: a mindful, efficient way and a wasteful, risky way. Come to think of it, those same two ways apply to any project, old or new. So it all really boils down to project management and corporate practices.
I agree with all the comments that say that legacy systems, government or corporate are not inherently, necessarily bad, inefficient, insecure, and in need of replacing.
alternatively, the grandparent post's mindset becomes the parent post's when the application needs to be extended, and the grandparent's simply hasn't had that need yet : )
They had an old database from the early 70s that stored _all_ of their data, everything, contacts, billing, etc.
That was accessible through a special proprietary program, that was overseen by one college kid after the rest of his team was let go.
That proprietary program was essentially an old DS prompt, which was connected to via a Java applet for an early version of Internet Explorer < 7 that emulated the old dos-like user interface.
That Java Applet was connected to via a Java web service, running on machines that had the java applet and ie installed.
The Java web service was accessed by tens, possibly a hundred thousand people nationally, through a few different interfaces.
The one I was aware of (probably the largest), connected to the Java Web service, through a C# WCF service.
The C# WCF service was built as a backend for a new javascript / html4 front end for their company.
That new UI, was intended to partially (BUT ONLY PARTIALLY) replace a strange, 100% actionscript web ui made previously.
Learning about their system architecture, was quite literally like stepping back through time. I felt like an archaeologist, uncovering layers of an ancient city.
It was also amazing how many people were employed supporting each system, each of which could have replaced the lower tiers if they had just upgraded at the time.
It was similarly amazing, how the company had laid off everyone at entire layers, when management arbitrarily decided they needed to make cuts, while other layers doing the _exact_same_thing were staffing huge quantities of people, completely unaware that a single bug in the layer beneath them was not being overseen, or supported, and could bring the whole house down at any time.