How to plan an ERP or IT system implementation: phases and milestones

The phases of an ERP implementation

Vendors and integrators name the phases differently, but almost every method covers the same ground:

1. Prepare. Confirm scope, budget, sponsor, team and governance. Agree which processes and sites are in the first release.
2. Design (fit-gap). Walk each business process through the standard system and record where it fits, where you change the process, and where you need configuration or custom work.
3. Build. Configure the system, build the agreed extensions, reports, forms and integrations.
4. Data migration. Clean legacy data, map it to the new structures and run several trial loads (often called mock loads) before the real one.
5. Testing. Unit tests, system integration testing (SIT) across processes and interfaces, then user acceptance testing (UAT) by the business.
6. Training and cutover. Train users by role, freeze the legacy system, load final balances and switch over.
7. Go-live and hypercare. A period of close support after go-live, then handover to normal support and project closure.

The same structure works for a CRM, an HR system or any large IT rollout. Only the names of the data objects change.

Milestones and exit criteria (template)

A milestone is only useful if everyone agrees what "done" means. Copy this table into your plan and adapt the criteria.

Milestone	Exit criteria	Signed off by
Project charter approved	Scope, budget, sponsor, team and governance agreed	Sponsor
Design signed off	Fit-gap complete; every gap has a decision; integration list agreed	Process owners
Build complete	All configuration and extensions unit tested	Project manager
Mock load 2 passed	Data loads complete, reconciled to legacy totals, error list below the agreed threshold	Data owner
SIT passed	End-to-end processes and interfaces run without critical defects	Test lead
UAT signed off	Business users accept each process; open defects have workarounds	Process owners
Go / no-go	Users trained, cutover rehearsed, support ready, rollback plan agreed	Steering committee
Go-live	Final data loaded and reconciled; first transactions posted	Sponsor
Hypercare exit	Ticket volume stable; first period close done in the new system	Sponsor and support lead

Worked example: building the timeline

Take an example first release with these estimates (yours will differ):

Phase	Duration	Depends on
Prepare	4 weeks	Start
Design	8 weeks	Prepare (FS)
Build	12 weeks	Design (FS)
Data migration (mock loads)	14 weeks	Build (SS + 4 weeks)
Testing (SIT and UAT)	8 weeks	Build (FS) and migration mock load 2
Training and cutover	4 weeks	Testing (FS)
Hypercare	6 weeks	Go-live (FS)

The main chain is Prepare, Design, Build, Testing, Cutover: 4 + 8 + 12 + 8 + 4 = 36 weeks to go-live, then 6 weeks of hypercare, so 42 weeks in total.

Now check migration. It starts 4 weeks after build starts, which is week 12 + 4 = week 16, and runs 14 weeks, ending in week 30. Testing starts when build ends, at week 24, and needs realistic data from mock load 2. If that mock load is planned for week 26, testing actually starts in week 26, not 24, and go-live moves two weeks to week 38. The dependency on data, not the build, now drives the date. This is exactly why migration belongs in the schedule as linked activities, not as a side note.

Steps to write the plan

1. Fix the scope of release one. Name the processes, legal entities and sites. Everything else goes to a later release.
2. Build a work breakdown by phase, then by process or workstream (finance, supply chain, HR, integrations, data, training).
3. Estimate with ranges. Use three-point estimates for uncertain work such as integrations and data cleansing.
4. Link the activities and find the critical path. Expect data and testing to sit on or near it.
5. Set the milestones with exit criteria from the template above, and baseline the plan.
6. Write the cutover plan as its own hour-by-hour schedule, with a rehearsal.
7. Open a risk register on day one: key-user availability, data quality, scope creep and integration readiness are common starting entries.

Roles and governance for an ERP project

A plan is only as good as the people who own its parts. Name these roles before design starts:

• Sponsor: owns the business case, chairs the steering committee and makes the go / no-go call.
• Project manager: owns the integrated plan, the critical path, the risk register and status reporting.
• Process owners: senior people from finance, supply chain, HR and other areas who sign off design and UAT for their processes.
• Key users: the people who test, train others and support colleagues after go-live. Book a fixed share of their week.
• Data owner: decides what legacy data moves, signs off each mock load and the final reconciliation.
• Integrator or vendor lead: owns configuration, build and technical cutover.

Meet as a steering committee at least once a month and at every milestone. Keep a decision log, so nobody reopens a design choice three months later without a change request.

Common mistakes in ERP project plans

• Treating data migration as a task, not a workstream. It needs owners, several trial loads and reconciliation.
• Compressing testing to protect the date. Defects found after go-live cost far more to fix than defects found in UAT.
• Assuming key users are free. The people who know the processes also run the business. Book their time in the plan.
• Too much customisation. Every gap closed with custom code adds build, test and upgrade work. Challenge each one in design.
• No go / no-go criteria. Without them, go-live becomes a date nobody dares to move, even when the system is not ready.

How to do this in Critova

Critova has an IT rollout template for smaller system projects and a project controls template for a digital or IT programme. In the controls level you can enter the phases above as activities, link them with FS and SS links and lags, mark milestones, find the critical path and save a baseline before build starts. The risk register and change requests keep scope decisions visible, and the printable status report gives the steering committee one page per update.

For uncertain durations such as data cleansing, try the three-point estimate calculator, and read the critical path method guide to check your logic. You can browse the starting structures on the templates page.