ERP migration: fix Supply Chain planning first or after?

‍

Ask a planning team mid-ERP-migration when they will tackle forecasting and inventory, and the answer is almost always the same: after. It sounds prudent. It is the reasonable, sequenced, one-project-at-a-time answer, and it is the one IT will support.

It is also the wrong way round. The ERP migration is the strongest argument for fixing planning now, not for postponing it. During a migration your planners lose the custom reports and familiar exports they lean on, master data gets churned, and service levels are at their most fragile, all while demand carries on regardless. That is a strange moment to have no reliable answer to the question "what should stock be?".

"We will do it after the ERP" is a decision, not a delay

The phrase treats waiting as the neutral option. It is not. It is an active decision to run another 12 to 24 months on the current process, with the current stockouts and the current excess inventory, and to accept that cost as the price of tidier sequencing.

The deeper problem is that the date you are waiting for is not really a date. Panorama Consulting Group's 2026 ERP Report found that more than a quarter of organizations exceeded their project budgets, with newly discovered technology needs the leading cause, the kind of mid-project discovery that moves timelines as well as budgets. Anyone who has been through a cutover recognizes the pattern: you know when an ERP implementation starts, you rarely know when it ends.

That uncertainty compounds in a way that rarely gets discussed. In conversations with a planning manager at a mid-market industrial manufacturer, the ERP upgrade had been a live topic for roughly a decade with no end in sight, and their conclusion was blunt: the longer the planning decision slips, the less likely it ever gets approved. Elsewhere, a European retail group was still writing requirements for its future ERP, with a tender months away, which realistically put a new system two to three years out. In both cases "after the ERP" was not a sequencing choice. It was a way of never doing it.

Your ERP is a system of record. Planning is a system of decision.

Underneath the sequencing debate sits a category error. An ERP records what happened and executes transactions: orders, receipts, movements, invoices. A planning layer decides what should happen next: how much to forecast, how much buffer to hold, what to order and when. Replacing your record-keeping does not improve a single one of those decisions.

It is worth being precise about what a migration actually delivers on the planning side. In most cases it delivers the same material requirements planning (MRP) logic on a newer, cleaner database. MRP takes a single-number forecast, propagates it through fixed lead times and applies a static safety stock. A newer ERP runs that faster. It does not run it better, because the limitation is not the database, it is the assumption that demand and lead times are single numbers.

Teams who already own an ERP planning module tend to describe it the same way: it produces a plan, then requires so much manual judgement on minimum and maximum levels that the real planning tool is still the spreadsheet beside it. The honest competitive picture is not one planning vendor against another, it is an ERP plus an Excel file, which is very good at producing long lists and very poor at telling a planner which twenty lines matter today.

The three worries behind "let's wait"

The sequencing argument is rarely about strategy. It comes down to three concrete worries, and they deserve concrete answers rather than reassurance.

"We would have to build the integration twice"

This is the objection IT raises, and it assumes a planning integration resembles an ERP interface. It does not. A planning layer reads a small and stable set of tables: demand history, current stock, open and in-transit orders, and the product and supplier master data behind lead times, minimum order quantities and lot sizes. Those tables exist in every ERP, and they are the tables the migration has to reproduce anyway.

Re-pointing them at a new source is a matter of days of configuration and validation work, not a second implementation. Set against a multi-year ERP programme, it is a rounding error, and it is work you do once, at a moment you can plan for. If there is a data warehouse in the landscape, the cleaner design is to read from that instead, which decouples the planning rollout from the migration timeline entirely.

"Our master data is not ready"

This is the most legitimate of the three, and also the one most likely to become permanent. A Supply Chain lead at a large automotive supplier described the trap exactly: there is no point evaluating solutions without proper master data governance, but as long as the business is shipping and making money, nobody funds fixing it. It stays deprioritized indefinitely, including through the ERP project, whose scope is transactions rather than planning parameters.

In practice a planning layer needs far less master data than an ERP does, and it does not need it to be perfect on day one. Where a field is missing or unreliable, a lead time or an order frequency can be held and maintained in the planning tool itself rather than blocking the project. Better still, the data-mapping exercise produces exactly the list of gaps your ERP programme will need later. Starting planning first hands the migration a cleaner set of requirements.

"IT has no bandwidth"

This one is true, and pretending otherwise wastes everybody's time. The people who own the cutover are the people who own any new data feed. The answer is to sequence the integration rather than the project: begin with scheduled flat-file exports in CSV or XLSX format, which is a small ask, get planners working on real forecasts and real buffers, then move to a database connection or an application programming interface (API) after go-live and stabilization. This is a standard onboarding path rather than a workaround, and it keeps the planning project off the critical path of the migration.

‍

‍

Go-live is the moment you most want a planning layer already running

Migrations disrupt operations. That is not a criticism, it is arithmetic: you change the system of record for every transaction in the business on a single weekend. Reports break, exports change shape, and the informal tooling planners have built over years stops working on the Monday.

A planning layer that recalculates probabilistic demand, lead-time variability and buffers every day is precisely what absorbs that noise. When variability rises, buffers widen automatically, rather than waiting for a planner to notice three weeks and two stockouts later. It also gives you something valuable during testing: an independent view of what stock should be, which is how you tell a data-migration error apart from a genuine demand signal.

The wider point is that availability gains come from the decision layer, not the systems landscape. Saint-Gobain Sekurit's spare-parts distribution business did not rebuild its landscape to improve service. It put dynamic, probabilistic buffers on top of what it already had, across a network of distribution centres, and reduced inventory by 9.25% while lifting service level from 95.8% to 97.2%. Two things moved in the right direction at once, which static safety stock rules cannot do, and none of it required a new ERP.

What to decide this quarter instead of after go-live

You do not need to resolve the sequencing debate in the abstract. Three questions settle it:

First, what does a month of delay actually cost, in excess inventory and lost sales? If nobody has quantified it, the comparison being made is not "one project versus two", it is "one project versus an invisible number".

Second, can you get scheduled exports of half a dozen tables from the current system without an IT project? If yes, the bandwidth objection dissolves, because you are not asking IT for an integration during a cutover.

Third, is there a data warehouse you can read instead of the ERP? If there is, the planning project and the migration barely touch each other.

Answer those and the order stops being a matter of principle. Your planners get better decisions now, and your ERP programme gets a cleaner data specification and a stabler Supply Chain to land in.

Mid-migration and want to see what this looks like on your own data? Book a demo and we will walk through the sequencing with your current system, not a hypothetical future one.