One of the main factors when deciding whether to keep or replace legacy systems is determining the cost. Here, we dive into five hidden costs CIOs should be aware of today.
CIOs are caught up in a constant need to balance old and new technology, systems, and processes. On the one hand, to embrace the new, they need to help their organization address new opportunities, deal with challenges, or improve efficiency and effectiveness. On the other hand, to commit to the existing technology, they must power existing processes and realize the full value of past investments in hardware, software, and staff, including the cost of maintaining a legacy system.
Somewhere along the line, "the existing system" imperceptibly transitions to "the legacy system." It's not simply a matter of no longer being the newest, fastest, and best: Most offerings cease to be those things within months of release. But some combination of distance from the state of the art, the approach of the official end of life, and the cessation of significant functional upgrades does the trick.
What should a CIO do when faced with a legacy system, be it hardware or software, that is still functionally viable? It's easy to say, "as long as it's cheaper to run the legacy system than to acquire something newer and better and continue to cash in on the original investment." It can be harder to fully account for the costs.
Here are five of the hidden costs of maintaining legacy systems that any CIO should keep in mind:
This one is the easiest because there's a bill each year, whether from the original provider or an aftermarket shop. Just remember, these costs typically decrease for a while as a product approaches the end of life -- i.e., as spare parts become more available when most users sell off old storage arrays or phone systems -- then increase steadily, sometimes sharply, afterward, such as when those parts run out of stock.
For the most part, a new system capable of accomplishing a given task will be smaller, consume less power, and produce less heat than a legacy system doing the same job. The data centers left with dusty rows of empty racks in the wake of massive server virtualization onto newer generations of hardware or the migration of workloads to the cloud demonstrate this principle in action.
Modernization can not only reduce power costs but also enable the downsizing of cooling and power infrastructure.
The older a legacy system is, the less common the knowledge required to operate and maintain it becomes. This can turn into a need to pay unusually high wages for staff with old and rare skill sets or a need to pay to have new staff trained up on the legacy platform, which can mean a knock-on cost to the staff themselves, as they devote their time to picking up skills on the trailing edge of the technology curve. It can also translate into a need to maintain a larger staff.
Read: Insourcing Nightmares
The flipside of the costs associated with maintaining a staff skilled in a legacy system's operations is the cost of not doing so -- in other words, allowing the overall staff skill set to degrade over time and technical debt to accrue. This can result in crises, consulting bills, or both.
A crisis is when a service-affecting problem arises and staff members must learn how to solve it in the moment, which usually prolongs the event. Or, to speed up the resolution of the problem, the business may have to pay consultants -- often at very high costs compared to in-house staff -- to temporarily patch over the missing skills. Or, worst case, the staff try and fail to fill in the gaps in their skill, therefore prolonging the interval before outside talent is brought in.
This can be difficult to quantify in any way but retrospectively. Just as staff members incur individual opportunity costs when they devote time to mastering old systems rather than emerging ones, so too can businesses incur opportunity costs from clinging to legacy systems.
A business that ties up too many of its resources in a legacy system may be unable to invest in emerging technology areas such as AI and IoT. This will cost them not just the new revenue streams or improved efficiencies that could come from projects centered on those new technologies, but also the expertise they would develop and could then apply to other opportunities down the line.
Certainly, it can be irresponsible and shortsighted to upgrade systems before there is a business need or opportunity to justify the cost. However, it can be just as irresponsible and shortsighted to cling too long to a system on the trailing edge of a technology wave. CIOs need to make an effective, well-rounded account of the full cost of maintaining the legacy system to balance against the costs of adopting the new system in making their decisions.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Legacy Software Modernization: How to Fix an Aging System Without a Risky Rewrite (article)
ERP Migration Cost: The Line Items Nobody Budgets For (article)
Hidden Cost of Manual Data Entry (video)
In rising order of change: encapsulate, which wraps the old system in APIs so new software can use it; rehost, which moves it to new infrastructure unchanged; replatform, which makes minimal changes to run on a new platform; refactor, which restructures the code without changing what it does; rearchitect; and replace, either with a rebuild or a purchased product. Most programs mix these, modernizing the parts that change often and leaving stable parts alone.
Total the five hidden costs on this page for the next three to five years: maintenance contracts as they rise toward end of life, infrastructure and energy, staff with scarce skills, the incidents and consulting that technical debt causes, and the projects the company cannot do while the old system holds it back. Set that against the cost of the replacement and the cost of the transition itself. The transition cost is the one most often underestimated.
A rehost can take weeks. A replatform or a focused refactor takes months. Replacing a core system that runs the business, such as an ERP or a billing platform, typically takes one to two years including data migration and the period both systems run in parallel. The duration is driven less by the technology than by how well the current processes and data are understood, which is why the preparation phase often matters more than the build.
Losing undocumented behavior: the old system handles exceptions nobody wrote down, and the new one does not until someone finds them in production. Data migration that moves history the new system cannot represent. Scope growth, because the project becomes the vehicle for every wish. And running two systems longer than planned. Each is reduced by the same preparation: documenting the exceptions, profiling the data and setting a firm scope before the build starts.
Incrementally where the architecture allows it. Replacing one function at a time, with the old and new systems integrated during the transition, limits the blast radius of each cutover and delivers value early. A single big-bang replacement is sometimes unavoidable when the old system cannot be split, but it concentrates all the risk on one weekend. Where big-bang is necessary, a long parallel run and a rehearsed rollback are the mitigation.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
