Planning an ERP rollout that survives go-live
Why ERP projects slip
ERP projects rarely fail on the software. They slip because the people who know the processes are also the people running month-end close, and because legacy data turns out messier than anyone admitted during the sales cycle. A controller who is supposed to spend half her week on design workshops ends up spending a day, and configuration waits.
A realistic implementation plan makes those constraints visible. It shows which tasks need key users and when, where the system integrator is blocked waiting on decisions, and how much slack sits between configuration, testing and the cutover weekend. If the plan only lists modules and dates, nobody can see why a two-week delay in design pushes go-live past quarter end.
Who needs to be on the team
Name a person for each role before kickoff, and put their availability on the plan. Backfilling key users with temps or overtime budget is cheaper than a delayed go-live.
- Executive sponsor who breaks ties on scope and owns the go/no-go call
- Project manager on the client side, not only on the integrator's side
- System integrator consultants for finance, supply chain and sales
- Process owners and key users from AP, AR, procurement, inventory and order management
- Integration developer for the CRM, e-commerce store, bank feeds and payroll
- Data owner responsible for customer, vendor, item and chart-of-accounts cleanup
- Training and change lead who prepares job aids and runs end-user sessions
Reading the template: phases and the critical path
Preparation covers kickoff and governance, current process mapping and scope and future process design, 16 business days in total. Configuration and data runs module configuration (15 days) and integration development (12 days) side by side, while data cleansing starts as soon as mapping is done. The pilot data load only runs once both configuration and cleansing are finished.
The critical path goes through mapping, design, configuration, the pilot load, integrated testing and business acceptance to the final migration. Integration development has about 7 days of float, data cleansing 11 and user training 13. That float is thinner than it looks. A vendor API that is late by two weeks puts integrations on the critical path. Turn on the critical path highlight in Great Gantt and save a baseline at kickoff so you can show the steering committee exactly what moved.
Cutover planning: mock runs and the go/no-go call
The two-day final migration in the template is the visible tip of a cutover runbook that should be rehearsed at least once, ideally twice. Run a mock cutover on a copy of production during integrated testing and time every step. If the full load takes 30 hours, a single weekend is too tight.
- Master data freeze date for customers, vendors and items
- Extract of open purchase orders, sales orders and open AP/AR items
- Physical inventory count or cycle-count sign-off before the load
- Opening trial balance loaded and reconciled to the legacy ledger
- Sales tax setup checked by state nexus in the US, or VAT returns under Making Tax Digital in the UK
- Bank file and positive pay tested with the bank
- Go/no-go meeting with a written list of blocking criteria
Timing go-live around the fiscal calendar
Most finance teams prefer to go live on the first day of a fiscal period, so the opening balances come from a closed month in the old system. Going live on the first day of the fiscal year looks tidy but lands on top of year-end close and the external audit. Many companies pick the start of Q2 or Q3 instead. Retailers usually freeze system changes from October through the holidays because of Black Friday and Cyber Monday.
Add public holidays, PTO for the key users and any audit fieldwork weeks to the project calendar. If the cutover happens over a weekend, mark Saturday and Sunday as working days so the business-day count stays honest.
Mistakes that turn three months into nine
Starting configuration before the future-state design is signed off is the most expensive one, because every reopened decision means rework in the system. Close behind it are customizations approved without a business case, a UAT run by IT instead of the people who will use the system, and training delivered a month before go-live so users forget it. Finally, ending hypercare after ten days by default. Keep it open until the first month-end close in the new ERP is done.