It is the first Monday after go-live. The ERP migration finished on schedule over the weekend, the cutover checklist is green, and the project team is collecting well-earned congratulations. In the planning office, the first file two planners open is the one they opened every Monday on the old system: the shortage list.
The new system has proposed purchase orders from safety stocks and lot sizes copied across exactly as they were. Some of those values were set years ago, by people who have since left, for products that no longer sell the way they did.
An ERP migration carries planning parameters, workarounds and habits across unchanged unless the business decides, before go-live, which of them to keep and who will own them afterwards.
The 2027 deadline turns a business change into a technical project
For many manufacturers the trigger is a date. Mainstream maintenance for SAP’s Business Suite 7 core applications, ECC included, ends at the close of 2027, with optional extended maintenance running to the end of 2030. Companies on other ERP platforms face similar pressure from cloud migrations and end-of-life releases.
Under deadline pressure, scope gets defined in technical terms: data, interfaces, reports, cutover. “Like-for-like” becomes the safest phrase in the programme, because it promises that nothing will break.
The pattern is not new. BCG’s 2026 research on supply chain planning found that process redesign and operating-model change frequently lag behind system deployment, so companies with modern tools in place often fail to see the expected benefits.
Like-for-like migrates policies nobody remembers making
Planning parameters look like technical settings. They are business decisions in disguise. A safety stock is a choice between service and cash. A lot size is a choice between unit cost and inventory. A planned lead time decides what the company promises customers and how early it commits money to suppliers.
A typical ERP holds thousands of these values across reorder points, planning horizons and frozen zones. Copying them like-for-like silently re-approves every one of those decisions, without anyone looking at them again.
In my years in supply chain, I rarely met a parameter set that anyone could fully explain. Most values were the residue of an old shortage, an audit finding or a customer complaint that everyone had long forgotten. The system remembered; the organisation did not.
The spreadsheet next to the ERP is your real planning process
Every planning team runs something beside the system: a shortage list, an expediting tracker, a file of manual overrides. Each exists because some part of the system’s parameters or data cannot be trusted. Together they are the most honest description of how planning actually works, far more honest than the process maps.
That gap between the documented and the lived process is the same one behind procedures that are not processes. A migration is the rare moment when it can be closed on purpose.
Before go-live, make an inventory of these files. For each one, ask what it compensates for, then decide: fix the cause in the new system, keep the file formally with an owner, or retire it. Skip that step and the spreadsheets migrate too, unofficially, on the first Monday.
Parameters need an owner after cutover, not just during it
During the programme, the project team owns the parameters. After hypercare ends, nobody does. The project team moves on, the key users return to their day jobs, and the values start ageing again from the day the system goes live.
Three things prevent that. Each family of parameters needs a named business owner, a process owner rather than a key user. Each needs a review rhythm, more often for fast-moving products than for stable ones. And there has to be a rule for who may change which values, with a record of why. Key users matter, but key users alone are not enough to govern a system across sites.
The parameters encode the trade-offs S&OP should be making
Service against cash, cost against flexibility: these are the same trade-offs an S&OP meeting argues about every month. When the parameters are set during configuration by a project team, the S&OP meeting ends up debating decisions the system made long ago.
The migration is a chance to reconnect the two. The S&OP forum agrees the policy, such as service targets by customer segment and an inventory budget. The parameters implement that policy. A regular review checks that they still match. The ERP then executes decisions the business has actually made.
A new system will run your old decisions perfectly. The migration is the only time anyone will ask whether they are still yours.