ERP implementations have a reputation for being expensive, slow, and painful. That reputation is earned — but it doesn't have to be your experience. The projects that go wrong almost always fail for the same reasons: unclear requirements, over-customization, poor data migration, and insufficient change management. None of these are technical problems. They're planning problems. This guide covers how to plan, evaluate, implement, and go live with an ERP system without joining the 55% that blow their budget.
When You Actually Need an ERP
Not every company needs an ERP. Many companies that buy one don't need one — they need better processes or better integration between existing tools. An ERP makes sense when:
| Signal | What It Looks Like | ERP Needed? |
|---|---|---|
| Multiple disconnected systems | Finance in Tally, inventory in Excel, orders in a custom app, HR in BambooHR — none talk to each other | Maybe — try integration first |
| Manual data reconciliation | Finance team spends 2 days/month matching invoices to purchase orders to delivery receipts | Yes — this is what ERP solves directly |
| No single source of truth | "What's our current inventory?" gets 3 different answers from 3 departments | Yes |
| Outgrowing QuickBooks/Tally | Multi-entity, multi-currency, or multi-location operations that basic accounting can't handle | Yes |
| Compliance requirements | Audit trails, approval workflows, and access controls that spreadsheets can't provide | Yes |
| "We need better reporting" | Executives want dashboards but data lives in 8 spreadsheets | Not necessarily — a BI tool + data warehouse might be cheaper |
The honest test: if your company has under 50 employees and operates in one country with one product line, you probably don't need a full ERP. Good accounting software (Zoho Books, QuickBooks Online) plus a CRM plus proper integration will serve you better at a fraction of the cost.
Requirements Gathering That Actually Works
The #1 cause of ERP failure is bad requirements. Not missing requirements — bad ones. "The system should be user-friendly" is not a requirement. "A purchase order must be approvable from mobile with one tap" is.
The Three-Layer Approach
We structure ERP requirements in three layers:
- Business requirements — What business outcomes must the ERP enable? ("Close monthly books within 3 business days instead of 12.")
- Process requirements — What workflows must the system support? ("Purchase order → 3-level approval → vendor PO → goods receipt → invoice matching → payment.")
- Functional requirements — What specific features are needed? ("System must support partial goods receipt against a single PO line item.")
Start from the top. Most companies jump straight to layer 3 and end up with a 400-line requirements spreadsheet that nobody reads and doesn't reflect actual business needs.
Must-Have vs Nice-to-Have
Force-rank every requirement into three buckets:
- Must-have (M): Business cannot operate without this. If the ERP can't do it, it's disqualified. (Typically 20-30% of requirements.)
- Should-have (S): Significant value, but workarounds exist. (40-50%.)
- Nice-to-have (N): Would be great, but won't affect the decision. (20-30%.)
If more than 40% of your requirements are "must-have," you're not being honest about priorities. Push harder. This categorization will save you months during vendor evaluation because you can quickly eliminate vendors that fail on must-haves without evaluating 400 features.
Evaluating ERP Vendors (2026 Landscape)
| ERP | Best For | Typical Cost (50 users) | Implementation Time |
|---|---|---|---|
| SAP S/4HANA Cloud | Large enterprises, manufacturing, complex supply chains | $200K-1M+/year | 9-18 months |
| Oracle NetSuite | Mid-market, multi-subsidiary, fast-growing companies | $50K-200K/year | 4-9 months |
| Microsoft Dynamics 365 | Microsoft-heavy orgs, services companies | $40K-150K/year | 4-12 months |
| Odoo | SMBs, budget-conscious, modular needs | $5K-30K/year | 2-6 months |
| Zoho One | Small businesses, all-in-one suite | $3K-15K/year | 1-3 months |
| ERPNext | Open-source, Indian compliance built-in, SMBs | Free (self-hosted) / $5K-15K/year (cloud) | 2-5 months |
The Evaluation Process We Recommend
- Long list (2 weeks): Identify 6-8 vendors that fit your industry and size. Eliminate based on must-have requirements.
- Short list (2 weeks): Send detailed RFP to 3-4 vendors. Include your top 15 process scenarios.
- Demo with YOUR data (3-4 weeks): Don't watch canned demos. Give vendors your actual data — your chart of accounts, your product catalog, a sample purchase order — and watch them process it. This is where reality diverges from sales pitches.
- Reference checks (1 week): Talk to 2-3 customers of similar size and industry. Ask: What surprised you? What took longer than expected? Would you choose this vendor again?
- Negotiation (2-3 weeks): ERP pricing is always negotiable. Multi-year contracts get 15-25% discounts. But never sacrifice implementation quality for license savings — the cheapest license with the worst implementation partner is the most expensive option.
Customization vs Configuration: The Decision That Kills Projects
This is where most ERP projects go off the rails. The distinction:
- Configuration: Using built-in settings to match your processes. Turning features on/off, setting approval thresholds, defining workflows using the vendor's tools. Low risk, easy to upgrade.
- Customization: Writing custom code to make the ERP do something it wasn't designed to do. High risk, breaks during upgrades, expensive to maintain.
| Scenario | Right Approach | Why |
|---|---|---|
| "Our approval workflow needs 4 levels instead of 3" | Configuration | Most ERPs support configurable approval chains |
| "We need a custom pricing algorithm based on 12 variables" | Customization (limited) | Complex pricing rarely fits standard modules; build as an extension |
| "Our invoice format must look exactly like our current one" | Change the invoice format | Customizing output templates to match legacy formats is pure waste |
| "We need to integrate with our proprietary warehouse system" | Integration (API) | Use ERP's API layer, don't modify ERP internals |
| "The ERP's procurement module doesn't support our 7-step process" | Simplify the process | If the ERP supports 4 steps and you need 7, question whether you need 7 |
| "We want the dashboard to show real-time production data from IoT sensors" | Separate BI tool + integration | ERP dashboards aren't built for real-time IoT. Use Grafana or Power BI. |
Our rule of thumb: if customization exceeds 20% of total implementation effort, you've chosen the wrong ERP. Find one that fits your processes better out of the box, or change your processes to fit the ERP. The second option is usually better — ERP vendors have spent decades encoding best practices into their standard workflows.
Data Migration: The Silent Project Killer
Data migration is consistently underestimated. "We'll just export from the old system and import into the new one." No. You won't. Here's why:
- Old data has quality issues you've been ignoring for years (duplicate customers, incomplete addresses, wrong categorizations)
- Data models don't map 1:1 between systems (old system has one "customer" field, new system separates "billing contact" and "shipping contact")
- Historical data may not fit new validation rules
- Open transactions (pending orders, partial invoices) require special handling
The Migration Plan
| Phase | Duration | Activities |
|---|---|---|
| 1. Data Audit | 1-2 weeks | Profile all data: volume, quality, completeness. Identify duplicates, orphans, invalid records. Decide what migrates and what doesn't. |
| 2. Mapping | 1-2 weeks | Map every field from old system to new. Define transformation rules. Document decisions ("old 'VIP' status maps to new 'Tier 1' classification"). |
| 3. Cleansing | 2-4 weeks | Fix data quality issues BEFORE migration. Merge duplicates, fill gaps, validate addresses. This is the most time-consuming step. |
| 4. Test Migration | 1-2 weeks | Run migration against test environment. Validate record counts, financial totals, relationship integrity. Fix issues. |
| 5. Rehearsal | 1 week | Full dress rehearsal with production data. Time the migration. Verify rollback procedures work. |
| 6. Production Migration | 1-3 days | Execute migration during planned downtime. Validate. Open for users. |
What to Migrate (And What to Leave Behind)
Don't migrate everything. Seriously. Here's our framework:
- Always migrate: Master data (customers, vendors, products, chart of accounts), open transactions (pending orders, unpaid invoices), last 2 years of financial data (for reporting continuity)
- Maybe migrate: 3-5 years of historical transactions (if needed for trend analysis), custom fields and categorizations (only if they map cleanly)
- Don't migrate: Data older than 5 years (archive separately), temporary/test records, data that was wrong in the old system (fix it, don't migrate it)
Go-Live Strategy: Big Bang vs Phased
| Strategy | How It Works | Best For | Risk Level |
|---|---|---|---|
| Big Bang | All modules, all locations go live on one date | Small companies (< 100 users), simple implementations | High (but fast) |
| Phased by Module | Finance first → Procurement → Inventory → Manufacturing | Mid-market, moderate complexity | Medium |
| Phased by Location | HQ first → Branch 1 → Branch 2 → International | Multi-location operations | Medium |
| Parallel Run | Old and new systems run simultaneously for 1-3 months | Regulated industries, zero-tolerance for errors | Low (but expensive and exhausting) |
For most mid-market Indian companies, we recommend phased by module — start with finance (it touches everything), then add procurement, then inventory/operations. Each phase takes 4-8 weeks, and lessons from phase 1 directly improve phases 2 and 3.
Go-Live Checklist
Every go-live should pass these gates:
- All must-have requirements tested and signed off by business users (not IT)
- Data migration validated — record counts match, financial totals reconcile
- At least 80% of users trained and confident (not just attended a session)
- Rollback plan documented and tested
- Support plan for first 2 weeks: dedicated team, extended hours, known-issues list
- Cutover plan with exact timing: old system locked at X, migration starts at Y, new system opens at Z
Post-Launch Reality: The First 90 Days
The go-live isn't the finish line — it's the halfway point. Here's what to expect:
Weeks 1-2: Survival mode. Everything feels harder than the old system. Users can't find things. Reports don't match what they're used to. The support queue is full. This is normal. Have a "war room" team available to resolve issues in real-time.
Weeks 3-4: Stabilization. Major issues are resolved. Users are developing new habits. You'll discover edge cases that weren't caught in testing — handle them quickly but don't panic. Track defects vs. training gaps (many "bugs" are actually users not knowing the new workflow).
Months 2-3: Optimization. Now you can see what's actually working and what needs adjustment. Refine workflows based on real usage data. Add the should-have features that were deferred from the initial launch. Start measuring ROI against the business case.
Common Post-Launch Mistakes
- Disbanding the project team too early. Keep the core team together for at least 3 months post-launch. The implementation partner should provide hypercare support for this period.
- Ignoring user feedback. If users create workarounds (Excel exports, manual tracking), it means the ERP isn't meeting a need. Investigate and fix.
- Not measuring adoption. Track login frequency, feature usage, and process completion rates. Low adoption in month 3 means change management needs attention, not more training.
Frequently Asked Questions
How much does an ERP implementation actually cost?
For a 50-user mid-market company in India: software licensing runs ₹15-60 lakhs/year depending on vendor. Implementation (consulting, customization, migration, training) typically costs 1.5-3x the first-year license fee. So total first-year cost: ₹40 lakhs to ₹2.5 crores. The wide range depends on complexity, customization level, and vendor choice. ERPNext and Odoo sit at the low end; SAP and Oracle at the high end.
Should we move to cloud ERP or keep it on-premise?
Cloud, in almost every case. Cloud ERPs (NetSuite, SAP S/4HANA Cloud, Dynamics 365 Business Central) eliminate server management, handle upgrades automatically, and scale with your business. On-premise only makes sense if you have strict data residency requirements that cloud vendors can't meet, or if you're in a regulated industry that mandates on-premise data storage. Even then, many cloud vendors now offer India-based data centers.
How long does a typical ERP implementation take?
Small company (< 50 users, basic modules): 2-4 months. Mid-market (50-200 users, multiple modules): 4-9 months. Large enterprise (200+ users, complex requirements): 9-18 months. These are realistic timelines assuming adequate resources and decision-making speed. The #1 cause of timeline overrun: slow decision-making by the client's steering committee.
What's the best ERP for Indian companies?
Depends on size and budget. Under ₹10 lakhs/year: ERPNext (open-source, Indian-built, GST-ready) or Zoho One. ₹10-50 lakhs/year: Odoo or Microsoft Dynamics 365. Above ₹50 lakhs/year: Oracle NetSuite or SAP. Key factor for India: GST compliance, TDS handling, and e-invoicing support. ERPNext and Tally-integrated solutions have the best out-of-box Indian compliance.
Can we implement ERP in phases or does it have to be all at once?
Phased is almost always better for mid-market companies. Start with finance and accounting (it's the backbone), then add procurement, then inventory or manufacturing. Each phase validates the next. The only argument for big-bang: very small implementations (under 30 users) where the interdependencies between modules make phased rollout awkward.