The Panorama Consulting 2026 survey of 170 organisations found 22.3% of ERP projects exceeded their planned schedule. The causes are predictable, and most of them are decided before the project starts.
Here are realistic durations and what moves them.
Why published timelines vary so much
You will see “ERP in 8 weeks” and “ERP takes 18 months” from credible-sounding sources. Both can be true, because they are describing different things.
What “8 weeks” usually means: configuring a product for a small business with standard processes, minimal data migration and no integrations. That is a real engagement and it is not what most people mean by an ERP implementation.
What “18 months” usually means: a multi-site enterprise replacing several systems, with complex integrations, substantial data history and phased rollout across departments and countries.
What is almost never included in the short figures: discovery, data migration, parallel running and training. Those four are where most of the elapsed time goes on any serious project.
How to compare quotes honestly: ask each supplier to break the duration into discovery, build, migration, testing, parallel running and training. A quote that cannot be broken down that way has not been planned, and the total is a guess.
Realistic timelines
| Project | Realistic duration |
|---|---|
| Integrations only (2–4 connections, no new core system) | 6–12 weeks |
| Operational layer over existing accounting | 8–16 weeks |
| Product implementation — Odoo or Business Central, light config | 12–24 weeks |
| Product implementation — NetSuite or SAP Business One | 24–48 weeks |
| Mid-size custom ERP | 20–36 weeks |
| Large / multi-site custom ERP | 36–72 weeks |
These include discovery, build, migration, testing, training and phased cutover. A quote showing a shorter figure is usually excluding one of those — most often training or parallel running.
Where the time actually goes
A typical 24-week mid-size project:
| Stage | Weeks | Share |
|---|---|---|
| Discovery and process mapping | 3 | 12% |
| Design and technical approach | 2 | 8% |
| Build | 9 | 38% |
| Data migration (overlapping build) | 5 | 21% |
| Testing and fixes | 3 | 12% |
| Training and phased cutover | 2 | 8% |
The build is well under half the project. People assume it is nearly all of it, which is why timelines feel wrong from the start.
Discovery, migration and training together account for more than the build. Those are also the three stages most often compressed when a deadline is imposed — and compressing them is the most reliable way to produce a late or failed project.
The five things that extend timelines
1. Integrations with systems you do not control
Adds 2–10 weeks.
A modern documented API is routine. A legacy system with no API, undocumented behaviour, or a vendor who charges for access and takes six weeks to respond is a different matter.
This is the largest single variable, and the Panorama data supports it — 54.9% of over-budget projects needed technology discovered after the start.
Reduce it: test every integration during discovery. Authenticate, pull real data, confirm the fields exist.
2. Data quality
Adds 2–8 weeks.
Covered in full here. Record count is irrelevant; quality is everything.
Reduce it: inspect a real extract before quoting, and start cleaning in the source system early — your team can do that in parallel with the build.
3. Decision latency on your side
Adds 2–8 weeks, and it is almost entirely within your control.
A project with one decision-maker moves at the speed of the build. One requiring four departments to agree moves at the speed of the slowest calendar.
Migration alone generates dozens of decisions — which duplicate is correct, how far back to migrate, what to archive. Each one waiting a week is a week.
Reduce it: name one owner with authority and allocated time. This affects duration more than any technical factor.
4. Scope growth
Adds 3–12 weeks. 51% of over-budget projects in the Panorama data.
Reduce it: write down what is out of scope, agree a priced change process before work starts, and phase delivery so additions land in the next phase rather than the current one.
5. Testing and training compression
Does not extend the project — it extends the failure.
Cutting testing moves the problems to after go-live, where they cost more and are more visible. Cutting training means people carry on using the old spreadsheet, and the project is judged a failure six months later regardless of whether the software works.
Why the build is the smallest part
Counter-intuitive and worth internalising, because it explains most of the disagreement about ERP timelines.
Writing code is the part everyone pictures, and on a 24-week project it is around nine weeks. The other fifteen are spent establishing what to build, moving the data, proving it is right, and getting people to use it.
This is why “can you just build it faster?” rarely helps. Adding engineers compresses the nine weeks and does nothing to the fifteen. Past a certain point it extends them, because more people need more coordination and more decisions from you.
It is also why discovery is not overhead. The three weeks spent mapping processes and testing integrations is what prevents the eight weeks of rework that follows discovering an integration does not work in month four. 54.9% of over-budget ERP projects needed technology discovered after the project began.
And why client availability dominates. Your team is most needed during migration decisions and parallel running — weeks 8 to 21 — not at the start. A project where the client becomes unavailable in month three stalls precisely when it is most expensive to stall.
What cannot be compressed
Four things that take the time they take.
Parallel running. The new system must run alongside the old until the numbers reconcile. Skipping it concentrates all the risk into one weekend with no fallback.
Migration rehearsals. At least three, each against a fresh extract. Rehearsal three should produce no surprises.
A month-end cycle. Many ERP systems cannot be fully validated until a complete period has been processed. If you have an immovable deadline, count backwards and include at least one full month-end inside the project.
Training delivered close to go-live. Train too early and people forget. Train at go-live and you have an outage. It takes the time it takes.
Can you go faster?
Yes, legitimately — in these ways.
Narrow phase one hard. The highest-pain area only, live and in use, before anything else starts. You get value in eight weeks instead of twenty-four, and the rest follows.
Keep your accounting package. Not migrating accounting removes the most compliance-sensitive and verification-heavy portion of the work. Often the right answer anyway.
Clean your data now, in parallel. This genuinely removes weeks and your team can start today without a supplier.
Appoint one decision-maker with real authority. Possibly the single most effective lever available to you.
Accept the product’s way of working. Every customisation adds build and test time. Standard configuration is fast; customisation is not.
What does not work: adding people to a late project, cutting testing, cutting training, or skipping parallel running. Each of these trades a visible delay for an invisible, larger one.
What your team actually has to do
The resourcing question nobody asks until it is a problem.
| Stage | Your team’s time | Who specifically |
|---|---|---|
| Discovery | 15–25 hours/week across several people | Process owners, IT contact, finance |
| Design review | 5–8 hours/week | Project owner, department heads |
| Build | 3–5 hours/week | Project owner, occasional specialists |
| Migration decisions | 10–20 hours/week | Data owner, finance, long-serving staff |
| Testing | 15–30 hours/week | The people who will use it |
| Parallel running | Double entry for the duration | Everyone operating the process |
| Training and cutover | 10–20 hours/week | Everyone |
Parallel running is the one that surprises people. For two to four weeks, staff operate both systems and reconcile the differences. That is real additional workload during normal trading, and it needs planning — temporary cover, reduced targets, or a quieter trading period chosen deliberately.
The project owner needs 20–40% of their time formally allocated, not squeezed around an existing full-time role. Projects where this is not done stall in the gaps between decisions, and those gaps do not appear in any plan.
Timeline warning signs
- A quote with no discovery stage
- Migration estimated before anyone saw your data
- No parallel running period in the plan
- A single go-live milestone rather than phased cutover
- Training occupying one line at the bottom
- A deadline driven by a licence renewal rather than the work
- No named decision-maker on your side
A realistic 24-week plan
What the weeks actually contain, so you can compare it against any plan you are shown.
| Weeks | Activity | Your involvement |
|---|---|---|
| 1–3 | Process mapping, integration testing against live systems, data extract inspection | High — interviews, access, decisions |
| 4–5 | Design, technical approach, phase boundaries agreed in writing | Medium — reviews and sign-off |
| 6–14 | Build in stages, working software at the end of each | Low–medium — stage reviews, questions |
| 8–13 | Data migration, running in parallel with build. Three rehearsals. | High — dozens of decisions |
| 15–17 | Testing, fixes, finance verification of reconciliation | Medium — your team tests it |
| 18–21 | Parallel running. Both systems live, numbers compared. | High — people run two systems |
| 22–24 | Phased cutover by department, training built into the rollout | High |
Two things people underestimate on this plan.
Parallel running is four weeks of real work for your team — they are operating two systems and reconciling the differences. It is not a passive observation period, and it needs resourcing.
Migration overlaps the build and demands most of your decision time. The weeks where your team is busiest are weeks 8–13, not the final ones.
When the date is immovable
Sometimes there is a genuine hard deadline — a lease ending, a system being decommissioned, a contractual requirement.
Count backwards and include a full month-end. Many ERP systems cannot be properly validated until one complete period has been processed. A plan that goes live two weeks before year-end with no prior cycle is a plan with a hidden failure.
Then cut scope, not stages. The negotiable thing is how much the system does at launch. The non-negotiable things are discovery, migration rehearsals, parallel running and training — those protect the date rather than threaten it.
Narrow phase one hard. One department, or one process, live and working. The rest follows after the deadline with no drama.
Be honest about what a compressed plan costs. Compressing testing moves problems past go-live where they are more expensive and more visible. Compressing training means people keep using the spreadsheet and the project is judged a failure regardless of whether the software works.
Frequently asked questions
How long does an ERP implementation take?
A custom operational layer takes 8–16 weeks. A mid-size custom ERP takes 20–36 weeks. Product implementations run 12–24 weeks for Odoo or Business Central and 24–48 weeks for NetSuite or SAP Business One. Large multi-site builds run 36–72 weeks.
Why do ERP projects take longer than quoted?
Integrations with systems nobody tested during discovery, data quality discovered late, decision latency on the client side, scope growth, and compressed testing pushing problems past go-live. The Panorama 2026 survey found 22.3% of projects exceeded their schedule.
Can an ERP be implemented in a few weeks?
A narrow operational layer or a set of integrations, yes — six to twelve weeks. A full ERP, no. A quote promising that is excluding discovery, migration, training or parallel running.
What takes the longest in an ERP project?
Not the build, which is typically under 40% of elapsed time. Discovery, data migration and training together account for more.
How can we speed it up?
Narrow phase one, keep your existing accounting package, start cleaning data now, appoint one decision-maker with authority, and accept standard configuration where you can.
Do we need parallel running?
Yes. Switching everything over in one weekend with no fallback is how a recoverable problem becomes a crisis. Parallel running until the numbers reconcile is the main defence.
What if we have a hard deadline?
Count backwards and include at least one full month-end cycle inside the project. Then narrow the scope to what genuinely fits, rather than compressing testing and training to make the plan fit the date.
Phasing: how to get value in month three
The single most effective change to any ERP timeline is to stop treating it as one delivery.
Phase one: the highest-pain area only. Not the most complete, not the most logical — the one costing you most right now. Usually stock accuracy, goods-in reconciliation, or whatever the critical spreadsheet does. Live and in use within 8–12 weeks.
Phase two: the next area, informed by what you learned using phase one. Requirements get sharper when people are using something real rather than imagining it.
Phase three onwards: the remainder, with the appetite and the budget that early value has earned.
Why this changes the project:
- Value arrives in month three, not month fourteen. That changes how the business feels about it, which changes how people engage with it.
- Scope growth lands in the next phase rather than the current one. That is the mechanism against the 51% scope-growth figure, not a promise to be disciplined.
- The risk is contained. If something goes wrong commercially, you have a working system rather than a half-finished one.
- Estimates improve. Phase two is quoted by a supplier who now knows your data and your systems rather than one who has read about them.
The objection you will hear: phasing costs more in total, because some work gets done twice at the boundaries. That is true and it is usually 10–15%. Set against a 30% chance of a budget overrun and a 22% chance of a schedule overrun, it is cheap insurance.
Written by Jas Singh, Founder. Last updated 8 October 2026.
Schedule and overrun figures from the Panorama Consulting 2026 ERP report (170 organisations, January 2025 – January 2026) as reported by secondary sources; cited as directional.
Related: ERP software development · Why ERP projects fail · ERP data migration
