ERP Implementation Timeline: A Month by Month Calendar and Critical Path

How long an ERP implementation takes, by company size and approach

Two published sources give useful planning bands. Ultra Consultants sorts projects by company size. Rand Group, in a guide updated in September 2026, sorts them by approach: a rapid activation close to standard setup, or a full transformation.

Treat these as bands, not promises. Panorama Consulting's 2023 ERP Report found a median project duration of 15.5 months, with only slightly more than half of organizations finishing within their expected schedule, as summarized by VJM Global in June 2026.

Plan at the low end of a band only if you keep standard processes, connect few systems and start with clean data. Otherwise, plan near the top.

• Small business (Ultra Consultants): 3 to 4 months.
• Midsize company (Ultra Consultants): 6 to 9 months.
• Large company (Ultra Consultants): 9 to 18 months, and 12 to 36 months for multinationals.
• Rapid activation close to standard setup (Rand Group): 6 to 12 weeks for small and midsize businesses, 6 to 18 months for enterprises.
• Full transformation (Rand Group): 3 to 12 months for small and midsize businesses, 12 to 24 months for enterprises.

ERP implementation timeline month by month: a midsize example

This calendar puts a midsize company at the top of its 6 to 9 month band: go live at the end of month 9, then three months of hypercare and stabilization before the project closes at month 12. Each month ends with one checkpoint you can verify.

Two things this calendar makes visible. Data migration runs from month 3 to month 9, in parallel with the build, not after it. And the project does not end at go live: the first month end close in the new system is the real proof.

• Month 1: scope, sponsor, project manager and key users named, baseline schedule. Checkpoint: scope and schedule signed by the sponsor.
• Month 2: process design workshops, interface list, data owners named. Checkpoint: all core processes workshopped.
• Month 3: design finished, configuration starts, first data extract. Checkpoint: design frozen, customization list closed.
• Month 4: configuration, customizations built in sprints, trial load 1. Checkpoint: trial load 1 reconciled.
• Month 5: interfaces built and unit tested, key user demos every two weeks. Checkpoint: all interfaces built.
• Month 6: configuration finished, trial load 2, integration testing starts. Checkpoint: full process demo accepted by key users.
• Month 7: integration testing, user acceptance testing starts, trial load 3. Checkpoint: final trial load with zero blocking errors.
• Month 8: user acceptance testing, end user training by role, cutover rehearsal. Checkpoint: go or no go decision recorded.
• Month 9: final data load, cutover, go live at month end. Checkpoint: system live, old system frozen.
• Month 10: hypercare with daily ticket review, first month end close. Checkpoint: first month end closed on time.
• Months 11 and 12: stabilization, handover to internal support, closure review. Checkpoint: closure report signed.

A 16 week schedule for a small business

VJM Global describes a 16 week plan for a cloud ERP in a smaller company. Its phases overlap by two weeks each, so design starts before planning ends and testing starts before configuration ends.

This fits the 3 to 4 month band from Ultra Consultants. It assumes few interfaces and little customization. Each connected system, such as an online store or a warehouse tool, adds build and test work, so add time to weeks 5 to 14 before you announce a date.

• Weeks 1 to 4: discovery and planning.
• Weeks 3 to 6: design.
• Weeks 5 to 10: configuration.
• Weeks 9 to 14: testing.
• Weeks 13 to 16: go live.
• Week 17 onward: post go live support.

ERP implementation plan timeline: the critical path

The overlaps in the calendar save months, but only if you know which tasks truly block others. These four usually sit on the critical path.

Put these four on one line of your roadmap and review them every week. If one moves, the go live date moves, whatever the other lines say.

• Design freeze: configuration and interface work depend on it. A late freeze pushes everything after it.
• Interfaces: integration testing cannot start until they exist.
• Data cleanup: user acceptance testing on fake data proves little.
• Key user availability: the same people design, test and train others.

Early signs that the calendar is slipping

Delays rarely show up first in the go live date. They show up in small signals weeks earlier, so check for these at every weekly review and act on the first one you see.

• Change requests still arrive after the design freeze.
• A trial data load is skipped or postponed.
• Key users miss workshops or test sessions.
• Test scripts are written but not run.
• Training still has no dates one month before go live.

Big bang or phased rollout: what changes on the calendar

A big bang puts everything live on one date. A phased rollout goes live by module, entity or site, one wave at a time. The choice changes the shape of the whole calendar.

In a phased rollout, draw each wave as its own row on the roadmap: design checks, data migration, testing and go live repeat for every wave. The length of each wave depends on how different the entity or site is from the pilot, so size it after the pilot, not before.

• Go live: a big bang has one date for everything, a phased rollout has one go live per wave.
• Total calendar: shorter with a big bang, longer with a phased rollout.
• Testing: longer and stricter in a big bang, with no second chance, and smaller per wave in a phased rollout.
• Extra work: a big bang needs a large cutover rehearsal, a phased rollout needs temporary interfaces between the old and new systems.
• Learning: a big bang trains everyone at once, while lessons from the first wave of a phased rollout shorten the later waves.

Questions to ask your ERP vendor or implementer about the timeline

A date in a proposal means little until you know what it includes. Ask these questions before you sign.

Write the answers into your schedule. Each one turns an assumption into a line you can track.

• What does your date include? Go live only, or hypercare and the first month end close too?
• How many hours per week do you need from our key users, and in which months?
• How many trial data loads are in the plan, and who cleans the source data?
• Which interfaces are in scope, and who builds and tests each one?
• What happens to the date if we add a customization after the design freeze?
• Where is the buffer, and in which phase?
• Who decides go or no go, and on which written criteria?
• Can you show the calendar of a similar project you delivered, with its planned and real dates?

How to build your own ERP schedule in five steps

Start from a published band, then adjust it to your own scope. Five steps are enough for a first schedule you can defend.

To present the result to leadership, a one page visual roadmap works better than a long task list. Show the phases, the critical path line and the go or no go date, and keep the detailed task schedule for the project team.

• Pick your band: use the ranges above, then place yourself low or high in it.
• Count interfaces and customizations: each one adds build and test time.
• Plan backward from a realistic go live window: stay away from year end and your peak season.
• Add a buffer: put it in testing and data migration, where delays usually appear.
• Add the end of the project: include the go or no go meeting and the stabilization months, so nobody reads go live as the finish line.