What an ERP rollout actually looks like, month by month

Month one — process mapping, not software

Nothing gets configured in the first month. The work is sitting with each function and documenting how material, money and information actually move, including the exceptions everyone knows about and nobody has written down.

The output is a map of the current process and a shortlist of the places where it is genuinely unusual. That shortlist is what you customise. Everything else takes the standard path, because every customisation is something you maintain forever.

Month two — the data-cleaning stage nobody budgets for

Then you open the master data. There will be four spellings of the same supplier, items with units that changed meaning in 2019, opening balances that do not reconcile, and a customer list with duplicates nobody dares merge.

This is the single most underestimated phase of an ERP project. It is unglamorous, it needs people who know the business rather than the software, and it cannot be delegated to the implementation partner alone — only your team knows which of the four suppliers is real.

Budget for data cleaning as a real work item with named owners. Projects that skip it discover it later, during cutover, at the worst possible time.

Months three and four — the first module, live

Pick one module and take it all the way to production. Inventory is usually the right first choice in manufacturing and trading businesses because it is the data everything else depends on, and because the feedback loop is immediate — stock is either right or it is not.

Going live with one module early is what converts an abstract project into something the team can see. It also surfaces the integration and permissions problems while the scope is small enough to fix them cheaply.

Months five and six — parallel running

For a period, the old system and the new one both run. This is genuinely annoying — double entry, tired people — and it is also the only reliable way to prove the numbers agree before you commit.

Set an explicit exit test: the two systems must agree on stock valuation and open orders for a full cycle before the old one is retired. A date-based cutover without a reconciliation test is how businesses end up unable to invoice for a fortnight.

Months seven and eight — the remaining modules

Production, purchasing, sales and billing follow, each with the same shape: configure, migrate, parallel run, cut over. The pace picks up because the master data is now clean and the team has learned the system.

This is also when reporting gets built. Deliberately last — reports written against a schema that is still moving get rewritten, and reports written before people use the system tend to answer questions nobody actually asks.

Month nine onwards — the part that determines success

The rollout ends and the ownership begins. Someone internal has to own the system: master data standards, permissions, the queue of change requests that starts the day after go-live.

Projects that treat go-live as the finish line drift back to spreadsheets within a year, because the small gaps never get closed. Name that owner during month one, not month nine.

What makes the difference

• One module live early beats every module configured and none in production
• Data cleaning is a project phase with owners, not a task list
• Parallel running ends on a reconciliation test, never on a date
• Customise only the process that is genuinely your advantage
• An internal owner is named before the build starts