The following is a shortened version of the conversation from Application Decommissioning 101 with Julie Fouque, VP of Marketing, and Paul Barry, VP of Sales.
Julie:
What are some reasons organizations decommission their legacy systems?
Paul:
There are several reasons that typically go hand-in-hand with both business objectives as well as IT initiatives:
- Some companies might want to just replace older applications or go through an application modernization process.
- Others are going through a data center consolidation or data center migration.
- Some companies have undergone mergers and acquisitions or IT transformations that require them to archive legacy data and decommission legacy systems.
- Other companies have corporate compliance policies that require them to place records retention policies on top of this archive data.
- And finally, some companies might be going through a shutdown or a sale and need to permanently retain data from legacy systems.
Julie:
What types of applications do organizations decommission?
Paul:
There are two general categories: common enterprise applications and applications that are used in specific industries.
From a common application perspective, everyone has a human resources system, a payroll system, and a finance system. They might want to archive things like accounts payable, accounts receivable and general ledger systems. Many companies have come to us and asked us to archive their older Lotus Notes applications that were built in the eighties and the nineties and have recently been replaced.
Some organizations, like many state unemployment agencies in the United States, are still running 50-year-old mainframe-based COBOL applications that are now slowly being replaced. And other organizations build their own applications over time, have been supporting those, and now want to go to more of an off-the-shelf or out-of-the-box application that’s easier to support. These are all reasons why organizations decommission these applications.
Julie:
What about vertical industries? Are there certain applications that pertain to specific industries that typically get decommissioned?
Paul:
In the banking industry, we’ve decommissioned both loan processing and loan history applications along with mortgage applications, trading applications, and others.
In healthcare, you notice that there has been quite a bit of consolidation in hospitals and healthcare systems. We have taken historical patient records from electronic health record systems and put these into archives, along with some of the accounts receivable data from legacy revenue cycle management systems. And finally, these hospitals are often sunsetting nurse scheduling applications or time and attendance applications.
In manufacturing, we’ve seen organizations decommission MRP applications. Some are sunsetting older versions of SAP or NetSuite, while others are decommissioning more modular-based applications like their building materials, timecards, and inventory systems.
Julie:
How much data from a legacy system typically needs to be archived?
Paul:
When we decommission a single system, the data volume might be as low as 20 or 50 gigabytes of data, even up to a terabyte of data, but some of those larger single applications might have a hundred terabytes of data in them.
Some of our more complex projects have had multiple legacy systems, and we’ve archived hundreds of terabytes of data. It really depends on the application and the number of applications.
Julie:
Tell us a little bit about how long a decommissioning project might take.
Paul:
How long it takes to decommission these applications really depends on a couple of factors. First, it’s how much data is in these applications and how much data needs to be archived. Having an export utility and program that will allow us to easily access that data and export it so that we can move the data into a temporary holding pen or directly into the archive also speeds up a project.
Once that data is in the archive, you’re going to want to talk to your end users and find out what their reporting requirements are, how detailed it needs to be, and what level of data you need to get to once you run these reports.
Finally, are there subject matter experts or business users that actually work on the team, answer questions and help you move this project along as you’re going through the project. This also facilitates decommissioning projects.
Julie:
Who within an organization typically heads up or is responsible for decommissioning legacy systems?
Paul:
The management of these projects is typically sponsored by the CIO or the chief data officer, and he or she then would deploy certain members of their IT organization to assist. Our team would be part of the overall project team.
You’ll also want to see business users or application owners involved so that they can tell you how the system was put together, how it was used, and how the data should be used in the archive. And the governance and compliance folks are generally part of the project so that the corporate-wide retention policies can be accurately enforced in the archive.
Lastly, the end users who will be using the system are actively involved in the design of the archive so that you can get user adoption.
Julie:
How can an organization get started decommissioning legacy systems?
Paul:
In a follow-up video, we’re going to talk about application rationalization and portfolio analysis. What that means is that you want to conduct an application assessment to identify potential candidate applications for decommissioning, and then put a well thought out plan together to move forward on that project. Stay tuned. That’s going to be a subject for our next chat.
