What a Legacy Core System Costs You Before It Fails

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

For: A COO or CIO at a 500–2000 person Indian enterprise — manufacturing, logistics, or financial services — whose core system is more than eight years old, still running on-premise, and whose IT team spends more time keeping it alive than improving it; she knows modernization is overdue but has never been able to build the board-level financial case to approve the spend

Here is the argument that gets the budget approved: your CFO is already funding the replacement. She just cannot see it as a single line item. Industry benchmarks from Gartner, Forrester and Deloitte place legacy maintenance at 60–80% of total IT spend across enterprise portfolios — meaning on a ₹10 crore IT budget, ₹6–8 crore is going into keeping existing systems alive before a single rupee is spent on anything new. Add shadow IT, reconciliation headcount, and the DPDP and GST exposure a hardcoded data model cannot close, and the cost of doing nothing is usually larger than the cost of a phased rebuild. This post gives you the frame to put that in front of the board.

Why the usual business case fails in the boardroom

Most modernization proposals arrive on the CFO's desk as a single number — the price of the new platform, the integrator fees, the change management overhead. The CFO looks at that number against a current operating cost that appears flat and predictable, and defers the decision. Nothing in the proposal has quantified what the status quo is actually costing, so the status quo wins by default.

The modernization business case that gets approved does the opposite. It separates the P&L into two columns: what you are paying today to keep a seven-, ten-, fifteen-year-old core running, and what a phased replacement would cost over the same horizon. The first column is almost always larger than the finance team realises, because the cost is scattered across a dozen cost centres that nobody has ever summed.

The five cost buckets your CFO is already funding

1. AMC, premium support, and the end-of-life surcharge

This is the only line item everyone can see, and it is usually the smallest of the five. The pattern worth highlighting to the CFO is the escalation curve: legacy maintenance costs typically increase 10–15% annually after warranty expiration, and premium support for end-of-life systems runs 50–200% higher than standard support. If your vendor has moved you onto extended support — the SAP ECC conversation, the Windows Server 2012 conversation, the Oracle 11g conversation — you are already inside that premium bracket.

Pull three years of AMC invoices and plot them. The slope is the argument. A flat line in the P&L is actually a compounding liability.

2. The headcount absorbed by workarounds

This is the bucket finance never counts. The two people in accounts whose job is really "reconcile what the ERP exported against what GSTR-2B says." The ops analyst who maintains the master spreadsheet because the system cannot produce a usable report. The warehouse supervisor who re-keys dispatch data into the logistics portal because the integration broke in 2021 and was never fixed.

These salaries sit in business cost centres, not IT. They are invisible to the CIO and invisible to the CFO as technology spend, but they exist entirely because the core system cannot do what the business needs. For a 500–2000 person enterprise, this is routinely 15–30 FTEs. At a fully-loaded cost of ₹12–18 lakh per head, that is ₹2–5 crore a year of operating expense attributable directly to the legacy system — and it grows every time a new process requirement cannot be configured and has to be worked around manually.

3. Shadow IT

When the sanctioned system does not meet the business need, the business buys its own. Gartner research cited in enterprise spend analyses puts shadow IT at 30–40% of total IT expenditure in large organisations. For a ₹10 crore IT budget, that is ₹3–4 crore in unmanaged SaaS subscriptions, departmental tools, consultant-built Access databases, and WhatsApp-based process layers that exist precisely because the core cannot flex.

Shadow IT is not a governance problem. It is a symptom. And it is a cost line a modernization case can legitimately claim back, because a modernised core absorbs most of what the shadow stack was built to do.

4. DPDP exposure

India's Digital Personal Data Protection Act rules were notified in November 2025, with a compliance deadline of May 2027. The penalty schedule, as summarised by EY India, allows for fines of up to ₹250 crore per violation for failure to implement adequate security safeguards. The piece most boards underestimate: penalties are per-instance, not per-event — a single non-compliant system processing thousands of personal data records can generate multiple violations from one audit finding.

As of 2026, 72% of Indian enterprises are not fully DPDP-compliant according to DSCI/PwC India — a gap that legacy systems make structurally difficult to close. Hardcoded data architectures, missing audit trails, no concept of consent as a first-class entity, no granular access controls, no deletion workflow — these are architectural problems, not policy problems. You cannot patch your way to DPDP compliance on a ten-year-old monolith. You can only wrap it, which pushes the real fix another budget cycle out while the May 2027 deadline keeps closing. Your legal counsel will need to scope the specific exposure for your data footprint; the architectural point stands independently.

5. GST and audit exposure

India's GST scrutiny regime has moved to continuous, automated, data-driven checks. Section 65 departmental audits and Section 61 return scrutiny are now driven by algorithmic flagging of mismatches between filed returns and the GSTN's own data. Under Section 16(2)(aa), operative since 1 January 2022, ITC can be disallowed where the purchase register does not reconcile against GSTR-2B — and the matching is a legal condition for the credit itself, not a procedural nicety.

A legacy ERP that cannot pull GSTR-2B in real time, cannot flag mismatches at invoice booking, and cannot reconcile at scale is directly costing you working capital in disallowed credits and the headcount to chase them. Any ITC disallowance treatment should be reviewed by your tax advisor against your specific filings, but the operational cost of a system that forces monthly manual reconciliation is observable from your own close calendar.

Modelling the cost of doing nothing

Here is the exercise, framed as something your finance team can actually run. For each of the five buckets, pull the current annual spend. Project it forward three years with a conservative escalator — 10% for AMC, 6% for reconciliation headcount, 15% for shadow IT (it compounds fast), zero for compliance exposure but a flagged tail risk. Sum the three-year total. That is the cost of doing nothing, and it is almost always between ₹15 crore and ₹60 crore for an enterprise in your size band, depending on where you sit on the legacy curve.

Illustrative only — every assumption stated: a 1,200-person manufacturing enterprise with a ₹10 crore IT budget, a 12-year-old on-prem ERP on extended support, 20 FTEs absorbed in reconciliation and workarounds, measurable shadow IT in sales and procurement, no DPDP programme yet. Three-year do-nothing cost: AMC trajectory ₹6cr→₹8cr, workaround headcount ₹3cr/year, shadow IT ₹3cr→₹4cr/year, plus an unquantified but non-zero DPDP tail. The three-year run-rate on the current path lands somewhere between ₹35 and ₹45 crore before you have improved a single business outcome. Your numbers will differ — the point is the method, not the figure.

The two sequencing options, and the risk profile of each

Big-bang rebuild

Full replacement of the core, cut-over on a date, old system retired. The attraction is architectural coherence and a clean end state. The reality in enterprise contexts: 18–30 month timelines, a parallel-run period that doubles operational load, a change management bill that often rivals the build cost, and a single catastrophic failure mode on cut-over day. For a core system that touches finance, inventory, and compliance, the risk of a bad cut-over is existential — and the board knows it. This is why big-bang proposals keep getting deferred.

Strangler-fig incremental modernization

Named after Martin Fowler's pattern: you wrap the legacy system in an API layer, then build new capability outside it, routing traffic away from the old core module by module. Finance stays on the legacy for a year while the new order management goes live. Inventory moves next. The old system shrinks over 18–36 months until what remains is small enough to retire or leave as a system of record.

The advantage is that risk is bounded to one module at a time, and the first increment produces measurable business value — recovered reconciliation hours, closed shadow IT line items, demonstrable DPDP posture improvement — that funds the second increment. The disadvantage is honest: you run two architectures in parallel for longer, your integration surface area grows before it shrinks, and the discipline required to actually retire the legacy (rather than keep it running forever as a convenient fallback) is organisational, not technical. Teams that cannot commit to retirement end up paying for both systems in perpetuity, which is worse than either extreme.

For most Indian enterprises in the 500–2000 person band, strangler-fig is the sequence that gets approved, because the first increment can be scoped at a budget the CFO will sign for a defined 90–120 day outcome. India's application modernisation market is growing at 18.6% CAGR precisely because this incremental model has made the spend defensible in a way big-bang never was.

How to phase the spend so the first increment pays for the next

The sequencing principle: pick the first module by payback velocity, not by architectural tidiness. The right first increment is usually the one that collapses the largest workaround or the loudest compliance gap, because those produce savings or risk reduction the CFO can book inside the same fiscal year.

Three candidates that tend to work for enterprises in your profile:

• GST reconciliation and e-invoicing layer. Builds alongside the legacy ERP, pulls GSTR-2B, matches against the purchase register, flags mismatches at booking. Payback: recovered ITC plus 2–5 FTEs returned to higher-value work. Timeline is short because scope is narrow.
• Customer or vendor master data service. Lifts the master data out of the legacy into a modern service with DPDP-grade consent, access, and audit controls. Payback: closes the biggest DPDP exposure first, and every subsequent module reads from the clean master instead of the legacy tables.
• Order-to-cash or dispatch workflow. Replaces the module where shadow IT and manual re-keying are most visible. Payback: closes SaaS line items, reduces working capital locked in reconciliation lag.

Each of these can be scoped as a defined-outcome increment. The savings from increment one — in headcount redeployed, SaaS retired, ITC recovered — are what you ring-fence to fund increment two. By the third increment, the business case is self-sustaining and the board conversation shifts from "should we modernize" to "how fast can we go." This is the pattern most legacy modernization programmes that actually complete tend to follow.

What the business has to supply

Modernization is not something IT does to the business. The programmes that fail are the ones where the business treats it as a technology project and withdraws. What the business must commit, in writing, before the first increment starts:

• A named business owner per module — not a steering committee, a single accountable executive — who can make trade-off decisions in days, not weeks.
• Time from the people who actually do the work. Not just the department head. The person who runs the reconciliation today has process knowledge nobody else has, and they need 20–40% of their time for the duration of their module's build.
• A commitment to retire, not augment. Written into the programme charter: on cut-over of each module, the legacy equivalent is decommissioned on a defined date. Without this, cost savings never materialise.
• Data hygiene budget. Legacy data is dirty. Someone has to clean it, and that work is unglamorous and consistently underestimated. Budget 15–25% of the increment cost here.
• Change management. New screens, new workflows, new approvals. Training is a line item, not an afterthought.

Framing the ask to the board

Walk in with two numbers and a decision, not three options and a recommendation.

Number one: the three-year do-nothing cost, built up from the five buckets above, with the methodology on one page so the CFO can challenge each assumption. Number two: the cost of increment one, scoped to a specific module, with the payback inside the same fiscal year quantified in the same units. The decision you are asking for is approval of increment one only — not the full programme — with a gate review before increment two is funded.

This framing works because it mirrors how the CFO already thinks about capital allocation: bounded commitment, measurable outcome, option to continue. It takes modernization out of the "big scary number" bucket and puts it in the "funded portfolio of increments" bucket, which is where capital actually gets allocated in Indian enterprises.

The question of what any specific increment will cost at your organisation depends on three things that a one-hour scoping conversation can answer but a blog post cannot: how many integrations the module touches, how clean the data you are migrating is, and how much of the business process is actually documented versus living in people's heads. Those three variables move an estimate by a factor of three or more. If you want to turn the model in this post into an actual number for your environment, that is the conversation to have with a modernization partner.

Frequently Asked Questions

How much does a legacy system cost per year to keep running?

Across Gartner, Forrester, and Deloitte benchmarks, legacy maintenance runs 60–80% of total IT spend, with another 30–40% of IT budget often sitting outside IT as shadow IT. On a ₹10 crore IT budget, the true all-in cost of the legacy footprint — AMC, premium support, reconciliation headcount, shadow IT, compliance remediation — typically lands between ₹12 and ₹18 crore when you count every cost centre. Your actual number depends on your vendor's support tier, your workaround headcount, and whether a DPDP or GST remediation is already underway.

What is the difference between a strangler-fig and a big-bang modernization?

Big-bang replaces the entire core on a cut-over date — architecturally clean but with a single catastrophic failure mode, 18–30 month timelines, and a change management bill that often matches the build. Strangler-fig wraps the legacy in an API layer and replaces it module by module over 18–36 months, bounding risk to one module at a time and letting early increments produce savings that fund later ones. For most Indian enterprises in the 500–2000 person band, strangler-fig is what the board will approve because the first increment is a defined-outcome commitment, not a bet-the-company programme.

How long does a legacy ERP modernization take?

The honest answer is that "the modernization" is the wrong unit — the right unit is the first increment, which is typically 90–180 days for a well-scoped module like GST reconciliation, master data, or a single workflow. The full programme to retire a legacy core usually spans 18–36 months of overlapping increments. What moves the timeline most: the number of integrations, how clean the migration data is, and whether the business has committed named owners and a retirement date for each legacy module. Those are the specifics that would turn this range into a plan.

Can we patch our existing ERP to be DPDP-compliant instead of modernising?

Partially, and only for a while. DPDP requires granular consent, auditable access, deletion workflows, and data minimisation as architectural properties — not as policy overlays. Legacy systems with hardcoded data models and shared service accounts can be wrapped with a compliance layer that handles some requirements, but the underlying exposure remains, and 72% of Indian enterprises are currently not fully compliant for exactly this reason. Your legal counsel should scope your specific obligations, but architecturally, wrapping buys time; it does not close the gap.

What goes wrong most often in legacy modernization programmes?

Three failure modes dominate. One, the business treats it as an IT project and withdraws, so the people with the real process knowledge never engage. Two, the legacy is never actually retired — the new system goes live alongside it and the organisation pays for both forever. Three, data cleanup is underestimated, which pushes timelines and erodes trust in the new system on day one. All three are organisational, not technical, which is why the business-side commitments outlined above matter more than the technology choice.