ERP
Most Indian mid-market companies — those in the ₹100–2,000 crore revenue band — are running ERP systems that were implemented somewhere between 2008 and 2018. These systems were selected when the business was smaller, when integration requirements were simpler, and when "real-time" meant a daily batch job rather than a live dashboard. In 2026, the operational gap between what these systems can deliver and what the business actually needs has become visible in day-to-day operations. The question most finance and operations leaders are asking is not whether to modernise — it is how to do it without shutting down the business while you do.
This article provides the decision framework: how to identify whether your ERP is genuinely holding you back, which of the three modernisation paths fits your situation, and what a realistic project looks like versus the idealised version vendors typically sell.
The signs are rarely dramatic. ERP debt accumulates gradually, and by the time the pain is visible, most teams have built workarounds so familiar they no longer register as inefficiencies.
The most reliable indicators are operational, not technical. If your month-end close takes more than five working days and a significant portion of that time is spent reconciling data between the ERP and spreadsheets, your reporting layer is broken. If your inventory team cannot answer "what is our actual stock position right now" without running a report that takes 20 minutes and is already 4 hours stale, your data architecture is the problem. If a new employee asking for a purchase order approval triggers a chain of WhatsApp messages because the system's approval workflow is too cumbersome to use, your workflow engine has been effectively abandoned.
The spreadsheet dependency is the most common symptom. When teams build Excel-based shadow systems to do what the ERP should be doing — financial consolidation, sales forecasting, production planning, vendor performance tracking — it means the ERP has stopped being the system of record and become the system of data entry. The analysis happens elsewhere, which means the analysis is not auditable, not consistent, and not scalable.
The audit risk is the one that tends to move boards. When your statutory auditors or internal audit team cannot trace a transaction through the system without asking someone to explain a manual step, you have an auditability problem. When the answer to "show me the approval chain for this purchase order" is "let me check the email thread," you are one investigation away from a finding.
There is no single right answer for mid-market ERP modernisation. The three paths differ in risk, cost, timeline, and disruption — and the right choice depends on how broken the current system actually is, how much change the organisation can absorb, and whether the business model is stable enough to justify a multi-year transformation.
Full replacement means selecting a new ERP platform, migrating your data, retraining your teams, and cutting over to the new system. It is the highest-risk option and the one most frequently oversold by ERP vendors and implementation partners. It is also sometimes the right answer.
Full replacement makes sense when the current system is genuinely unsupported — the vendor has end-of-lifed the version you are running and security patches are no longer available. It makes sense when the business model has changed so substantially that the current system's structure no longer maps to how the business operates. It makes sense when the cost of integration and augmentation has exceeded the cost of replacement, which typically happens after 10–12 years of layer-on-layer customisation.
What full replacement does not make sense for: businesses that are mid-growth and cannot absorb 18–24 months of implementation distraction; businesses where the current system works for core finance and the problem is reporting and workflow, not the ledger itself; businesses where a previous full replacement project failed and the organisation's change capacity is depleted.
The extend-and-integrate path keeps the ERP core — the ledger, the chart of accounts, the established transaction processing — and layers modern tools on top of it. A modern analytics layer replaces the ERP's native reporting. An AI-powered workflow engine handles approvals and exceptions that the ERP's built-in workflow cannot manage. A modern supplier portal replaces the ERP's vendor interface. The core transaction data stays in the existing system; the user experience and the intelligence move elsewhere.
This path is underutilised in India. Most mid-market companies either continue with the broken status quo or jump to full replacement — the middle option, which often delivers 80% of the value at 30% of the cost and disruption, is not well understood. The reason is that it requires integration expertise that most ERP vendors do not sell, and it requires a clear architecture view of what the ERP should and should not do.
Extend-and-integrate works when the core system is sound — data is reasonably clean, the ledger structure is correct, the transaction processing is reliable — and the problem is the experience layer. If you can get reliable data out of the ERP via API, you can build almost anything on top of it.
Module-by-module migration replaces one functional area at a time — typically starting with the area of greatest pain — while keeping the rest of the system running. The first wave might replace the inventory and warehouse management module. The second wave replaces HR and payroll. The third replaces the financial reporting module. The core ledger, which touches everything, is typically replaced last.
This path minimises disruption at the cost of a longer overall timeline and the complexity of running two systems simultaneously during each transition. It is the right choice when different parts of the business have different levels of pain and when the organisation's change capacity is limited. It is the wrong choice when the systems being modernised are too tightly coupled to separate cleanly.
Regardless of the path chosen, the decision about what to preserve and what to replace follows a consistent logic. Keep anything that is working, that has accumulated significant configuration value, and that is expensive to reconstruct. Replace anything where the cost of maintenance or workaround exceeds the cost of replacement.
In practice for most Indian mid-market companies:
One of the most cost-effective modernisation moves available to Indian mid-market companies in 2026 does not require changing the ERP at all. If the ERP exposes data via API — and most systems from the past 15 years do, even if the API is not well documented — you can connect AI agents to that data and get significant capability improvements without touching the core system.
Practically, this means: a real-time dashboard that pulls from the ERP and presents inventory positions, outstanding payables, and cash flow projections in a format that finance and operations can actually use. An AI agent that runs nightly reconciliation across the ERP and your bank feeds, flags exceptions, and assigns them to the right person for resolution. A natural language interface that lets a manager ask "what are our top 10 overdue receivables this week" and get the answer without running a report.
None of this requires migrating the ERP. It requires clean API access to the data, a well-designed integration layer, and AI agents that know how to interpret the data correctly. This is the extend-and-integrate path applied specifically to the intelligence layer.
The business case for ERP modernisation is often framed around the cost of the project. The more important number is the cost of the current state.
A finance team of eight people spending 30% of their time on manual reconciliation is costing the business roughly 2.4 full-time equivalents — at a fully loaded cost that, for a mid-market company, represents ₹60–90 lakh per year in finance team time alone, doing work that adds no analytical value. A five-day month-end close versus a two-day close is 36 extra working days per year when your senior finance people are focused on closing books rather than on analysis that drives decisions. An inventory system that cannot give you real-time stock positions means either carrying excess buffer stock or experiencing avoidable stockouts — both of which have measurable cost at mid-market scale.
The audit risk has a cost too, though it is harder to quantify until it materialises. A significant audit finding related to ERP controls or an inability to produce documented approval trails has both direct remediation cost and reputational cost with lenders and investors.
The CFO and board presentation for ERP modernisation needs three things: a quantified current-state cost, a realistic project cost, and a credible timeline to value. The most common reason modernisation projects fail to get board approval is that the presentation leads with project cost rather than current-state cost — which makes it look like a discretionary expense rather than a cost-reduction initiative.
Quantify three categories of current-state cost: people time spent on activities the ERP should handle automatically, inventory or working capital inefficiency attributable to poor data visibility, and audit or compliance risk exposure. In most mid-market companies, these three categories together exceed the cost of a well-scoped modernisation project within 24–36 months.
Three factors account for the majority of ERP project failures in the mid-market: scope creep, data migration underestimation, and change management neglect.
Scope creep happens when the initial project definition is too broad — "modernise our ERP" is not a project scope, it is a wish. Projects that stay on time and budget start with a specific functional scope, a clear definition of what is in and out, and a governance process that prevents scope additions without timeline and budget adjustments.
Data migration is consistently the most underestimated workload in ERP projects. Legacy ERP data is almost always messier than it looks — duplicate vendors, inconsistent product codes, historical transactions that don't balance, master data that has never been cleansed. Budget generously for data assessment, cleansing, and migration validation. What takes two weeks in the project plan typically takes eight.
Change management is the factor that determines whether the new system gets used or becomes the next legacy system that people work around. The technical implementation of a new ERP is the easy part. Getting 200 people to change how they work every day is the hard part, and it requires dedicated effort that most mid-market companies do not budget for separately.
Our ERP practice works with Indian mid-market companies across manufacturing, distribution, and services — and our starting point is always a current-state assessment before any modernisation recommendation. We have seen too many projects fail because the path was chosen before the problem was correctly diagnosed.
For companies where the extend-and-integrate path is appropriate, our integration team builds the API connectivity and AI augmentation layer without touching the core ERP. For companies where module-by-module or full replacement is warranted, our implementation team handles the project with a specific focus on data migration and change management — the two areas where mid-market projects most commonly fail.
Our automation practice handles the workflow layer independently of the ERP path — approval workflows, exception management, and reconciliation automation can often be deployed in 6–8 weeks while the longer-term ERP decision is still being made, delivering immediate value without waiting for the transformation to complete.
If you are running an ERP that is more than eight years old and the symptoms above are familiar, the right first step is an honest assessment of current-state cost. Talk to our team — we will tell you which path makes sense for your situation and what a realistic project looks like.