ERP implementations have a reputation for running over budget and schedule, and for delivering less than promised. That reputation is earned — but it is not inevitable. The difference between a transformational rollout and a painful one is almost always made in the planning phase, not the development phase.
This post shares the patterns that work and the traps that don't.
The scoping problem: why most ERPs fail before they start
The single biggest cause of ERP project failure is scope that grows unchecked from the moment the contract is signed. Every stakeholder has a wish list. Business analysts uncover edge cases. The "standard" module turns out not to handle the specific way your company calculates commission. By the time you're three months in, you're building a custom ERP from scratch.
Start with a process inventory, not a feature list. Document every business process that the ERP will touch — accounts payable, purchase orders, inventory movements, sales cycles, payroll. For each process, classify it as: will run in standard ERP, will require configuration, will require customization. Any customization needs a business owner who signs off on the scope and accepts the ongoing maintenance cost.
Separate must-have from want-to-have. Apply MoSCoW prioritization ruthlessly: Must have, Should have, Could have, Won't have. Phase 1 should contain only Must-haves. Everything else waits.
Define the boundaries of integration. Which external systems must the ERP talk to at go-live — CRM, e-commerce platform, logistics, payment gateway? Each integration is a mini-project with its own timeline, dependencies, and risks. Map them all before you commit to a delivery date.
Data migration: the most underestimated workload
Most project plans allocate one to two weeks for data migration. Real data migrations take two to three months and consume roughly 20-30% of total project effort. If your plan doesn't reflect this, your timeline is wrong.
Start with a data audit. Export a sample of records from every source system the ERP will replace. Audit them for completeness, consistency, and accuracy before you write a single migration script. You will find:
- Duplicate customer records
- Products with missing cost prices
- Open purchase orders referencing suppliers that no longer exist
- Inventory counts that don't match the physical count
The time to discover these is before migration, not after go-live when users are looking at corrupt data in a live system.
Three migration rules:
- Cleanse in the source, not the destination. Fix data quality issues in the source system before you migrate. Do not try to clean data mid-migration.
- Migrate in layers. Static master data (chart of accounts, products, suppliers, customers) first. Then open transactions (purchase orders, sales orders, open invoices). Then historical transactions only if business justifies it.
- Validate with the business, not just IT. Have the finance team reconcile the migrated chart of accounts. Have the warehouse team walk through a sample of inventory records. Technical validation catches format errors; business validation catches accuracy errors.
Change management: the conversation nobody wants to have
ERP implementations fail because people don't adopt the new system, not because the software doesn't work. This is uncomfortable to say in a technical context, but it is statistically true.
Name a change lead per department. This person is not a project manager. They are a respected peer in the department who advocates for the new system, collects feedback, and surfaces concerns early. They are involved in user acceptance testing and are the first call when department members have questions after go-live.
Training is not documentation. Handing users a PDF manual is not training. Role-based, hands-on training in a sandbox environment, one to two weeks before go-live, is training. Each user type needs to learn exactly the screens and workflows relevant to their job — not a comprehensive tour of the whole system.
Design for the exception, not just the rule. Train users on what to do when something goes wrong. What do they do when a purchase order can't be approved because of a budget limit? What happens when a delivery arrives with a damaged item? If users hit a wall their first week and don't know what to do, they lose confidence in the system permanently.
Go-live strategy: parallel run vs. cutover
Two approaches:
Hard cutover: On day X, you switch off the old system and go live on the new one. All data has been migrated. Clean, but high-risk.
Parallel run: For a period — typically one to two payroll or accounting cycles — you operate both the old system and the new one simultaneously, comparing outputs. More work, but de-risks the transition significantly for financial modules.
For most mid-size businesses:
- Use parallel run for core financial modules (general ledger, accounts payable/receivable, payroll).
- Use hard cutover for operational modules (inventory, sales orders, purchase orders) with a clean-slate start date.
- Migrate historical financial data for reporting, not for re-processing.
Post-go-live: the 90-day stabilization window
The work does not end at go-live. The first 90 days after go-live typically surface:
- Edge cases the testing phase missed
- Performance issues that only appear with real data volumes
- Workflow design decisions that made sense on paper but create friction in practice
- Report gaps where users need data the system can provide but isn't surfaced
Plan for a dedicated stabilization squad: two to three people with deep system knowledge available full-time for the first 30 days post-go-live, then on-call for the following 60 days. The cost of this investment is small compared to the cost of users abandoning the system because issues go unresolved.
The customization trap
Every ERP has standard processes. When your business process deviates from the standard, you have three options:
- Adapt the business process to match the standard.
- Configure the system within its supported parameters.
- Customize — write code.
Customizations are expensive to build and exponentially more expensive to maintain through upgrades. Before approving any customization, ask:
- Can the standard process serve the underlying business need, even if it's different from what we do today?
- Is this deviation truly a competitive differentiator, or is it just how we've always done it?
- What will this customization cost to maintain over three years?
In most cases, the answer is to adapt the process, not the software. The businesses that get the most value from ERP are the ones willing to standardize their operations around proven processes.
A realistic timeline for a mid-size business
For an organization of 50–200 employees implementing a full ERP (finance, procurement, inventory, sales):
| Phase | Duration | Activities |
|---|---|---|
| Discovery & scoping | 4–6 weeks | Process inventory, integration map, MoSCoW prioritization |
| Data audit | 2–3 weeks | Source data sampling, quality assessment, cleansing plan |
| Configuration & development | 8–12 weeks | Module setup, customizations (minimal), integration development |
| Data migration scripts | 4–6 weeks | Migration development, test runs, reconciliation |
| User acceptance testing | 3–4 weeks | Role-based testing, defect resolution |
| Training | 2–3 weeks | Role-based workshops in sandbox |
| Parallel run / cutover prep | 2–4 weeks | Parallel operation or final data load |
| Go-live + stabilization | 12 weeks | Hypercare support, issue resolution |
Total: 37–52 weeks. Any plan significantly shorter than this for a full ERP implementation should be examined closely.
Related: explore more under our ERP Development services or the ERP features overview.