ERP implementation timeline for a small or mid-sized business: phases and realistic durations

A small business moving from an accounting package to a cloud business-management suite can often go live in roughly two to four months; a mid-sized, multi-entity business moving to a mid-market ERP commonly needs six to twelve months or more. These are illustrative ranges, not benchmarks: the real duration depends on scope, data quality, integrations, partner capacity and, above all, how much time your own staff can give. This guide sets out the phases, what has to be decided in each, the Australian calendar dates to plan around, and how delay turns into cost.

This guide is part of the ERP selection checklist series.

Illustrative durations by project type

Treat these as starting points for questions to your partner, not as targets.

The phases and what you must decide

1. Mobilise (1–3 weeks). Confirm the project team, governance, plan and tools. Decide who signs off designs and who can approve change requests.

2. Discovery and design (2–8 weeks). Workshops by process. Decisions: chart of accounts, tax codes, entity structure, approval rules, item and customer coding, reports, what history to migrate. Slow decisions here are the single biggest cause of slippage.

3. Build and configure (4–12 weeks). The partner configures, builds integrations and reports. You prepare and cleanse data.

4. Data migration trial loads (in parallel, 2–6 weeks). Usually two or three trial loads with reconciliation of balances, stock and open items.

5. Testing (2–6 weeks). System testing by the partner, then user acceptance testing by your staff using real scenarios, including a pay run with STP Phase 2 reporting and super paid under Payday Super, and a BAS.

6. Training (1–3 weeks). Role-based training as close to go-live as possible.

7. Cutover and go-live (1–2 weeks). Final data load, opening balances, stocktake, switch-over.

8. Hypercare (4–8 weeks). Extra support through the first month-end and first BAS.

Australian calendar dates to plan around

• End of financial year (30 June) and the weeks after it: finance teams are busy with year-end, STP finalisation (generally due by 14 July) and tax work. A 1 July go-live gives a clean financial year but competes with year-end workload; many businesses prefer another month or quarter start.
• BAS due dates: avoid go-live in the weeks around a quarterly BAS lodgment, or at least plan for the first BAS from the new system.
• Christmas and January: many partners and customers run reduced staff; seasonal retailers and wholesalers are at peak.
• Payroll cycles: go-live of payroll is easiest at the start of a pay period, with super payment set-up tested beforehand under Payday Super timing.
• Stocktake timing for inventory businesses.
• State public holidays and school holidays, which affect staff availability differently in each state.

How delay becomes cost

Delay costs money even on a fixed-price contract:

• Partner time: change requests and extended project management at day rates.
• Double running: paying for the new subscription while still paying for the old system.
• Internal backfill: temporary staff covering the project owner for longer.
• Deferred savings: every month late is a month without the benefits.

Illustrative example: a three-month delay on a project where the new subscription ($4,265 a month) started at signing, the old system costs $1,500 a month, a temporary backfill costs $15,000 a month, and expected net savings are $3,170 a month:

• Extra subscription paid before benefits: 3 × $4,265 = $12,795
• Old system kept longer: 3 × $1,500 = $4,500
• Backfill: 3 × $15,000 = $45,000
• Savings deferred: 3 × $3,170 = $9,510
• Total cost of delay: about $71,800, before any partner change requests.

That is why the payback calculation should be re-run when a go-live date moves; enter the extra cost in the payback calculator.

Keeping the timeline realistic

• Get the partner's plan by phase, with named resources and dependencies.
• Ask reference customers how long their project actually took versus plan.
• Release your project owner from part of their day job, in writing.
• Freeze scope for phase one; log new requests for phase two.
• Plan data cleansing to start in week one, not after configuration.
• Ask for licence ramp-up so you pay fewer licences until go-live; see pricing models.
• Set go/no-go criteria for go-live: reconciled balances, a passed test pay run, trained users.

If a project starts to slip badly, read budget overruns and how to control them and compare the costs using the quote comparison guide.

Frequently asked questions

Can we go live faster by skipping testing?

You can, but untested payroll, tax or stock processes are expensive to fix after go-live. Shorten scope rather than testing.

Should we run the old and new systems in parallel?

Full parallel running doubles workload. Many projects run a parallel pay run and one month's reconciliation rather than full parallel operation.

Is a big-bang go-live or phased go-live better?

For small businesses with one entity, a single go-live is common. For multi-entity or multi-site businesses, phasing by entity or module can reduce risk but lengthens the overall timeline.

What is hypercare?

A period after go-live when the partner provides extra support, often through the first month-end. Check how long it lasts and whether it is in the quote.

Sources

• Australian Taxation Office — STP finalisation, BAS due dates and Payday Super timing
• business.gov.au — key business dates and planning tools
• Fair Work Ombudsman — pay period and record-keeping obligations