Creating a robust applications portfolio is a key first step to any legacy data management project, and it’s a good tool to help keep track of the numerous applications across any organization. The data gathered in the applications portfolio especially helps organizations prioritize how applications should be archived based on costs, risks and other factors. A portfolio also often helps with identifying old, unused applications sitting around without any data that needs to be retained due to the type of data stored or duplication across other systems.
An applications portfolio is best laid out in a table format like Excel for easy filtering and further analysis. Components to include typically fall into the following buckets: Application Background, Cost, Usage, Risks and Vendor Contract Profile.
Application Background. This will include general information about the application such as vendor name, application name (sometimes the same as the vendor name), software version, data types, retention, internal and vendor contact information, and hosting. The type of data stored in the application and subsequent retention periods are important in determining whether or not the application needs to be archived and, if so, how much of that data will need to be retained. Hosting information is also critical to an archive project, as a vendor-hosted solution will almost always have an extra incurred cost for extraction of the data.
Cost. It is very important to determine all costs associated with the application, including vendor, internal hosting, hardware or FTE fees. All recurring or monthly costs should be calculated into an estimated total monthly cost for a true grasp of the monthly budget load.
Usage. Application usage information – including the database size, number of users/records/patients, integrations, required reporting and whether or not the application is read only – will affect the cost of archiving the application and will help determine if the application can be archived at that time. The more data in the database, the higher the cost to archive the application. Any application currently in use, e.g. data is currently being added, will either need to be archived once it is in a read-only state or catch-up archives would be required until the application goes read only (common during enterprise EMR implementations).
Risks. The risks will mainly focus on items that could prevent the data from being legally released in a timely manner. End-of-life hardware and software threaten system breaks and long time frames without access to the system. Not being able to properly back up the application puts the organization at risk of system crashes or hardware failures. When vendor support and maintenance lapse, the vendor can no longer assist with application access issues or breaks and may charge excessive support reinstatement fees for their assistance. Data encryption complicates the ability to export and view the data when archiving.
Vendor Contract Profile. Obtaining key contractual information helps determine when the system should be archived and when the support can be terminated. Archive timelines should take into account the contract renewal date to ensure contracts aren’t renewed when unnecessary. Tracking termination notice requirements reminds the organization to notify the vendor in a timely manner after archival and helps eliminate added costs.
A robust applications portfolio can help organizations get a clear picture of all in-use or inactive applications within the organization. Gathering the key components listed above for each application will ensure the organization has the needed information to make informed, objective decisions on which applications to archive and in what order they should be archived. This portfolio is an important first step when starting any legacy data archiving project.