This blog gives you a foundation for understanding why Application Decommissioning should be a key part of your IT strategy. We’ll explain what it means, illustrate the business case, and show you how to get started. Future blogs will expand on this with a series of real examples and best practices to get the most out of Application Decommissioning projects.
The Application Decommissioning Opportunity
In the Navy, ships are decommissioned when they are getting old, outdated and too costly to operate compared to more modern and effective alternatives. For example, over time all of the World War II era battleships have now been decommissioned and retired from service, replaced with modern cruiser and destroyer ships.
Interestingly, the same idea can be applied to old and outdated legacy applications in an IT department. Costly to operate and no longer used for production processing, such applications chew up budget that could be better used for something else. If we could decommission them like aging battleships, we could cut out a huge chunk of the IT maintenance budget.
But there is a reason that legacy systems stay in place. Although no longer in regular use, they contain historical data that often must be retained for both business reasons and to meet legal, compliance and regulatory requirements. Further, this data may be stored in arcane formats that only the original application can read. When the legacy system was displaced by a newer application – or inherited through merger or acquisition—it was easier to leave the old data where it was rather than attempt to convert it. And without a new and innovative approach, it continues to be easier to leave it that way.
The problem with that is the huge amount of much money it takes to keep the old applications running. In one of our examples, the cost for just one set of applications was over $285,000 a month – about $3.5 million per year! And studies show that 50% or more of typical IT application portfolios – and 70% of typical IT maintenance budgets – are made up of legacy applications. To state the obvious, that’s a lot of money on the table.
So how do we solve these issues and take advantage of the opportunity? How do we have our cake (all the cost savings), and eat it too (extract the data and keep it compliant)? That’s where the new era of Application Decommissioning comes into play.
What is Application Decommissioning?
Application Decommissioning is a strategic approach for systematically retiring outdated and costly legacy applications—without compromising business needs or compliance requirements. It does this in two important ways.
First, it uses a rigorous process to analyze the application portfolio and identify the best candidates for decommissioning. This is based on a combination of their value to the business, the savings that can be achieved, and the cost to retire them. In general, the best candidates have valuable data that needs to be retained for a long time—thus offering longer-term cost savings—while not being overly difficult to deal with technically.
Second, it employs innovative technology that can extract data from difficult legacy environments and store it in an accessible but fully compliant central repository. This includes maintaining a full chain-of-custody audit trail of the data as it’s extracted and transformed, and maintaining all security, privacy, retention and other compliance rules in the central repository.
Our Application Decommissioning solution is built on InfoArchive, which uses the concept of active archiving to keep data both accessible and fully compliant. Unlike older data archiving and hierarchical storage management systems, InfoArchive allows data to be actively queried, reported, and integrated with other data for business analytics. At the same time, it includes a rich set of security, privacy and data retention rules that can be customized to meet or exceed the level of legal and regulatory compliance exhibited by the original application.
Application Decommissioning uses XML—a vendor neutral and self-describing format—as the basis for storing data in the central repository. This makes it possible to combine data from different original sources into integrated queries and reports, and also ensures that the data will always be accessible and convertible into future formats. Sophisticated Extract-Transform-Load (ETL) tools are used to extract legacy data into XML, including transformations that can deal with proprietary and pre-relational data formats. And flexible web tools can be used to recreate original query and report formats from the legacy application, making it easy for users to adopt.
Once customizations are built, data is extracted and the new system validated, the data is safe and the legacy system can be turned off.
Building the Business Case
The business case for Application Decommissioning involves comparing the cost of maintaining the legacy application to the cost of decommissioning it. This allows us to calculate an ROI for the project over a given period of time, and also to see how fast the project costs can get paid back. As you’ll see, for Application Decommissioning these numbers are typically quite compelling.
To calculate the ongoing annual maintenance costs, at least three components need to be considered. First, what is the cost of continuing to license and pay for software maintenance contracts for the legacy application environment? This should include not just the application itself, but also the operating system, database and other unique software required to run the legacy application. Second, what are the associated personnel costs? Often, these include expensive resources with very specialized knowledge of outdated applications and operating environments. And third, what are the incremental energy and other environmental costs for operating the legacy application hardware?
To calculate the cost of decommissioning, we take the cost of the project itself and add incremental software licensing and maintenance costs for the data archive.
Then, we pick an appropriate time period over which we can calculate a Return on Investment (ROI). Ideally, this time period reflects the overall lifecycle of the legacy data—that is, how long the legacy application would need to keep running if it wasn’t decommissioned.
Here is an example from a real project that we’ll examine in a future blog post. In this case it was determined that around $4 million per year could be saved in legacy maintenance costs, the cost of the decommissioning project was about $2 million, and a reasonable time period was 7 years. Then over seven years the total cost savings are $28 million, less the $2 million in decommissioning costs, or a net savings of $26 million. Based on the initial investment of $2 million, the resulting seven-year ROI is $26 million divided by $2 million—or 1300%. Dividing 1300% by the 7 years, you could also say that the ROI for decommissioning was about 185% per year.
Meanwhile, the project payback period was only 6 months. That is, if you’re saving $4 million a year and the project cost $2 million, it only takes half a year before you break even.
Getting Started
So how can you get started?
Actually, it’s very simple. We offer a free half-day onsite assessment to analyze your application portfolio and understand where there are opportunities for Application Decommissioning. This includes an estimate of the ROI and payback periods that could potentially be achieved. From there, we would work with you to plan the full detailed analysis described above.
In the next blog posts, we’ll go over some real examples of how others have gone through this process and the results they were able to achieve. Hopefully this will make things even more clear—and exciting!
