Quick Summary
Most ERP implementation projects take between six months and two years, with duration driven more by scope than by company size. Small, single-entity businesses often go live in under six months, while large multi-entity groups can need eighteen months or more.
- Build a phase-by-phase timeline with a named owner and decision gate for every row.
- Identify the critical path early and manage those tasks daily, since they control the go-live date.
- Allow for at least three trial data migrations plus business-led data cleansing.
- Hold a contingency buffer centrally, sized against a documented risk register.
- Route every change request through a single decision forum and record each outcome.
Table of Contents
- Typical ERP Implementation Durations by Business Size
- Step 1: Build a Realistic Sample Timeline Phase by Phase
- Step 2: Estimate the Timeline for Your Specific Project
- Step 3: Plan for Data Migration and Set Its Timeline
- Step 4: Apply Best Practices to Protect Your Schedule
- Booking Your Timeline Review With Quinn Consulting
- Frequently Asked Questions
Typical ERP Implementation Durations by Business Size
Last Updated: November 4, 2026
Most ERP implementations take somewhere between six months and two years, but the spread is wide and the size of the business is only part of the story. A small manufacturer running one site and a few core modules can often go live in under six months, while a large group with several entities, multiple currencies and a legacy finance system can need eighteen months or more. Duration tends to follow scope more than headcount alone.
Small businesses with simple, single-entity requirements usually sit at the short end. Larger organisations with multiple sites, heavy customisation or regulated reporting typically need longer. These are planning ranges, not promises, and they shift with how many business units, locations and integrations are involved.
Treat any single figure with caution. Many businesses find that their estimate is driven less by the software and more by how quickly decisions get made and how clean the existing data is.
Step 1: Build a Realistic Sample Timeline Phase by Phase
The most useful starting point is a phase-by-phase sample timeline with explicit assumptions attached. Without assumptions, a duration is just a guess. The table below is a worked example for a mid-sized organisation: two legal entities, one currency, four core modules (finance, procurement, inventory and reporting), three third-party integrations, standard cloud deployment and subject-matter experts available two days a week. Treat it as a planning skeleton, not a benchmark.
| Phase | Typical duration | Accountable owner | Key dependency | Decision gate |
|---|---|---|---|---|
| Mobilisation and project charter | 2-3 weeks | Programme sponsor | Steering group formed; budget released | Charter and governance signed off |
| Requirements and process design | 4-8 weeks | Business process owners | Subject-matter experts available; current-state process maps complete | Future-state design signed off; scope frozen |
| Configuration and build | 8-16 weeks | Implementation lead | Design sign-off; environments provisioned | Core configuration complete; change requests logged |
| Integrations | 6-12 weeks, overlapping build | Technical lead | Interface specifications agreed with third parties | Each interface tested end-to-end |
| Data migration | 6-12 weeks, overlapping build and test | Data owner (business side) | Source data audited; cleansing resources assigned | Trial migration signed off by process owners |
| System and integration testing | 4-8 weeks | Test manager | Build and interfaces complete | Critical defects closed; test exit criteria met |
| User acceptance testing | 3-6 weeks | Business process owners | Super-users trained; test scripts ready | UAT sign-off by process owners |
| Training and cutover rehearsal | 3-5 weeks | Change manager | UAT sign-off; training materials approved | Cutover plan and rollback plan approved |
| Go-live and hypercare | 4-8 weeks | Programme sponsor | Cutover rehearsal passed; support model live | Stabilisation exit criteria met |
Read the table by dependency, not by date. Requirements cannot close until process owners have signed off the future-state design; integrations cannot be tested end-to-end until each third party has agreed its interface specification; and UAT cannot start until critical defects from system testing are closed. In practice, configuration, integration and data migration run in parallel, which is why the elapsed programme is shorter than the sum of the rows.
A common pattern is for organisations to compress requirements and testing to protect a fixed go-live date, then absorb the delay later as rework. The decision gates are the mechanism that prevents this: each gate should have a named approver and a documented exit criterion, and the programme should not proceed past a gate that has not been met.
Watch out: a sample timeline built without named owners and decision gates becomes a wish list. Assign an accountable owner to every row before the plan is baselined, and record the assumption behind each duration so the estimate can be defended when conditions change.
Step 2: Estimate the Timeline for Your Specific Project
Generic ranges only become useful once you adjust them for your own conditions. Work through these questions before committing to a date:
- How many business units, entities and locations go live, and at the same time or in waves?
- How many modules are in scope, and how many are genuinely new to your organisation?
- How many integrations must be built, and how many of those systems are poorly documented?
- How available are your subject-matter experts? Process owners with full-time day jobs can add months.
- How much customisation is required, compared with adopting standard processes?
Each answer moves your estimate up or down. A useful habit is to write the assumption beside each duration. "Twelve months, assuming two entities, one data migration cycle and subject-matter experts available two days a week" is far more defensible to a board than a single number.
Watch out: Estimates built on the vendor's standard implementation template rarely reflect your actual complexity. Use the template as a starting structure, then rebuild the durations from your own scope.
Step 3: Plan for Data Migration and Set Its Timeline
Data migration is one of the most common causes of delay, and it deserves its own timeline rather than a footnote in the build phase. Start with a data audit to establish what exists, how clean it is and which records genuinely need to move. Then plan for several trial migrations. Most projects run at least three, each one exposing new quality issues that must be fixed at source.
Allow time for data cleansing by the business, not just the project team, because only process owners can confirm which customer, supplier and product records are still valid. Data migration can add a meaningful period on top of the core build, and it should be scheduled with its own milestones and owners.
Step 4: Apply Best Practices to Protect Your Schedule
Once you have a realistic timeline, protect it with mechanisms rather than intentions. The practices below are the ones that most often separate a programme that lands close to plan from one that drifts.
Identify the critical path first. Not every task can delay go-live. Map the sequence of dependent tasks with zero float, typically requirements sign-off, configuration of core processes, integration testing, UAT and cutover, and manage those daily.
Size the buffer against identified risk. A contingency buffer should be built from a risk register: integration complexity, data quality, subject-matter expert availability and third-party responsiveness.
Govern scope through a single decision forum. Route every change request through one forum that weighs cost, schedule and benefit, and record the decision.
Track readiness, not just task completion. A task marked complete does not mean users can perform their core processes in the new system.
Phase the rollout where sensible. Deploying one business unit, region or module first can reduce risk and shorten the time to first value, but it lengthens the overall programme and adds transition overhead.
Re-baseline at each major gate. A schedule is not fixed once the go-live date is announced. Re-baseline the plan at each decision gate, and be prepared to move the date rather than compress testing to hit it.
Watch out: a buffer that is never tracked is indistinguishable from no buffer. Record when contingency is drawn down, by how much and for what reason, so the programme board can see the remaining float and make an informed decision about the go-live date.
Booking Your Timeline Review With Quinn Consulting
If your ERP timeline has already slipped, or you are about to commit to a date your board will hold you to, an independent review can test the assumptions before they become expensive. Quinn Consulting works across Oracle Cloud, SAP, Microsoft Dynamics, NetSuite and Odoo, and focuses on reset scope and governance for programmes that have stalled or gone over budget.
To discuss your timeline, get in touch with Quinn Consulting through the website. Pricing depends on the scope and stage of your programme, so request a quote for current prices.
Frequently Asked Questions
How long does a typical ERP implementation take? For a mid-sized business using a standard cloud ERP, most implementations take between six and twelve months. Simpler single-entity projects can finish sooner, while multi-site enterprises often need eighteen months or more.
What makes an ERP implementation take longer? Scope drives duration more than company size. Multiple entities, heavy customisation, many integrations and poor data quality are the most common reasons projects run long.
How much time should be allowed for data migration? Plan for at least three trial migrations and several weeks of business-led data cleansing. For a mid-sized business this often adds six to twelve weeks alongside the core build.
Should I include a buffer in my ERP timeline? Yes. A contingency of roughly 15 to 20 per cent helps absorb unplanned rework and dependency delays without compressing testing before go-live.
Frequently Asked Questions
How long does a typical ERP implementation take?
Most ERP implementations take a period that depends on business size, the number of modules, and how many legacy systems must be integrated. Smaller businesses with a single site and standard modules usually finish sooner, while mid-sized and enterprise rollouts across several locations typically take longer. Your own estimate should start from the phases in this guide and be adjusted for scope, resource availability and data readiness.
What are the main phases of an ERP implementation?
A typical ERP implementation moves through planning and requirements gathering, design and software configuration, data migration, integration with existing systems, testing including user acceptance testing, training, go-live, and post-launch support. Planning usually takes the least time but has the greatest effect on everything that follows. Testing and data work are the phases most often underestimated, so allow explicit time for them rather than squeezing them at the end.
How long does ERP data migration take?
Data migration can take a significant part of the overall schedule, and this varies widely. The work is driven by data quality rather than volume: duplicate customer records, inconsistent product codes and incomplete histories all add cycles of cleansing and validation. Plan at least three trial migrations before go-live, with reconciliation checks after each one, and treat data owners' sign-off as a milestone in its own right.
Why do ERP implementations take longer than planned?
The most common causes are scope creep from late requirement changes, underestimated data cleansing, slow decisions from stakeholders, and limited availability of internal subject matter experts. Integration with legacy or third-party systems also adds unplanned work. Building a contingency buffer into the schedule, and reviewing scope against business return at each stage gate, keeps delays visible early.
