Bespoke built legacy systems are a drain on the resources of IT departments across the globe.  In many cases these systems run key business processes and maintenance of these systems is problematic.  Often few people in the IT department have knowledge about how they work, or the language they are coded in.  Documentation can be poor making it hard for new people to learn the systems.  Making changes can be risky as it could seriously impact the business if things go wrong. 

How can organisations tackle this problem?  Well the first step is to assess your legacy systems and understand where they fit into the technology architecture and, more importantly, the business process architecture.

Not every company has documented a systems map identifying all of the applications used and how they interact.  Even at a high level this is an important exercise as it provides understanding of how complex your IT environment is.  In particular what are the dependencies between systems? 

This is more than just documenting that the systems, what they do, and any data interfaces.  Each system should be ranked in terms of:

• How critical is it to the business performance?  Think in terms of financial loss or reputational risk to order them.
• How old is the technology it is written in? Even technology a few years old can be legacy, especially if the supplier has ceased trading or is a niche player.
• Who has knowledge about the system?  Are these individuals able, or willing, to continue maintaining the system. 

Naturally the most critical systems on the oldest technology with the least knowledge available should float to the top of your priority list. 

Hopefully your list of systems has reduced so you can focus on the critical ones right now.  Leave the others for a while as I am sure they will become critical in the coming years.