When you buy groceries, you know that they have a best before date and your wouldn't dream of using it long time after that day have passed. With IT-systems, it's the same as with milk. It's perfectly good when you buy it and store it under right conditions, but when its getting to old, you don't use it event if the packet is half full.

If you have a COTS solution, then it's easy. Just go to the vendor site and search for end-of-life and plan for this in advance. If you have a heavily customized system will it probably take between one to two years to make and upgrade. If the upgrade path is closed, then you better find yourself another solution.

With bespoke systems is it a bit harder to find out when best before date is due. One parameter is lack of support for the underlying platform (old mainframes or mini-computers) or development languages (Visual Basic as example).

The other parameter is system documentation. Have the people how wrote the code been retired or reach their end-of-life? Do we have good documentation of the requirements and business rules in the application?

Why is is important to keep track of the best before date then?

For groceries, it's very simple. You can get very ill if you eat food that is to old.

With soft ware systems is it more subtle. Instead of bacterias in the salmon, you will be at a large risk for virus, as Windows XP users should be very well aware of.

For the management, the most obvious reason is that nobody is willing to take any responsibility for the solution and it's just best effort. Neither the vendor, not your outsourcing partner will guarantee anything and if there is a problem, your are very much on your own. The additional risk with this approach is that the prioritization between efforts could be lower if there are several problems at the same time.

Not a very good solution of it's a business critical systems that have run out of support.

Disruptive architecture