Learn how legacy ERPs stifle innovation and increase IT overheads. See why CFOs choose cloud-based platforms to streamline operations and reduce risk.
Legacy systems rarely fail. That is precisely what makes them expensive. A system that broke would be replaced, budgeted for and dealt with. A system that works, slowly and awkwardly, gets tolerated indefinitely while the business quietly pays for it in ways that never appear as a line item.
The costs are real and they are distributed. A few hours here in manual reconciliation, a few there in a report somebody rebuilds in a spreadsheet, a decision made on a figure that turned out to be three weeks old. None of it is attributable to the system, so none of it ever gets counted against the system.
This article sets out where those costs actually sit, how to quantify them, and how to tell the difference between a system that is merely old and one that is genuinely constraining the business.
It is worth starting here, because the case for replacement is frequently made on the wrong basis.
A system being old is not a problem. A system that does what the business needs, reliably, at low cost, is a good system regardless of when it was built. Plenty of businesses run stable arrangements for a decade and get excellent value from them.
The problem arrives when the business has changed and the system has not, or when the system's limitations have been absorbed as workarounds rather than recognised as limitations.
That distinction matters because it determines whether the honest answer is replacement or something considerably cheaper. A specific process that is awkward can often be fixed without replacing anything. A structural mismatch between the business and its systems cannot.
The most quantifiable cost is the work people do because the system will not.
Duplicate data entry is the clearest, where the same information is keyed into two systems because they do not talk. Every instance is both time and a chance of divergence.
Reconciliation between systems is the second, and it is genuinely skilled work. Finding why two systems disagree, understanding whether the difference is legitimate, and resolving it takes somebody capable, every period.
Report assembly is the third, where a figure that should be a report is instead an export, a lookup and a spreadsheet formula. This is usually the largest single component and the one people are most likely to describe as normal.
Each of these is measurable if you decide to measure it. Track one month, note who does what and for how long, and multiply. The number is usually larger than anybody expected because it has never been assembled in one place.
This is the largest cost and the hardest to quantify, which is why it is almost always left out of the comparison.
A business operating without current, reliable information makes decisions on impressions and on figures that were true at some point. Pricing set without knowing true margin. Stock held because nobody can see what is actually moving. A customer retained because nobody has established that servicing them costs more than they pay.
The difficulty is that the better decision that was not made is invisible. Nothing goes wrong in a way anybody can point at, and the cost never appears anywhere.
A reasonable proxy is to list the decisions the business has made in the past year where better information would have changed the answer, and to estimate what the difference was worth. Most management teams can name two or three without much prompting, and the aggregate is usually substantial.
The most consequential cost in growing businesses is the growth that does not happen because the systems could not carry it.
This shows up in specific forms. A second location that would require duplicating a manual process. A channel that cannot be served because order volume would exceed what people can key. An acquisition that is harder to justify because integrating the target's systems looks unmanageable.
These decisions are rarely framed as system constraints. They are framed as operational complexity, or capacity, or risk. But the underlying limitation is frequently that the system cannot scale without adding proportionate headcount.
The test worth applying is whether the business could double its transaction volume without doubling its administrative staff. Where the answer is no, the system is a constraint on growth whether or not anybody has described it that way.
Businesses that have extended a legacy system rather than replacing it accumulate a layer of connections, and that layer has an ongoing cost.
Every integration is a permanent maintenance obligation. It breaks, it needs monitoring, and it requires attention whenever either side changes. Where there are several, somebody spends real time keeping them running.
Custom modifications carry a similar burden. Code written years ago, frequently by somebody no longer available, that has to be understood before anything nearby can change.
And older systems increasingly require their own infrastructure, meaning servers, backups and the specialist knowledge to keep them running. That cost is genuine and it is frequently accounted for as general IT rather than attributed to the system it supports.
A category of cost that is zero until it is not.
Software has a lifecycle. Vendors end support for older versions, stop issuing security updates, and eventually retire products entirely. A business running an unsupported version is carrying a risk that is invisible right up to the point it materialises.
The related exposure is version lock, where a business cannot upgrade because its customisations or integrations would break. That situation tends to worsen, since each year on an old version increases the gap that an eventual upgrade has to cross.
And there is dependency on individuals. Where one person understands the system, its customisations and the reasons behind them, their departure is a genuine operational risk rather than an inconvenience.
None of these produce a monthly cost. All of them produce a large one eventually, and the timing is not yours to choose.
Regulatory obligations have moved from periodic to continuous, and older systems were built for the periodic world.
Single Touch Payroll reports every pay event rather than annually, in a format that has changed substantially. Tax reporting requirements evolve. Employment compliance has become a genuine enforcement priority rather than a background obligation.
Where a system cannot meet a requirement natively, the business meets it with a workaround, and workarounds are where compliance failures originate. A manual process that produces the right answer when performed correctly will eventually be performed under pressure by somebody who was not fully trained.
The cost here is asymmetric. Nothing happens for years, and then remediation, penalties and the professional fees to establish the extent of a problem arrive together.
An underappreciated cost, and one that has become more significant as recruitment has become harder.
People do not generally leave because of the volume of work. They leave because of the proportion of it that is mechanical and avoidable. A finance role that is mostly reconciliation and rekeying is difficult to fill and difficult to retain.
Poor systems also make onboarding slower, because a new starter has to learn both the process and the workarounds, and the workarounds are usually undocumented.
And they concentrate knowledge. Where the system is awkward, the people who have learned to navigate it become disproportionately valuable, which is a risk rather than an asset.
Turnover cost is real and rarely attributed to the system that contributed to it.
Some costs land outside the business, where they are least visible and most damaging.
Customers experience legacy systems as slow responses to questions about their order, invoices that arrive with errors, and an inability to self serve for information they consider basic.
Suppliers experience them as late payments caused by approval processes that depend on paper, and as queries about invoices that were received and then lost.
Neither group usually complains in a way that reaches management. They simply factor it in, and it shows up eventually as a customer who did not renew or a supplier whose terms are less favourable than they might have been.
A short exercise produces a defensible number and is worth doing before any conversation about replacement.
Start with time. For one month, have people note how long they spend on duplicate entry, reconciliation between systems, and building reports outside the system. Convert to cost using real salary figures including on costs, and annualise.
Add the direct costs. Licensing and maintenance on the legacy system, the infrastructure it needs, the specialist support you buy, and the cost of maintaining integrations.
Add error correction. What has been spent in the past year fixing things that went wrong because information was wrong or transferred incorrectly.
Then estimate the decision cost and the growth constraint separately, as ranges rather than points, and present them as such rather than pretending to precision.
Most businesses that do this find the total is a multiple of what they assumed, and the components that surprise them are usually report assembly and reconciliation.
A few indicators distinguish a system that needs a specific fix from one that has been outgrown.
The same information is entered in more than one place, by different people, as a matter of routine.
Reporting requires exporting and rebuilding, so the system holds the data and something else holds the meaning.
The month end close is getting longer rather than shorter, which usually indicates the process is compensating for something structural.
Nobody can answer a question about profitability by product, project, customer or site without a manual exercise.
And growth is creating problems that adding people does not solve, because the constraint is coordination rather than capacity.
One of these is a specific problem. Three or four together is a structural mismatch.
The other side of the comparison deserves the same honesty, because businesses that budget only for licence and implementation are the ones who later feel the investment underperformed.
Count the licensing, the implementation fee, the internal time which is real cost even without an invoice, data cleansing effort, training both at go live and afterwards, and the ongoing capability to administer the new system.
Budget for the twelve months after go live rather than only the project, because reporting gets built out, deferred items get delivered and refinements get made.
And allow for the productivity dip immediately after cutover, which is real and temporary and considerably easier to manage when it was planned for.
The decision is a comparison rather than a judgement about age.
Act where the counted cost of the current arrangement exceeds the cost of the alternative, where the business can genuinely free the people a project requires, and where the constraint is structural rather than a single awkward process.
Do not act where the pain is specific and narrow, since fixing that process is cheaper. Do not act where the business is about to change shape significantly, since you would be building for a structure that is about to change. And do not act where the organisation cannot free the people, because the project will produce a system that reflects whoever was available.
Our piece on timing an ERP implementation covers that judgement in more detail, and ERP versus accounting software covers the question of what you would actually be moving to.
The reason legacy systems persist is not that businesses are unaware of them. It is that the cost is distributed, invisible and never assembled, so there is no moment at which it becomes obviously unacceptable.
Assembling it is the useful first step, and it is an afternoon of work rather than a project. Whatever the decision then turns out to be, it is at least an informed one.
Where the question is whether current systems will support the business you are becoming, advisory and strategy is the right starting point. Where the decision is made, preparing from day one covers the work that should happen before a project begins.
If you would like help building the comparison for your own business, get in touch.
