The first 90 days of an ERP migration: where to start

When an ERP migration is discussed, the time usually goes into comparing software: which modules exist, which integrations are supported, how licensing works. Those are fair questions. But they are rarely where migrations get stuck. Things go wrong in the first three months after go-live, because the sequence was set up backwards.

Data first, process second

The most common mistake is starting with process design. Meetings are held, flows are drawn, approvals are defined — and then the system opens and week one shows that stock balances do not reconcile.

The order is the other way round. If opening balances, product cards, accounts and unit definitions are wrong, the designed process cannot run anyway. The first thirty days belong to data cleanup. It is dull work, nobody volunteers, and skipping it is paid for over the following six months.

A practical threshold: do not move to process design until the gap between a SKU’s physical count and its system balance is under two percent.

Get one module fully working

The second mistake is opening every module at once. Every department moving to a new system in the same week makes it impossible to trace the cause when something breaks — and something will break.

Picking a single module and running it end to end gets there faster. Inventory is usually a good start: its inputs are clear, its outputs are measurable, and most other modules depend on it. Once inventory is right, purchasing and production meet far less resistance.

Switch the old system off early

The third and most expensive mistake is extending the parallel run. “Let’s enter into both for a while, just to be safe” sounds reasonable. What it produces: both systems half-filled, neither trustworthy, and a team doing double data entry instead of learning the new system.

If a parallel period is needed, announce the end date up front and keep it short. Two weeks is usually enough; past a month, parallel running stops being a safety measure and becomes a habit.

Who gets trained, and when

Piling training into go-live week means most of it is lost. A better sequence: the core team two weeks before go-live, end users during go-live week, and the core team again a month after. The third session is the one that gets skipped and the one worth the most — by then the team’s questions are real questions.

What to look at on day 90

Module count is a poor measure of success at three months. Three questions work better: when an order is entered, on how many other screens is something still typed by hand; how many days does the month-end close take; and when the team needs an answer, do they open the system or somebody’s spreadsheet.

The third answer tells you most honestly whether the migration actually finished. The same question is worth asking while reviewing our solutions: which hand-kept file does this module remove?