ERP Implementation Timeline: How Long Each Phase Really Takes

Timelines in ERP proposals are often optimistic, and the reasons are understandable: buyers want short projects and partners want to win. The result is a go-live date that slips repeatedly, eroding confidence.

This article sets out realistic durations for a first-phase implementation at a small or mid-sized company — typically covering sales, purchasing, inventory and accounting, with a few integrations — and explains what makes each phase longer or shorter.

A typical first-phase timeline

From discovery to go-live, that's roughly three to nine months for most SMB first phases. Larger scopes — manufacturing, multiple countries, many integrations — take longer.

Phase-by-phase notes

Discovery: don't compress it

Shortening discovery to hit a date is the most expensive saving in ERP. Missed requirements surface later as change requests, when they cost more. Two to six weeks is enough for most SMBs if key people are available.

Design: decisions are the bottleneck

Design duration is mostly about how quickly decisions get made. A finance lead who can decide the chart of accounts structure in a week saves a month compared with one who needs board approval for every choice.

Build: iterative beats waterfall

Build in two-week cycles with demonstrations. Each cycle reduces uncertainty. If demonstrations aren't happening, you can't tell whether the project is on track.

Data migration: start in week one

Migration runs in parallel with build, but its critical path often determines go-live. Poor data can add weeks of cleansing. Starting profiling during discovery is the best protection.

Testing: budget for defects

User acceptance testing finds issues; fixing them takes time. Plan at least one round of fixes and retesting. If UAT starts late, go-live will move.

Training: close to go-live

Two to three weeks before go-live is ideal. Earlier, and people forget; later, and there's no time to practise.

Cutover: timing matters

Cutover at a month or quarter end simplifies accounting. Avoid peak seasons — the week before a major sales period is the worst possible time.

What stretches timelines

• Decision latency. Every week waiting for sign-off is a week added.
• Key user availability. Workshops cancelled because people are busy.
• Scope growth. New requirements added mid-build without moving dates.
• Data surprises. Discovering at mock migration that half the products lack costs.
• Integration dependencies. Third parties slow to provide API access or test environments.

What shortens them

• A clear, limited first-phase scope
• Fast, empowered decision-makers
• Clean master data, or cleansing started early
• Standard functionality preferred over customisation
• Experienced partner with relevant industry templates

Setting a realistic go-live date

Commit to a date only after discovery, and anchor it to a business calendar: a month end outside peak season. Then protect it by managing scope rather than squeezing testing.

If the date must slip, slip it early and once. Repeated small delays damage confidence more than a single honest reset. The implementation checklist helps spot slippage early.