Why ERP Implementations Fail in India (and How to Not Fail)
The Pattern Is Always the Same
A business signs an ERP contract in March with a six-month timeline. By September, two modules are live, finance is running parallel books in Excel, the store still keeps a physical register, and the person who championed the project has stopped attending review meetings.
Eighteen months later, someone says the software was wrong and starts evaluating a different vendor.
It usually was not the software.
I'm Ashish Sharma, founder of Codingclave. We build custom ERP and business systems and we get called into implementations that have stalled. The causes repeat with unusual consistency, and nearly all of them are visible before a contract is signed.
Cause 1: Nobody Cleaned the Data
The single most underestimated part of every ERP project.
Your existing systems contain years of accumulated mess. The same customer entered four times with different spellings. Item codes that changed convention twice. Suppliers who ceased trading in 2019. Stock quantities that have never reconciled with the physical warehouse. Outstanding balances nobody can explain.
Importing this into a new ERP produces a new ERP full of the same mess — and now nobody trusts the reports, so they keep using the old spreadsheets, and the implementation has failed while technically being complete.
Why it goes wrong: data cleaning belongs to the business, not the vendor. Only your people know whether two customer records are the same company. Vendors cannot do it for you, and they frequently underplay how large it is because it makes their timeline look bad.
What to do:
- Start data cleaning before implementation begins, not during
- Assign named owners per data domain — customers, items, suppliers, opening balances
- Set a cut-off: data older than a defined date is archived, not migrated
- Physically verify stock before opening balances are set
- Treat it as the critical path, because it is
A business that spends two months cleaning data before kick-off usually finishes faster than one that starts immediately and discovers the problem in month four.
Cause 2: Process Denial
You buy an ERP largely to standardise how things are done. Then every department explains why their process is the exception.
Some exceptions are real. Most are habit — the way it has been done since someone set it up years ago, preserved because nobody questioned it.
The consequence: heavy customisation. Expensive to build, expensive to maintain, painful at upgrade time, and it encodes the inefficiency you were trying to remove.
A workable test. For each requested customisation, ask: does this reflect something genuinely distinctive about how we compete, or is it just how we have always done it?
- A manufacturer with a genuinely unusual costing method for a specialised product — real, customise it.
- A sales team wanting the quotation screen laid out like the old system — habit, adapt.
Set a customisation budget at the start, both in money and in count, and make departments compete for it. Unlimited customisation requests are how six-month projects become two-year ones.
Cause 3: No Empowered Owner
Nearly every failed implementation shares this. Nobody inside the business owns it with real authority.
The vendor cannot own it — they do not have the power to tell your sales head to change how quotations are approved. An external consultant cannot either. It has to be someone internal, senior enough to make decisions stick, with enough time genuinely allocated.
What the owner does: arbitrates process disputes, approves or rejects customisations, holds departments to data deadlines, escalates when a function is not participating, and makes the trade-offs the project constantly demands.
The failure mode: the role is given to someone junior, or added to someone's existing full-time job, or split across a committee. Committees do not make the unpopular decisions ERP projects require.
If you cannot name this person before signing, do not sign.
Cause 4: Scope Creep
The project starts as finance and inventory. By month three someone has added HR, then production planning, then a customer portal, then a mobile app.
Each addition is individually reasonable. Together they turn a defined project into an open-ended one, and the original modules never stabilise because attention keeps moving.
The fix is unglamorous: freeze scope after discovery. New requests go on a phase-two list with a date. Ship phase one, stabilise it, then reopen.
Prefer phased over big-bang. Finance and inventory first, live and stable, then the next module. It delivers value sooner, lets your team absorb change gradually, and means a problem affects one function rather than the whole company.
Big-bang concentrates every risk on one date, which is invariably the date you can least afford disruption.
Cause 5: Training Treated as an Afterthought
Two days of training at the end, delivered by someone who knows the software and not your business, to people who are already resistant.
Then go-live, and the shop floor cannot find the screen they need, so they keep the register "just for now", and now you have two systems.
What works better:
- Train by role and workflow, not by module. A storekeeper needs to know how to receive goods, not a tour of the inventory module.
- Train with your own data, so screens look familiar.
- Identify super-users per department and train them deeply. People ask a colleague before they raise a ticket.
- Provide short reference material in the language your staff actually use. A one-page workflow sheet beats a 200-page manual.
- Plan for support in the weeks after go-live, when the real questions arrive.
Resistance is usually a signal, not an obstacle. When an experienced storekeeper says the new process will not work, they are frequently right about something the design missed. Listen before overriding.
Cause 6: Go-Live Timing
Going live at financial year end, during peak season, or in the middle of an audit.
The business is under maximum pressure exactly when the new system is at its least familiar. People revert to old methods to get through the week, and the implementation never recovers.
Choose your quietest period. Run parallel for at least one full cycle — both systems, same transactions, compare the outputs. For anything financial this is not optional. Differences are either bugs or business rules you did not know about, and you want to find both before the old system is switched off.
What a Realistic Plan Looks Like
Before signing
- Name the internal owner and confirm their allocated time
- Document current processes honestly, including the workarounds
- Start data cleaning
- Define phase one scope narrowly and write it down
- Agree a customisation budget
Discovery
- Vendor learns your business; you learn the software's assumptions
- Every gap decided explicitly: change the process, customise, or accept
- Firm scope, firm timeline
Build and configure
- Weekly demonstrations to actual users, not just the steering committee
- Data migration rehearsed repeatedly, not attempted once
- Integrations with existing systems built and tested early
Testing
- Real users, real data, real workflows
- Deliberately test the awkward cases: returns, cancellations, corrections, month-end
- Parallel run for a full cycle
Go-live and after
- Quiet period chosen deliberately
- Support present for several weeks, ideally on site initially
- Old system read-only rather than switched off
- Formal review at thirty and ninety days
Custom ERP: When It Is Right, and the Extra Risk
Everything above applies to custom builds too, plus one addition: with a product, the requirements already exist inside the software. With a custom build, you have to define everything.
That is a significant amount of decision-making, and it lands on the same internal owner who is already busy.
Custom is justified when your processes are genuinely distinctive, when you need deep integration with systems that have no connectors, or when licence costs at your scale exceed a build plus its maintenance. Our build vs buy framework applies directly, and custom software development cost in India covers the numbers.
Custom is the wrong answer when the real problem is that nobody configured the last ERP properly. Building bespoke software to escape an implementation failure usually reproduces the failure with a larger budget.
If you are evaluating products first, our ERP software guide for Indian businesses and best ERP software in India cover selection, and ERP development cost covers the build side.
Rescuing a Stalled Implementation
If you are already in trouble, the instinct is to change vendors. Sometimes correct, frequently not.
Diagnose first:
- Is the data clean? If not, no vendor will fix this. It is your work.
- Is there an empowered owner? If not, appoint one before doing anything else.
- Has scope expanded? Cut back to the original phase one and ship it.
- Are people trained? Retraining by workflow is cheaper than replacing software.
- Is the software genuinely incapable? Only after the first four is this a fair question.
In most stalled projects we are called into, the answer to question five is no. The software could do it; the project could not.
Related Reading
- ERP software guide for Indian businesses
- Best ERP software in India
- Build vs buy CRM in India
- Legacy software modernization
- Custom software development cost in India
- Automate business operations with custom software
Founder note: the question I ask first when an ERP project is struggling is "who decides when two departments disagree?" If the answer is a committee or nobody, that is the problem, and no amount of software will solve it. WhatsApp me on +91 92771 84741 for a straight assessment.