What Staying on Your Legacy ERP Costs the CFO's Own Budget

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A CFO or COO at a 200–800-person US manufacturer or distributor running a 10-plus-year-old ERP — Epicor, Infor, or a heavily customized on-premise Microsoft Dynamics — who has just received a modernization proposal from IT and needs to decide whether the status quo is actually cheaper than the disruption of replacing it

If you are a CFO holding a modernization proposal and asking whether the status quo is actually cheaper than the disruption, the honest answer is: you cannot know until you count the costs that are not on the IT budget. The vendor support contract is the smallest line. The largest is almost always 1.5–2.5 FTE of senior finance or ops staff whose job exists only to patch the gap between what your ERP exports and what the business needs to report — a cost that lives in departmental headcount, never in IT, and disappears the day a modern system goes live. Add the deals your sales team quietly stops pursuing because procurement asks for real-time inventory APIs you cannot provide, plus the audit findings tied to unsupported modules, and the 'cheaper to maintain' math usually inverts on a five-year horizon.

This post gives you the argument to take into the meeting: a line-item view of what you are already spending, the two sequencing options and their risk profiles, and the specifics that would turn any modernization range into a real quote.

Why the IT budget hides most of the cost

Every CFO has seen the same proposal structure: here is the annual vendor maintenance line, here is the hosting line, here is a one-time migration estimate, please approve. The problem is that the maintenance line is the only piece of the real cost that your controller can actually see. The rest is distributed across departments that do not report to IT and were never asked to tag their work as 'legacy ERP overhead.'

Industry benchmarks make the scale concrete. Legacy maintenance consumes 60–80% of total IT budgets, leaving as little as 20% for anything new — a figure Gartner, Forrester and Deloitte all converge on. Deloitte's 2026 Global Technology Leadership Study puts technical debt at 21–40% of total IT spending. But those numbers only cover what IT already owns. They do not cover the finance analyst building the inventory-to-GL reconciliation in Excel every Monday morning.

The five cost buckets that belong on one page

Before you evaluate any modernization proposal, build a one-page internal baseline across the five buckets below. Any of them, taken alone, is debatable. Together, they almost always exceed the IT line by 3–5x.

1. Vendor maintenance, hosting, and the module tax

Start with the obvious: annual support contracts, infrastructure, license true-ups, and the surcharge for modules the vendor has deprecated but still supports under extended agreements. This is the only number currently visible to you. Legacy maintenance costs compound at 10–20% annually, which means a flat line in this year's budget is a 60–150% increase over a five-year planning window. Build the baseline with that curve, not a straight line.

2. The reconciliation FTE no one calls a reconciliation FTE

This is the bucket that changes the meeting. Walk through your finance and ops org chart and identify every person whose weekly work includes the phrase 'export from [ERP], then…'. For most 200–800-person manufacturers running a decade-old Epicor, Infor, or customized Dynamics install, that list is longer than leadership expects.

The benchmarks:

• 68% of organizations lose 11+ hours per week to manual reconciliation, with 14% losing 21–40 hours. For a mid-market firm, that is routinely 1.5–2.5 full-time equivalents absorbed by work that would not exist on a modern system.
• 75% of finance specialists spend 5–6 hours per week recreating reports that already exist in some form — roughly 300 hours per person per year. A five-person team loses 1,500 hours annually to assembly rather than interpretation.
• 84% of finance teams say they spend too much time on manual processes, and only 46% of cash flow management is actually automated.

The cost model here is not speculative. Take fully-loaded salary (base + benefits + overhead, usually 1.35x base for a US mid-market firm), multiply by the FTE count you identified, and that is your annual spend on patching the ERP's output. In most CFO reviews, this single line is larger than the vendor support contract.

Important: this cost does not go to zero on day one of a new system. It typically drops by 60–80% once reporting, close, and reconciliation workflows are modernized. The remaining 20–40% is real finance analysis work that was always valuable; the system was just hiding it under spreadsheet labor.

3. The revenue your ERP is quietly blocking

This is the bucket most CFOs underestimate because the sales team has stopped flagging it. When an enterprise procurement team asks for an EDI connection, a real-time inventory feed, a customer portal with order history, or a SOC 2 report that covers the ERP's data flows — and your sales lead knows the answer is 'not in this quarter' — they stop surfacing the opportunity. The deal is lost before it enters the CRM as lost.

Fragmented ERP systems cost mid-sized manufacturers and distributors an estimated $800K–$2M per year in lost deals, margin erosion, and inventory distortion for a $50M revenue company. 77% of enterprises lack real-time access to ERP data, and 46% of manufacturers lack the visibility needed to respond to supply-chain changes.

To quantify this for your business, ask your head of sales two questions: which deals in the last 18 months required capabilities we could not deliver on, and what is the average contract value in that segment? That is your annual revenue block, and it is a line item on the cost of doing nothing.

4. Audit cost inflation and compliance exposure

If any part of your ERP runs on an unsupported version — a database the vendor has end-of-lifed, a middleware component out of extended support, a customized module nobody will patch — your auditors already know. Under SOC 2 Trust Services Criteria CC7.1 and CC6.1, unsupported software is a direct path to findings. When IT general controls are weak, auditors cannot rely on sampling and shift to detailed transaction-by-transaction testing. Your audit fee goes up, and the audit takes longer.

This applies to both public companies under SOX and private companies facing lender-required audits or customer-driven SOC 2 attestations. If you are pursuing enterprise customers in financial services, healthcare, or government, the SOC 2 report is table stakes — and a qualified opinion on IT controls is a deal-killer.

None of this is legal or audit advice; your external auditor and counsel should assess your specific exposure. But the shape of the cost is predictable: audit fees rise 15–40% once ITGC testing expands, and remediation projects to close findings often cost more than the modernization increment would have.

5. The breach and downtime tail

Unsupported modules do not receive security patches. An unpatched ERP running production order management and customer PII is a risk that your cyber insurance carrier is increasingly unwilling to underwrite at prior rates. This bucket is probabilistic rather than annual, but it belongs on the page — if only as a one-line note that insurance premiums are rising and renewal underwriting now includes ERP version questions.

An illustrative baseline (every assumption stated)

To make this concrete, here is how the five buckets stack up for an illustrative $75M-revenue distributor with 400 employees, running an on-premise ERP customized over 12 years, pursuing SOC 2 Type II for enterprise retail customers. Every number below is a modeled estimate using the benchmarks cited above, not a quote and not a prediction for any specific company.

The point is not the specific numbers — your figures will differ based on headcount mix, deal pipeline, and audit scope. The point is the ratio: in this illustrative model, the IT-visible cost is 15–20% of the total. The modernization proposal you are reviewing is almost certainly being compared against the wrong denominator.

The two sequencing options and how they fail

Once the baseline is honest, the sequencing question becomes easier. There are two realistic paths, and they have different risk profiles — but both are better understood than the vendor pitch deck suggests.

Big-bang replacement

Rip and replace: pick a new ERP, run parallel for a quarter, cut over. The upside is a clean architecture and a single project timeline. The downsides are well-documented: Gartner estimates 80% of modernization projects fail, usually from scope compression, insufficient domain understanding, and change-management collapse. For a 200–800-person operations-heavy business, big-bang cutover concentrates all the risk in one weekend. If it goes wrong, you cannot ship product.

Big-bang can work for firms with simple process footprints, strong internal change capability, and a boardroom appetite for a 12–18 month program with limited interim value. For most mid-market manufacturers and distributors with heavily customized workflows, it is the higher-risk path.

Strangler-fig increments

The alternative is to leave the legacy ERP running and incrementally route specific capabilities — reporting, customer portal, inventory APIs, AP automation, specific modules — to new systems that read from and write to the legacy database. Each increment is scoped to pay for the next: typically start with the reporting and reconciliation layer, because that is the increment that frees the FTE cost and funds everything downstream.

The tradeoff is honest: strangler-fig is slower to a 'fully modern' end state (often 24–36 months rather than 12–18), and you are running two systems during transition, which adds integration complexity. But each increment has standalone value, each one can be killed if it is not working, and the business never faces a single cutover weekend. For most CFOs weighing this decision, the risk-adjusted return on strangler-fig is better even if the headline timeline is longer. CodeNicely's digital transformation practice and broader enterprise engagements are structured around this incremental model for exactly this reason.

How to phase the spend so the first increment funds the next

The sequencing decision that matters most is which increment comes first. The answer is almost always the one that unlocks the largest hidden cost soonest — and for most mid-market firms, that is the reporting and reconciliation layer, because it is where the invisible FTE cost lives.

A workable phase order for a distributor or manufacturer looks like this:

1. Phase 1 — Reporting and reconciliation layer. Modern data warehouse, automated close workflows, API access to ERP data. Frees 60–80% of the reconciliation FTE within two quarters. Funds Phase 2.
2. Phase 2 — Customer and partner interfaces. Portal, EDI, real-time inventory APIs. Unblocks the enterprise deals that were quietly disqualified. Revenue impact in two to four quarters.
3. Phase 3 — Transactional core. Order management, inventory, procurement moved to a modern platform. The legacy ERP is reduced to a system of record for historical data.
4. Phase 4 — Decommission. Legacy ERP goes read-only or offline. Vendor support contract ends.

Phased this way, Phase 1 typically pays for itself inside 12–18 months on the reconciliation line alone, before any revenue impact from Phase 2. That is the structure to look for in any proposal — if the vendor cannot explain which increment pays for the next, the proposal is a big-bang in disguise.

What the business has to supply

No modernization proposal survives without three things from the business side, and the CFO is usually the only person who can commit them:

• A named business owner per increment — not IT, not the vendor. A finance or ops leader who can approve scope, resolve process disputes, and sign off on go-live.
• Protected time from the people who actually know how the legacy system works. This is usually one or two long-tenured staff members whose knowledge is undocumented. If they are 100% booked on BAU, the project will miss every date.
• Clean enough data to migrate. Not perfect — perfect is a trap — but a decision on what historical data moves, what archives, and what gets written off. This is a CFO call, not an IT call.

What turns the range into a quote

Any credible range for a modernization program depends on three specifics. Until these are scoped, any number is a guess:

• Integration surface. How many external systems (EDI partners, warehouse management, CRM, bank feeds, tax engines) does the ERP connect to, and which of those connections must survive the transition?
• Customization depth. How much of the current ERP is standard functionality versus custom code written over the last decade? Custom code is where estimates break down, because its intent is often undocumented.
• Data migration scope. How many years of transactional history must be queryable in the new system versus archived? This single decision can swing a program budget by 30–50%.

If you want to pressure-test a proposal against your actual baseline, that is the conversation to have — with your internal team first, then with a modernization partner who will scope rather than quote. CodeNicely's offerings page outlines where that scoping conversation typically starts.

The argument to take into the meeting

The modernization proposal on your desk is almost certainly comparing a bounded, one-time investment against the wrong baseline. The right baseline is not the vendor support line. It is the vendor support line plus the finance FTE absorbed by reconciliation, plus the enterprise deals quietly disqualified, plus the audit fee inflation, plus the compounding 10–20% annual increase on all of it.

Build that number for your business before you say yes or no. If the total cost of doing nothing is less than the modernization increment, keep the ERP — the proposal was wrong. If it is more, which is the usual answer, the question becomes sequencing, not whether. And the sequencing question has a defensible answer: start with the increment that recovers the largest hidden cost soonest, and use its savings to fund the next.

Frequently Asked Questions

How do I actually calculate the FTE cost of ERP workarounds without a formal study?

Ask every finance and ops manager one question: name every recurring task on your team that starts with exporting data from the ERP, and estimate the hours per week. Sum the hours, divide by 40, multiply by fully-loaded salary (base × 1.35 is a reasonable US mid-market loading). You will have a defensible number within a week. It will almost certainly be larger than you expect, and it is the single most useful figure to bring into the modernization conversation.

Isn't it cheaper to just keep paying maintenance than to take on a modernization program?

Only if you measure maintenance alone and ignore the compounding curve. Legacy maintenance costs compound at 10–20% annually, and the hidden costs in headcount, blocked revenue, and audit exposure compound alongside them. Over a five-year horizon, the status quo is rarely cheaper once those are included — and the gap widens every year.

What does a realistic modernization timeline look like for a 400-person distributor?

The honest answer is: it depends on integration surface, customization depth, and data migration scope — the three specifics named above. A strangler-fig approach typically delivers the first value-generating increment (usually reporting and reconciliation) in two to three quarters, with full transition over 24–36 months. A big-bang replacement is faster to the end state (12–18 months) but concentrates risk. Any firm quoting a confident timeline before scoping those three variables is guessing.

How do I justify the project to a board that remembers a failed ERP replacement from a decade ago?

Lead with the sequencing. Most failed ERP projects from the 2010s were big-bang replacements with 18-month timelines and single cutover weekends. A strangler-fig approach is structurally different: each increment is independently valuable, independently reversible, and funded by the savings from the prior increment. Show the board the phase plan, show which increment pays for the next, and show the kill criteria for each phase. That is a different risk profile than the project they remember.

What about SOC 2 and audit risk — is this really driven by the ERP version?

If any component of your ERP stack is on an unsupported version — database, middleware, OS, or custom modules — it is directly in scope for Trust Services Criteria CC7.1 and CC6.1. Your external auditor should confirm the specific exposure for your environment, and your counsel should advise on contractual and regulatory implications. But as a general matter, unsupported production software is one of the first things SOC 2 auditors flag, and remediation after a finding is typically more expensive than the modernization increment that would have prevented it.