Many legacy system decommissioning projects with our customers involve applications that are managed by an external vendor. Archiving data from legacy systems that are not managed in-house can pose significant challenges. What are the first key steps to decommissioning a legacy application that is not managed in-house? Here are some tips.

Extracting Data from Your Legacy System

First, look at your contract with your vendor. It most likely has renewal dates for contract extension, involving significant fees. Depending upon the size and complexity of your application, give yourself plenty of time for data extraction. Extracting your data may not be a priority for the vendor. Decommissioning the application means you will no longer be paying for their services to manage the application, so they may not be incented to cooperate with your data extraction initiative.

You’ll want to understand the contractual implications of asking the vendor to extract data from the legacy application for you. Typically, there are fees involved.

Finally, extracting data from legacy systems can be laborious and time consuming because it will take time for the vendor to extract data in the format you need.

For these reasons, get your best contract negotiator involved and, in our experience, allow a minimum of several months.

Getting Your Data

You’ll need to know how the vendor is going to transfer the data to you once the data is extracted from the application. As your data most likely has security constraints associated with it, work this point up front so you will be prepared to identify a data transfer method.

In addition to the transfer of data, there’s also consideration of the data format. There are several options, including database dumps, CSV extracts, and XML. Confirming the accuracy and completeness of the data transfer early is critical to the success of the archive project.

Does anyone still know about this application? Check to see if you still have a subject matter expert (SME) in-house who has both technical and user knowledge of the system and find out if you have documentation on the application.

Determine if SQL tracing or other database access logging can be performed on the application. If it can, you’ll want the ability to perform this as part of your contract. If the vendor managing the application is the application vendor, you’ll also want to receive documentation as part of the contract. Get as much as you can from the application vendor. You’ll want user guides, data dictionaries, any secondary logic. This is important especially if you want to create a graphical user interface, or GUI, for accessing the legacy application data, because data mapping is extremely challenging without it.

If you don’t have anyone in-house that still has knowledge of the application, make sure you have hours in the contract to hire a SME from the vendor to work with your data archiving team.

Setting Up Your Archive Infrastructure

Are your database administrators (DBAs) ready to receive the data from the vendor? The last thing to do is to get your in-house DBAs ready for the task of receiving the legacy data and transferring it into your secure infrastructure. A best practice is to allocate plenty of space and time for them to do this. Then you’ll be ready to archive your legacy data.

Preparing is Worth the Effort

Even though the preparation for data archiving and decommissioning of an application that’s not in-house seems daunting, the return is worth the effort. You’ll no longer be paying high rent for your application and data, and your data will be accessible and secure at a fraction of the cost.