ERP Implementation Timeline: How Long It Really Takes

How long does an ERP implementation take?

A realistic ERP implementation takes 3 to 18 months from project kick-off to a stabilized go-live, and the single biggest driver of where you land inside that band is operational complexity, not headcount alone. Industry guidance reviewed in August 2026 still clusters small businesses at 3 to 6 months, mid-market companies at 4 to 12 (with many well-scoped cloud projects finishing in 4 to 9), large enterprises at 12 to 24, and multinationals at 18 to 36-plus months. Those ranges describe a reasonably well-run project, not a marketing promise.

Within the SMB band, a tightly scoped single-entity cloud rollout (finance plus inventory or CRM, clean data, almost no custom code) commonly lands in about 8 to 16 weeks. Broader SMB multi-module projects, or anything with messy masters and several integrations, stretch to the full 3 to 6 months. Mid-market manufacturing and multi-entity finance sit in the 4 to 9 month sweet spot when partners use industry templates; multi-site, multi-currency, or heavily customized programs push toward 9 to 12-plus months even before enterprise scale.

The band is wide because duration compounds: module count, legal entities and sites, currencies and countries, configure-versus-customize choices, legacy data quality, third-party integrations, and how available your own people are to decide and test. Two companies of identical headcount can sit months apart because of those levers. Treat any vendor promise of go-live under three months with skepticism for anything beyond narrow scope—sub-three-month calendars usually strip change management, training, data migration, or testing, and those missing steps show up as slow, painful stabilization after go-live.

What actually sets your ERP timeline

Headcount is a proxy for complexity, not the rule. A 300-person single-site distributor with clean data and standard processes can go live faster than a 120-person manufacturer running three legal entities across two countries. Weight estimates toward operational complexity—entities, sites, currencies, integrations, and master-data health—rather than staff count alone. Those variables move the calendar.

Scope is still the largest single lever. Finance and procurement alone is a different project from finance, inventory, supply chain, manufacturing, and CRM at once. Multiple geographies and production or distribution sites multiply the work again. Write scope down before kick-off (in-scope versus out-of-scope processes, milestone gates, change-request rules) and get every party to sign it—that is the cheapest schedule insurance you can buy.

Two levers sit on the critical path more often than executives expect: legacy data quality and system-to-system integrations. Configuration can be accelerated with templates; dirty masters and brittle interfaces cannot. Panorama Consulting’s 2025 ERP Report found data issues were the most common reason projects that overran schedule did so, and practitioners on the ground still describe rip-and-replace work as a data-migration and change-management problem first, tooling second.

Deployment model sets a floor. Cloud ERP is generally faster because there is no hardware to procure and harden. Independent comparisons put cloud roughly 30 to 40 percent faster than on-premise for comparable scope, largely by removing infrastructure lead time. On-premise still fits some regulated or data-sovereignty cases, but you must budget those weeks before configuration starts.

• →Scope and module count: more modules and sites means a longer build, test, and migration effort.
• →Customization versus configuration: configuring standard processes is fast; mirroring today’s workflows in custom code blows the schedule and creates technical debt. “We’re different” is often the most expensive sentence on an ERP project.
• →Data quality (critical path): dirty, fragmented, or duplicated legacy data turns migration into open-ended cleanup and is the top reported cause of schedule overruns among late projects.
• →Integrations (critical path): each CRM, e-commerce, payroll, banking, WMS, or EDI connection adds design, build, end-to-end test, and cutover risk that must fit the window.
• →Change management and people: unavailable sponsors, part-time SMEs, and undertrained users stall decisions and UAT even when the build is on track.
• →Resource availability: a full-time internal team plus a partner with committed capacity moves faster than a part-time team and overbooked consultants.

How long each ERP phase actually takes

Most ERP projects move through the same six phases: discovery and planning, design and configuration, development and build, data migration, testing (including user acceptance testing), and deployment with training and cutover, followed by post-go-live hypercare. The industry-standard six-phase lifecycle is the structure behind most vendor and partner methodologies, and it maps cleanly onto how SME-focused implementations are actually run.

Here is the part most timelines get wrong: these phases overlap in practice. Data migration usually runs in parallel with configuration, and testing starts while modules are still being finished. That means the per-phase durations below add up to more than the calendar timeline, because two or three phases are often consuming effort at the same time. Read the table as where your team's hours go, not as a strict sequence.

Two phases concentrate most of the schedule risk: configuration and UAT. Configuration slips when requirements were not nailed down in discovery, so the build keeps changing underneath it. UAT slips when testing surfaces gaps that trigger rework, which is why a strong discovery phase is the cheapest schedule insurance you can buy. Hypercare is not optional padding; it is the period where your team learns to run the business on the new system, and cutting it short is a leading cause of post-go-live pain.

Critical path: data cleansing and integrations

On most mid-market calendars the longest uncompressible path is not “configure the GL.” It is cleanse and load master data while integrations are designed, built, and proven end to end. If either stream slips, cutover slips—configuration and training can often absorb a week or two of float; data reconciliation and interface defects usually cannot.

Start data work in discovery, not two weeks before UAT. Profile customers, vendors, items, open AR/AP, inventory balances, and chart-of-accounts structure early. Decide what history you will carry (often open items plus current balances, not every decade of transactions). Redesign the chart of accounts before migration when the old structure will not support the reports you need—finance teams that migrate a broken COA can spend months after go-live fixing reports that should have been fixed in design. Plan at least two full migration rehearsals with reconciliation checklists before the production cutover weekend.

Treat every integration as a mini-project with its own design, sandbox, test data, and cutover owner. CRM, e-commerce, payroll, banking, EDI, WMS, and tax engines each need contract tests for happy path and failure modes. Prefer standard connectors and iPaaS patterns over one-off custom APIs when the business case is ordinary. Limit “must keep” legacy connections: each integration you refuse to retire is calendar time you are choosing to spend. Connection problems between systems—not greenfield module setup—are what practitioners still flag as the real timeline risk in 2025–2026 rollouts.

• →Data critical path: profile → cleanse → map → trial load → reconcile → production cutover load, with named owners for each master.
• →Integration critical path: inventory interfaces early, design contracts, build, unit and end-to-end tests, failure handling, cutover sequence, and post-go-live monitoring.
• →Float exists in training material polish and non-blocking reports; float rarely exists in first-close numbers and order-to-cash interfaces.
• →If data and integrations are yellow on the status report, the go-live date is yellow—even if configuration is green.

Sample 9-month mid-market ERP Gantt (month by month)

The table below is a defensible calendar for a mid-market cloud ERP program: single primary legal entity, two sites, finance, inventory, procurement, and light manufacturing, three to five integrations, industry template as the starting point, and a dedicated core team. It is not a promise for multi-country or heavily customized programs—those need 12 months or more. Read it as a Gantt compressed into months: shaded “active” workstreams run in parallel, which is why phase totals exceed nine months if you add them as a pure sequence.

Use this as a planning skeleton. Shift cutover away from year-end close, peak season, and major holidays. Keep UAT and the final migration rehearsal on the critical path with explicit exit criteria. If discovery exposes dirty masters or an integration you did not budget, re-baseline before you burn configuration weeks on a date that no longer holds.

Buffer policy: UAT defects and holiday freezes

Contingency works when it is explicit, owned, and placed where slip actually happens—not as a vague “10 percent on the whole plan.” Seasoned planners put the largest buffers on configuration late changes and UAT defect cycles, keep a hard freeze window before cutover, and refuse go-lives that land in known freeze zones (major holidays, peak shipping, year-end close) unless the business consciously accepts dual-system pain.

A practical mid-market buffer policy: hold 15 to 25 percent contingency on the combined configuration-plus-UAT window (for a 14-week config+UAT block, that is roughly 2 to 3.5 weeks of reserve). Consume buffer only through change control when a defect or scope item is accepted. Do not raid hypercare to pay for unfinished UAT. Add a separate 1 to 2 week calendar reserve immediately before cutover for final migration issues—this is not UAT time; it is cutover float.

Institute a change freeze: after UAT exit (or a fixed number of calendar days before go-live, whichever is earlier), only severity-1 defect fixes and cutover-critical configuration changes are allowed. Everything else goes to a post-hypercare backlog. Holiday and peak freezes should be written into the charter at kick-off so leadership cannot “just squeeze go-live into December” without acknowledging the risk. If a hard external date forces a bad window, cut scope or phase the rollout—do not silently remove testing.

• →Place buffer on config rework and UAT cycles (about 15–25% of those phases combined), not as a flat pad on discovery alone.
• →Keep a separate 1–2 week pre-cutover float for final load and interface issues.
• →Change freeze after UAT exit: Sev-1 and cutover-critical only; everything else waits.
• →Blackout windows: major holidays, peak season, and fiscal year-end close unless explicitly risk-accepted in writing.
• →Never fund schedule recovery by deleting training, second migration rehearsal, or hypercare.

How the timeline shifts by ERP platform

Different ERP platforms carry genuinely different implementation profiles. The platform sets the floor; your scope sets the ceiling. Cloud-native, pre-configured systems aimed at smaller companies go live fastest; deeply configurable enterprise suites take the longest. Ranges below describe a typical mid-sized deployment of each product as of guidance reviewed in 2026—your calendar moves with entities, integrations, and custom code.

Finance-first cloud systems for SMB finance teams can go live in two to four months. NetSuite commonly runs three to six months for standard multi-entity mid-market scope (SuiteSuccess templates help when you stay near standard). Acumatica often sits around three to nine months for distribution and manufacturing. Microsoft Dynamics 365 Business Central typically lands at three to nine months for US SMBs (partners often quote 3–4 months for small, clean deployments and 6–9 for multi-entity or manufacturing-heavy ones). Dynamics 365 Finance and Supply Chain (Finance and Operations) still runs roughly nine to eighteen months for mid-to-large scope; enterprise Finance + SCM programs frequently need 12 to 24 months.

At the enterprise end, SAP S/4HANA greenfield or complex multi-country programs still run twelve to thirty-six months. Mid-sized brownfield ECC-to-S/4 conversions are often planned at nine to fifteen months minimum before slippage—Explore and assess, preparation and data housekeeping, convert and adapt with custom-code remediation, testing, then go-live and stabilize. Oracle Fusion Cloud ERP commonly lands eighteen to thirty-six months for large multi-entity programs. Modular platforms such as Odoo can go live quickly for tight scope, but the calendar still scales with modules, sites, and integrations. Matching platform to scale remains one of the earliest timeline decisions you make.

How rollout strategy changes the timeline

Rollout strategy changes both calendar length and risk shape. A big-bang go-live—every module and site on one cutover—produces the shortest overall project timeline because there is one transition and no long dual-system period. The trade-off is concentrated risk: every defect lands on the same weekend, and recovery is expensive if finance or order-to-cash breaks.

A phased rollout (module by module or site by site) lowers blast radius and delivers earlier value, but extends the overall calendar because each wave needs its own test and cutover cycle, and you may run legacy and new systems in parallel between waves. A pilot-first pattern sits between them: one plant, legal entity, or country goes live first, hypercare proves the model, then you clone the template. Pilot calendars look longer end-to-end than a clean big-bang, but the first production value arrives earlier than a full multi-site wait, and later waves usually shrink because playbooks already exist.

Most modern SMB and mid-market programs favor phased or pilot-then-roll approaches because risk reduction is worth the extra weeks. If a fixed external date is non-negotiable, phase highest-value scope first rather than deleting UAT to hit big-bang. Timeline rule of thumb: big-bang optimizes total calendar if everything is ready; pilot and phase optimize time-to-first-value and survival probability. Detailed cutover mechanics live in the companion ERP go-live checklist; this page owns how those choices consume months.

The time everyone forgets: selection and procurement

The published implementation timeline almost always starts at project kick-off, but the clock for the buyer starts weeks earlier. Before configuration begins, most organizations run a structured selection process: researching and shortlisting vendors, holding introduction calls, requesting preliminary budget letters, narrowing to a shortlist, running scripted demos, checking references, and negotiating a contract. For a small or midsize business that process typically adds roughly two to three months before a deposit is paid and a kick-off is scheduled.

That pre-project time is real calendar time, and it should be in your plan, not discovered after the fact. If the business needs the new system live before a busy season or a fiscal year-end, the selection window has to be counted backward from that date alongside the implementation itself. Compressing selection to save time is a false economy: choosing the wrong system at the outset is one of the most reliable ways to make the implementation slower and more likely to fail.

A practical approach is to set a desired go-live date, then work backward through both the implementation phases and the selection steps, with explicit timeframes for each. That single backward-planning exercise is what separates a timeline you can defend from one that keeps slipping because somebody forgot that demos, reference checks, and contract negotiation each take their own weeks.

• →Selection research and shortlisting: roughly two weeks to identify five to ten candidate vendors.
• →Introduction calls and preliminary budget letters: around two weeks each, to qualify fit and ballpark cost.
• →Shortlisting, scripted demos, and reference checks: roughly three to four weeks to reach a final decision.
• →Contract negotiation and deposit: one to three weeks, depending on complexity, before kick-off can be scheduled.

Why ERP timelines slip

Schedule overruns are the norm, not the exception. Industry research still finds that a majority of ERP programs run longer than planned; widely cited figures put roughly two-thirds of implementations over original timeline and budget, and broader failure-to-meet-objectives rates near 70 percent appear in 2025 analyses. The upper end of every size band in this guide is therefore common rather than unusual—planning only to the optimistic floor is how six-month replatforms become multi-year dual-system sagas.

Among projects that do overrun, data issues are repeatedly named as the leading technical cause—duplicate masters, incomplete open items, and chart-of-accounts structures that cannot support the new reporting model. Late scope changes force rework where it is most expensive. Undocumented processes surface in configuration or UAT and get designed on the fly. Integration surprises (a legacy API that does not match its docs, an EDI partner that will not test until cutover week) stack onto the same critical path.

People and change problems cost as much calendar time as technical ones—and often more. Change management remains a primary failure mode: users who do not trust migrated data keep the old system open, work around the new one, and freeze adoption. Unavailable sponsors and SMEs stall decisions; part-time project teams delay UAT; overbooked partner consultants leave work waiting. High-profile public failures (for example municipal payroll and HR cutovers that produced months of pay discrepancies) almost always show the same pattern after the fact: rushed testing, weak data validation, and change readiness treated as optional. Under-investing in discovery, data, integrations, and dedicated people is still how calendars die.

• →Data quality and migration rework (most common overrun driver in recent industry reports).
• →Scope creep and “we’re different” customizations after the baseline is locked.
• →Integration defects discovered late (interfaces not on the early critical path).
• →Change management gaps: low trust in data, parallel shadow systems, weak training.
• →Resource contention: part-time SMEs, missing sponsors, overbooked consultants.
• →Forced go-lives in holiday, peak, or year-end windows without scope cuts.

How to estimate your own ERP timeline

A defensible timeline is built backward from a target and checked forward against complexity and critical path. Start with the business outcome that anchors the project—a fiscal year-end, a contract renewal, a season you must avoid—and set a desired go-live date. Then work backward through selection (if not already under contract), the six implementation phases, and a realistic hypercare period, using the per-phase ranges and the sample 9-month mid-market Gantt as skeletons.

Pressure-test the draft against complexity levers and the two critical-path streams. Count legal entities, sites, currencies, modules, and third-party integrations. Score master-data health honestly (duplicates, orphaned records, COA fitness). A single-entity finance and inventory rollout sits at the fast end of every phase; multi-site manufacturing with brittle EDI sits at the slow end. If data and integrations need more weeks than configuration, the calendar follows data and integrations—not the other way around.

Apply an explicit buffer policy (15–25% on config+UAT, plus pre-cutover float) and blackout windows from the contingency section above. Treat the plan as living: re-baseline after discovery and after every major gate. Hold a weekly cadence between business leaders and the delivery team so slipping dates cannot hide until the week of cutover.

1. 01
   Set the anchor date

   Choose go-live from a real business driver, then count backward through selection and delivery. Reject anchors that force holiday or year-end cutovers without a written risk acceptance.

2. 02
   Map phases and critical path

   Walk back through discovery, design, build, migration, UAT, training, cutover, and hypercare. Overlay data cleansing and integration tracks so they start early enough to finish before UAT exit.

3. 03
   Score complexity and data health

   Count entities, sites, currencies, modules, and integrations. Rate master data. Move each phase toward the slow end of its range for every extra lever you carry.

4. 04
   Add buffer, freeze, and blackouts

   Apply the UAT and pre-cutover buffer policy, lock a change freeze, and steer clear of peak and holiday windows. Re-baseline after every milestone gate.

How to compress the timeline honestly

You can shorten an ERP implementation without cutting the steps that protect go-live, but only by attacking levers that actually drive duration. The fastest wins: narrow scope, configure instead of customize, start data and integrations on day one, phase or pilot the rollout, and staff a dedicated team. Limiting scope or sequencing waves is the single most effective move and de-risks go-live.

Configuration over heavy customization matters more than almost anything for the calendar. Pre-built industry processes fit most needs; adapting your workflows to the software is faster and avoids upgrade debt. Reserve customization for genuine competitive advantage—not for “we’re different” resistance. On the critical path, every hour spent cleansing masters before migration and proving interfaces in sandbox saves multiple hours in UAT and hypercare.

Resource discipline and committed partner capacity close the rest of the gap. Full-time internal members, empowered super-users, an available sponsor, and a partner who is not overbooked move faster than a part-time team waiting on decisions. Flectic runs ERP delivery with AI-assisted documentation, test generation, and migration tooling inside the manual-heavy steps, designed to deliver up to three times faster than a traditional implementation while expert consultants stay accountable for quality. That is a delivery target supported by reusable accelerators—not a license to skip discovery, UAT, or hypercare. When evaluating ERP implementation services, ask how a partner accelerates without removing those steps.

• →Narrow scope, phase, or pilot: deliver highest-value modules first; accept a longer total calendar for lower risk when needed.
• →Configure, do not customize: standard features first; reserve custom code for real competitive advantage.
• →Pull data cleansing and integrations onto the early critical path; run trial loads before UAT, not during it.
• →Commit a dedicated team: full-time internals, super-users, engaged sponsor.
• →Pick a partner with committed capacity and accelerators, not the cheapest overbooked bench.
• →Quiet go-live window, explicit buffer policy, and a hard change freeze before cutover.

A worked SME timeline and what your plan must contain

To make this concrete, use the sample 9-month mid-market Gantt above as the default skeleton for a manufacturer (or distributor) going live on cloud ERP with finance, inventory, procurement, and light manufacturing across a single entity and two sites, plus three to five integrations. A defensible end-to-end plan runs roughly seven to nine months from kick-off to stable go-live, preceded by about two to three months of selection when the vendor is not already chosen. Map discovery to month 1, design and early cleanse to month 2, configuration and trial loads through months 3–5, UAT and rehearsal through months 6–7, cutover in month 8, and hypercare into month 9-plus.

Whatever your size, every timeline plan worth defending contains the same elements: signed scope with explicit out-of-scope items and change control; a phase schedule with named owners and dependencies; a data migration strategy with at least two rehearsal dates; an integration inventory with test contracts; UAT exit criteria; role-based training; a cutover approach with go/no-go gates; an explicit buffer and freeze policy; and hypercare metrics. For cutover runbooks and mock rehearsals, use the companion ERP go-live checklist.

The discipline that ties it together is a weekly cadence. If business leaders and the implementation team are not reviewing progress, critical-path status (data and integrations), and blockers together at least weekly, the timeline drifts silently until a missed date becomes obvious. A timeline is a management instrument, not a document you write once and file away.

• →Signed scope, out-of-scope list, and change-control rule.
• →Phase schedule with owners, dependencies, and the sample Gantt as a starting skeleton.
• →Data migration strategy with rehearsal dates and reconciliation thresholds.
• →Integration inventory with contract tests and cutover sequence.
• →UAT exit criteria, change freeze, buffer policy, and blackout windows.
• →Role-based training, go/no-go gates, and hypercare exit metrics.

Frequently asked questions