5 minute read
“Decommission the legacy system” is one issue that never seems to get priority on the agenda. Month after month, this major decision sits in the old business category, dwarfed by the other initiatives. With an excitement factor of zero, and a tenuous link to business goals, the prospect of investing precious IT resources into a backward facing project is difficult to justify, and easy to put off.
But while the operational switch may have been turned off, and the legacy system is relegated as storage, the resources required to maintain it, even in its reduced role, don’t decline in proportion to the system’s usefulness, or usage. And soon, these maintenance costs will also be difficult to justify.
However, a decommissioning project has plenty of inherent value, in cost and resource savings, as well as in the potential opportunities in the data. Quantifying that value, and initiating the decommissioning process starts with basic logic: Is the total cost of decommissioning lower than the total cost of not decommissioning? How can we quantify those costs and return real value from a decommissioning project?
Knocking it Down Step by Step
Step 1 – Evaluate costs. For a true cost analysis, compare the price tag for a decommissioning proposal to the real costs of maintaining the old systems. These not only include line items such as licensing costs and vendor support costs, but also internal labor costs, which are often underestimated.
For example, if the responsibility for the legacy system is distributed across a team rather than just one person, and/or issues tracking is only loosely monitored because a quick fix will do the trick, then it is likely that these internal labor costs are not formally accounted for anywhere.
What could your team be doing with their time if it was not being spent maintaining old systems? This is not just a simple tally of hours spent, but also a strategic gut check. Your next business breakthrough could be right under your nose, but if your IT resources are otherwise engaged in babysitting old systems, your opportunities are limited to business as usual.
Step 2 – Calculate risks. Risks come in many forms, and are generally defined by their potential for producing a negative outcome. And the risks of not decommissioning your legacy system could potentially outweigh any other deciding factors.
There is a serious threat to the survival of the data contained in the legacy system if its current platform becomes non-supported or obsolete. More simply stated, data in the old system may not be able to be used with data in the new system because it’s stuck, aging away, in the old system.
You then face a very real possibility of losing the capacity to use that data in any future analysis. That could spell disaster, for instance, in the healthcare world where conversion from ICD-9 to ICD-10 (which is all about coding and data migration) has been mandated.
The longer the legacy system sits there, housing critical data, the more vulnerable it becomes. If the data becomes inaccessible because it can’t be interpreted, or the machine fails and the data is lost, and you are required to recall the data for legal or compliance requests, your negative outcome is realized and your disaster has begun.
Step 3 – Identify opportunity in the data. Though it sounds repetitive to the point of being, well, repetitive, the potential value of opportunity in the data can never be overstated. Once you establish real costs and calculate risks (Steps 1 and 2 above) now the fun begins.
For example, you could take a tried and true approach to data warehousing and extraction from those old systems. In this scenario, you’d first determine all the data you need from those systems, and then expose it to a business intelligence toolset so your business analysts and/or IT guys can go crazy.
Alternatively, if you’re unsure about which data to extract, but want to allow for the potential of future analysis, (a big data approach) then you could determine the minimum effort to extract the data and its metadata, in an unstructured approach, that creates a placeholder to resolve, or analyze, or bring into your Master Data Management (MDM) scheme sometime in the future.
Step 4 –Align your project with business goals. Peel it off and break it down into realistic chunks that can be chartered, and build incremental value into each phase of your project that aligns with broader organizational goals.
So rather than approach compliance issues as independent projects (a.k.a., cost centers), a CIO could instead fold the mandated projects into a larger, strategic IT upgrade, broken up into smaller projects whose value builds with each phase. This strategy helps meet broader goals, e.g., efficiencies and improved patient care, and provides a measurable return on investment.
Step 5 – Get funded. Be aware of major corporate deadlines and financial reporting cycles. Chunk your project and its benchmarks so that its progress is congruent with (and doesn’t cross over) major corporate deadlines or business cycles. A series of smaller 90-day projects is much more palatable to a CFO than a 450-day behemoth.
Create your project budget carefully, attributing the expenses into appropriate buckets, such as operating, special projects, and capital expenditures. This makes each line item that much more tolerable, and the overall project becomes less imposing.
Decommissioning a legacy system may not carry the wow factor that higher-visibility IT ventures enjoy. But by bumping this project up on the agenda to the “new business” category, and approaching it as strategic enterprise venture, you will likely uncover added business value in the form of cost and operational efficiencies, as well as growth opportunities made possible by newly discovered data value.
Mind Over Machines delivers elegant IT solutions that help you achieve your business goals. Connect with me on LinkedIn or send us a message and we can discuss your organization’s business challenges.
