Legacy Application Retirement - Sleeping with the Fishes?

Today, companies are looking for solutions that can archive inactive data from little used enterprise applications. Those applications can be decommissioned, saving the company the expense of keeping them running for little payback. But the question not addressed early enough in the project is what to do with all of the application’s legacy data – delete it or save it (and where). By migrating the legacy data to an intelligent archive, organizations can preserve the value of legacy application data, ensure regulatory compliance, and address any legal concerns.

Know, before you start

When starting an application retirement project, you should consider the questions listed below - before  you move forward. If not addressed, you can end up spending a lot more money, raising your risk and liability, and negatively affecting employee productivity.

1. What are the company's reasons for starting an application retirement project?

The usual reason for starting an application retirement project is to lower overall cost. Keeping legacy systems updated and operational can be expensive –including keeping personnel available that can actually run it. Take the annual overhead expense of keeping the legacy applications functional and multiply it by 10, 50, 500, or 5000. You can imagine these expenses would be astronomical. And yes, I have spoken with a company that had a project to retire more than 5000 legacy applications.

However, other reasons for application retirement can include: application has been declared end-of-life by the vendor; corporate acquisition; and data center moves.

2. Does the company anticipate future litigation or have actual litigation where potentially responsive data could be stored and dependent on a legacy application?

This question is extremely important. Your legal department should always be involved in the decision to move forward - and when approved - document the legal department’s approval.

Retiring an application and its data carries risk that many IT people aren’t aware of. If the company is currently in litigation or is anticipating it in the future, then the movement of potentially relevant data could cause data loss or corruption, which in the court’s eyes, could amount to destruction of evidence.

Another risk to be aware of is individual file’s metadata. Metadata is as important for eDiscovery as the file content. If not migrated correctly, metadata can be altered - risking a destruction of evidence charge.

3. Which legacy systems should be kept operational, and which should be decommissioned?

When answering this question, you need to take into consideration several factors:

• Does the application need to be retired because the vendor declared it at end-of life? If yes, then it must be retired and the associated data archived if needed.
• What format is the application data in?
• How many users are actively utilizing the system?

Obviously, these questions are specific to individual companies.

4. For application retirement candidates, what data actually needs to be preserved?

Application data preservation is usually driven by three needs, (1) regulatory compliance, (2) eDiscovery, and (3) business value.

If data is subject to regulatory retention requirements and it’s within the stated retention period, then it must be migrated to an archive for later search and retrieval if requested - at least until its retention period expires.

For discovery, the need is obvious. If application data is relevant to a current or anticipated lawsuit, the data must be migrated for possible search later (that is if the corporate attorneys approve the migration and decommissioning).

The most problematic question is what data from the application still has business value. There is no easy answer to this one. Companies will typically sort the data by date and or keyword to determine whether or not it should be retained.

5. For what period of time should the archived data be retained?

This question is dependent on the answer above. For regulatory retention, the data should be archived for a period of time required by the regulatory authority. For eDiscovery, the document originals of potentially responsive data, should be placed on a legal hold until the case and potential appeals are concluded. Data with assigned business value should be archived until it is determined to be of no more value to the company.

6. Is there any specific (prescriptive) retention requirements that must be followed such as SEC 17 immutability?

eDiscovery retention, and most regulatory retention requirements do not impose specific technology requirements for the retention of data. However, financial services companies are required by some individual country agencies to handle and store data in very specific ways. For example, SEC Rule 17 requires communications to be captured, serialized, and stored on immutable media (WORM). When migrating legacy application data, it is important to fully understand all regulatory requirements before the data is moved.

7. Can the target archive effectively recognize, index, and search the data?

When migrating legacy application data, it is a good idea to ensure the receiving archive can actually work with the data. For example:

• Can the new archive ingest the data in its native format?
• Can the archive index it for later search?
• Can it produce a preview of the data for review?
• Can it export data in its native format with all metadata intact?

8. Which users will need access to data and what levels of permissions need to be supported?

In many cases, archived data can be of a sensitive nature so archive access controls are a must. The new archive should have granular access and capability controls to set which employees can gain access to specific data and what they can do with it.

Don’t ignore it, archive it

Obviously, when retiring enterprise applications, including legacy data stores in the planning and execution of the project will ensure that the company is not inadvertently disposing of regulated and relevant eDiscovery data. Where the legacy data is stored is another important question. Because this data will be held for longer periods of time and rarely accessed, a low cost storage tier is a common sense solution. Because enterprise storage is expensive, costing between 15 and 30 cents per GB per month to just maintain, low cost cloud archival storage makes a great deal of sense.  

Archive360’s Archive2Azure is an intelligent data management and compliance cloud archiving solution based on the Microsoft Azure Cloud. It provides customers a low cost alternative to expensive enterprise storage for low-touch legacy application data. Archive2Azure enables companies to provide automated retention, indexing on demand, encryption, search, review, and production for long term archiving of their compliance, low-touch, and inactive data from within their own Azure tenancy.  This pairing of the Azure Cloud with Archive2Azure's archiving and data management capabilities provides companies with the cloud-based security and information management they have long sought.

To read additional application retirement blogs, click the links below: