(1) An old COBOL application running on IBM Mainframes has many problems: (a) It does not have the modern user interface that makes people more productive. (b) We cannot justify the cost of operating an IBM Mainframe environment when the same work can be accomplished on a powerful Windows Server. (c) It is very difficult and costly to find experienced COBOL programmers to maintain the software. (d) Marketing is demanding Extranet and Web Service facilities for clients, because our competition offers those facilities.

(2) An old application written in ‘C’, which runs some core production floor processes, used to be such a wonderful asset for the company. But now it is taking forever to make simple changes. Last week marketing was livid because they lost an order due to our inability to switch from one product line to another quickly enough. This week a supposedly simple change introduced a bug that halted production for over 2 hours. IT chief claims that over time the source code has become very difficult to maintain because there is a lot of spaghetti code, dead code and duplicate code. To top it all, the documentation is almost useless because it was not kept updated as the software was changed.

(3) We want to move our Sales Order System to the Cloud but the dynamic nature of IP address assignment within a cloud environment poses new challenges for how we handle database clustering and failover rules. There are other known issues as well and those, coupled with the perceived risk of the unknown, is preventing us from moving to the cloud quickly.

(4) A Visual Basic 6 application that was developed barely five years away has become a major headache because after Microsoft dropped support for VB6, the third-party components vendors started releasing only .NET versions of their components and stopped supporting the VB6 versions. When bugs are discovered in those components we have to design workarounds. We can’t find any good developer who wants to work in VB6. Now our customers are demanding a User Interface that a critical third-party control does not support. So we might have to replace the entire component with custom VB6 code that will cost us a ton of money and bunch of time that we can ill afford.

(5) We have an incentive computation system for our 15,000 strong salesforce that started on the IBM Mainframe using the IMS database. Then some additional functionality needed the IDMS database. Now we have combined this app with our payroll app that uses DB2. Now the management does not want to pay all these different license fees and want us to consolidate all data into the DB2 database platform.

(6) Many of our core business processes run on the IBM Mainframe, but most of our new applications over the past seven years have been developed on Java. Now the management has decided to eliminate the Mainframe and move all COBOL apps to the J2EE platform.

(7) Our company recently acquired a logistics firm to strengthen our delivery operations. The problem is, we have standardized our information systems on the J2EE platform, while the newly acquired firm has a mixture of .NET, COBOL and even Visual Foxpro apps. All of those now need to be moved to J2EE.

As some of the examples above demonstrate, it is inaccurate to think that only ancient and decrepit software running on antiquated hardware/software platforms (called "legacy software" in common parlance) need to be modernized. We treat all software that is in production -- regardless of their language or their age -- as “legacy systems”, because most software currently in production can benefit from modernization in smaller or larger measure.

One definition of “legacy software” is “anything that’s currently in production” - “anything that works”.