We all know the risks of hanging on to out of date food. But not everybody thinks of the negative consequences that come with keeping IT applications beyond their ‘sell-by’ date.
Many organisations feel forced to keep aging applications running even though they are no longer being actively used by the business. The only reason they are kept alive is to allow access to historical data, which may be needed for a whole raft of reasons – perhaps to respond to customer queries, for regulatory compliance, or ‘just in case’.
However, maintaining obsolete systems can put a real strain on resources, as they continue to incur maintenance charges, support costs and – particularly in the case of large mainframe and UNIX systems – significant hardware costs. For example, keeping just a small mainframe running can cost several hundred thousand pounds a year in hardware and software maintenance.
Older applications may call for specialist legacy skills that are often in short supply – while newer staff, unfamiliar with historical applications, may be unable to fix problems or access information needed by the business.
Vendors may charge extra for support – with the worrying possibility that support could be withdrawn altogether. Added to this, older applications might be incompatible with new operating systems and database versions..
You might think the answer to the problem would be to extract the data and store it elsewhere, leaving you free to switch off the original application. But if you separate the raw data from the original application, it will be out of context, making it much harder not only to locate the data you need, but also to interpret it. How confident can you be about interpreting raw billing data, for example, without meaningful labels attached to the data – as they would have been on the original screen.
Migrating historical data to, say, a new billing application is often impractical due to the time it would take – and the sheer volumes could significantly impair system performance. Extra disk space and back up storage would also be needed, at additional cost.
One alternative is to remove the key data from legacy applications and keep it in an accessible, searchable online archive. The difference between this approach and just ‘dumping’ the data in a database is that the data is kept in its original context.
When displayed online it looks just like a screen from the original application – complete with all the headings, labels and notes that allow users to makes sense of the data. Users can access all the information they need to support customer service and other operational requirements, without the help of an expert. As the information is read-only and tamper proof it also serves as a legally compliant record.
Using this application decommissioning technique, security is tightly controlled so that users only have access to information that they are authorised to view. So customer service teams may have access to customer history and billing data, but not sensitive payroll information, for example.
Access could be via a browser or Windows or the online archive could be integrated with core business applications – such as SAP ERP, or a CRM interface, so that legacy data ‘pops up’ in the user’s familiar interface when required.
When deciding how to handle data from obsolete systems it is worth asking three questions: is the data business complete i.e. there will be no further changes to it? Could swift access be required in the future – for operational reasons, or compliance? Are there significant risks, costs or access problems associated with leaving it where it is? If the answer to one or more of these questions is ‘yes’, an online archive may be the answer.