In my time involved with corporate information systems-related work I have seen many systems re-written. In many of these cases, they were re-written not because of business need, but because of what has been called "technical obsolescence".
What exactly is "technical obsolescence", and who declares software to be in such a state?
The answer to the second question is, of course, the vendor that supports the particular technology. The answer to the first question is a bit more difficult to answer; does the technology still work? Generally, yes. Does the system utilizing the technology still support its business function? Generally, yes. Does the technology still function correctly on servers or desktop PCs? Sure. So what, exactly, is obsolete about the software?
To answer this question, let's talk about the vendors. Software vendors need to make money. They do this by, of course, selling software. If their software is no longer selling, they create new software. One way they persuade their customers, like us, to buy this new software is by eliminating support for the previous software.
This dynamic often creates a cycle at companies to re-write, then re-write again, then re-write again, the same program in new technologies, regardless of whether there is a business case for such a project.
One way for companies to break out of this wasteful cycle is to make use of more Free software in their business.
Free software (Free as in libre) is not governed by a controlling entity's need to make a profit. Changes are not made because of the vendor profitability cycle, and so things tend not to break or alter in arbitrary, unpredictable ways.
I have PHP code that I wrote eight years ago. I have not had to touch it once since its initial development. It has always "just worked" the way I wrote it originally, and I fully expect it will continue to work indefinitely in the same manner. By contrast, I fully expect every line of ASP.Net code I write to have a "shelf life" of whenever Microsoft decides to replace ASP.Net with something else, just like how they replaced ASP with ASP.Net.
While vendor relationships are fantastic, and companies rightfully place a lot of importance on them, the vendor's profitability cycle should not be the driver for when companies should re-write their systems. Put another way, if companies were to make use of more Free software, they would regain control over their code-- their direction would be driven by their business needs, not the vendor's business needs.
As a practical example, I was once part of a group that supported database operation applications that were written in Microsoft's DTS technology. Later, a fairly significant effort was made to re-write all of these applications in Microsoft's SSIS technology, only because Microsoft pulled the plug on DTS support. This altering of technologies by Microsoft led to a reasonably-sized project with absolutely zero business value.
Imagine if the group had just written those programs in Perl in the first place. Perl has been around since 1987, and has had support in the form of a thriving community ever since then. I would be willing to bet it will still be around in another 12 years, still with the same support it has always had. And the best part is that Perl code written in 1987 still works today, and Perl code written today will still work in 2021.
Why companies aren't using more Free software
Two common arguments I hear against Free software in corporations is that the companies don't get a support contract with it, and their programmers would need to learn new programming languages.
In the first case, you often do get support contracts with Free software. Red Hat Linux and MySQL offer support contracts just like HP and Oracle do.
Additionally, in all of my time in corporate environments, I have seldom seen a vendor approached for technology support-- how often do companies contact Microsoft for .Net development guidance?
I see the community looked to for help about twice every hour-- every time developers have a problem, the first place we turn to is Google and help forums.
From my practical experience, if support is so important, companies should be biased towards technologies with a strong community, not a strong "support contract".
In the area of community, you simply can not compare Free software to proprietary technologies, and anyone who has used both will tell you the same thing.
PHP, as one example, has such a thriving community that nearly every single page of the user manual has dozens of user-contributed code snippets, examples, and caveat demonstrations. Microsoft attempted to imitate the same idea with MSDN, and it has completely failed due to a dearth of user-contributed comments, because their technologies do not have the same level of community following that PHP does.
As far as the second argument about programmers needing to learn new languages, this is not a valid argument because companies are constantly asking their programmers to learn new languages.
I originally knew nothing about PL/SQL, so an employer asked me to learn it. I knew no .Net, so an employer asked me to learn it. I knew no ABAP, so an employer asked me to learn it. The list goes on. I have worked with dozens of new hires and interns, and the story is the same. Whether companies ask their people to learn SSIS or Perl is up to them.
What companies should do about it
I am not proposing that companies start writing all of their web applications in Ruby. What might be a good idea however is for companies to pick a spot in their IT organization today to selectively try Free software. There is no substitution for practical application.
In the long term, and in a day and age where cost savings are becoming more and more important, the choice of Free software could free companies up to work on business value-added activities as opposed to needlessly re-writing old systems.