How long does ERP implementation take? Phases and realistic timelines

An ERP implementation for a small business with standard processes can take a few months; a mid-sized business with inventory, manufacturing, several entities or many integrations should plan for considerably longer, often the better part of a year or more. The length depends less on the software than on scope, data quality, decision speed and the time your own staff can give the project. Plan the go-live date around your fiscal year and busy season, add time contingency, and treat the vendor's or partner's timeline as a best case until it has been tested against your own calendar.

This guide is part of the ERP selection checklist. Durations below are illustrative planning ranges, not industry statistics.

The phases

Phase	What happens	Illustrative duration, small business	Illustrative duration, mid-sized business
Selection	Requirements, shortlist, demos, references, contract	4–8 weeks	2–4 months
Discovery and design	Workshops, fit-gap, solution design	2–4 weeks	1–3 months
Configuration and build	Settings, workflows, reports, integrations	4–8 weeks	2–5 months
Data migration	Cleaning, mapping, test loads	Overlaps with build	Overlaps with build, often the critical path
Testing	Integrated and user-acceptance testing	2–4 weeks	1–2 months
Training	Role-based sessions	1–2 weeks	3–6 weeks
Cut-over and go-live	Final data load, opening balances	A weekend to a week	1–2 weeks
Hypercare	Extra support, first month-end close	4 weeks	1–3 months

What makes projects longer

Unclear requirements: decisions revisited during build.
Poor data quality: duplicate customers and items, inconsistent units, missing costs. See data migration mistakes.
Customisation: every custom feature needs design, build, test and future maintenance.
Integrations: each connection depends on another vendor's cooperation and timetable.
Staff availability: key users doing their day job and the project at the same time.
Multi-entity and Quebec specifics: separate legal entities, intercompany flows, bilingual documents, QST and Quebec payroll hand-offs need design time.
Slow decisions: workshops that end without an owner signing off.

What makes projects shorter

Adopting the system's standard processes wherever possible.
A phased scope: core financials and inventory first, advanced planning later.
A dedicated internal project lead with authority to decide.
Data cleaning started before the partner arrives.
Limiting history migrated (for example, open items and summarised balances rather than every past transaction).

Choosing the go-live date

Common choices are the start of a fiscal year (clean opening balances, no mid-year conversion of the ledger) or the start of a quarter. Avoid your busy season, the weeks around year-end close and the period when your T4 and RL-1 slips are prepared (the slips for a calendar year are generally due by the end of February of the following year). If you file GST/HST quarterly, avoid going live in the weeks before a filing deadline. Consider how the old system's records will be kept accessible for CRA purposes after you switch; see CRA record-keeping and cloud ERP.

Worked example: planning backwards (illustrative)

A manufacturer with a 31 December year-end wants to go live on 1 January. Working backwards:

Hypercare runs January to February, through the first month-end and the January close.
Cut-over: a year-end inventory count on 31 December, then the final load of opening balances and open orders over the first days of January.
Training: 4 weeks in November to early December.
User-acceptance testing: 6 weeks from late September to early November.
Build and data migration: 5 months from mid-April to mid-September.
Design: 2 months from mid-February to mid-April.
Contract signature: by early February.

If signature slips to April, the plan does not fit a 1 January go-live without compressing testing, which is where problems tend to appear. A better fallback is a 1 April go-live at the start of the second quarter. Time contingency is usually cheaper than a rushed go-live.

Cost of a delay

Delays cost money in several ways: extra partner hours, subscription fees paid before you get value (many SaaS contracts start billing at signature, not go-live), the old system's licences kept longer, and staff time. Ask whether the subscription can start at a reduced rate or at a later date until go-live; some vendors will negotiate this. Use the payback calculator to see how a six-month delay in savings changes payback.

FAQ

Is a "go-live in 90 days" offer realistic?

For a small business adopting a standard configuration with clean data, possibly. For complex inventory, manufacturing or multiple entities, ask the vendor for references that achieved it.

Should we run the old and new systems in parallel?

A full parallel run doubles the workload. Many projects instead run a parallel month-end in testing or compare key reports for the first month.

Who should lead the project internally?

Someone who knows the processes well and has authority to decide, with time freed from their day job.

What if testing finds serious problems near go-live?

Move the date. A delayed go-live is usually less costly than fixing a broken month-end close in production.

Sources

Canada Revenue Agency — filing deadlines for GST/HST and T4 slips to plan around
Revenu Québec — RL-1 slips and Quebec filing deadlines
Business Development Bank of Canada (BDC) — project planning resources for technology adoption