Planning an ERP Change Without Disrupting Daily Operations

The most common question I hear at the start of an ERP project is not about software at all. It is: "How do we do this without everything grinding to a halt?" The answer has very little to do with the product you choose and almost everything to do with how you sequence the work.

Gartner research predicts that by 2027 more than 70 percent of recent ERP initiatives will fail to fully meet their original business goals. In my experience the failures rarely happen at go-live. They happen in the months before, when the plan falls apart under the weight of daily operations, and the project responds by cutting corners on testing, training and data. This article is about the planning that stops that from happening.

In this guide

1. Phase it, do not bomb it
2. Freeze periods and the calendar you cannot control
3. Parallel running versus the dress rehearsal
4. A cutover that does not break Monday
5. Sponsorship and the steering group
6. Frequently asked questions

Phase it, do not bomb it

The single biggest planning decision is whether you replace the ERP in one event or in stages. For most mid-size businesses the answer is stages, and the stages follow a rhythm:

1. Discovery (6 to 10 weeks). Map the current processes, capture the workarounds, agree the target design. The output is a requirements baseline that the whole project refers back to.
2. Design (4 to 8 weeks). Turn the baseline into configured processes. This is where the shadow IT tools you found become formal requirements, not casualties.
3. Build and configure (8 to 16 weeks). The system takes shape. Resist the urge to customise. Every configuration decision should trace back to a discovery requirement.
4. Test (6 to 10 weeks). Unit, integration, user acceptance and a dress rehearsal. The test window is the one place in the plan where the project must win arguments with the business.
5. Cutover and stabilise (4 to 8 weeks). Freeze, migrate, go live, support. Stabilisation is part of the plan, not an afterthought.

Staging also lets you deliver value before the end. Some businesses migrate finance first and leave inventory for a later wave; others go the other way. The point is that a phased plan gives the business a working system to react to, instead of one big reveal.

Freeze periods and the calendar you cannot control

Every business has a calendar it cannot move: month end, year end, the audit, the peak season, the supplier price change. The planning mistake is to treat these as background noise. They are the spine of the project plan.

Two rules I use with every client:

• Never cut over near a hard date. No go-lives in the week of year end, the annual stocktake, or the two weeks before peak season. If the calendar says no, the plan moves, not the calendar.
• Schedule a data freeze before migration. In the two to four weeks before go-live, master data changes are batched and controlled, so the final migration starts from a clean picture. Freeze periods are unpopular, which is exactly why they need to be agreed in writing months ahead.

Trade bodies such as the Institute of Directors and Make UK run the same message to their members from different angles: the businesses that plan around their operational calendar protect their trading performance, and the ones that do not spend the next quarter apologising to customers.

Parallel running versus the dress rehearsal

There is a persistent myth that a safe go-live means running the old system and the new one side by side for a month. I have seen parallel running work exactly once, in a business with a dedicated finance team who did nothing else for six weeks. I have seen it collapse many more times, because it doubles the workload at the exact moment everyone is busiest.

The better approach is the dress rehearsal:

• Take a real month of data, from a recent month you still have on file.
• Process it through the new system end to end, in the test environment, with the real users.
• Compare the outputs against what the old system produced. Every difference is either a defect to fix or a process change to confirm.
• Fix, re-run, and sign off.

The dress rehearsal gives you the confidence of parallel running at a fraction of the cost, and it produces a signed record that the new system can actually do the month. That record is worth more to the board than any number of PowerPoint updates.

A cutover that does not break Monday

Cutover is a sequence, not an event. The sequence for most mid-size businesses looks like this:

1. Friday close of business: the old system stops taking new transactions. The freeze window ends and the final data extraction runs overnight.
2. Saturday: data migration, validation, and the first set of reconciliation checks. Issues found here are fixed while the business is closed.
3. Sunday: the dress rehearsal team walks through Monday morning's critical processes: orders, invoices, stock movements, banking files.
4. Monday 8am: go live with a war room, a named support rota, and a two-week hypercare period where the project team is not allowed to be anywhere else.

The technology industry body techUK has long argued that the public sector's most successful system changes share this pattern: short cutover windows, rehearsed rollback, and hypercare. The same discipline applies at any scale. If the Monday morning order flow works, the rest of the week tends to follow.

Sponsorship and the steering group

No plan survives contact with daily operations without a sponsor who can say no. ERP projects get derailed by scope creep, and scope creep gets approved by people who cannot say no, or will not. The steering group should be small, meet monthly, and have one job: protect the scope and the calendar.

Three decisions the steering group must own from the start:

• The scope baseline. What is in, what is out, and who decides when something moves between the two.
• The change budget. A fixed allowance of days for legitimate change requests. When it is gone, requests wait for the next release.
• The stop criteria. The signs that say the project is not ready: open critical defects, unrehearsed processes, unvalidated data. If the criteria are met, go-live moves, and nobody gets to argue with the checklist.

The practical detail of running these phases, including the tasks nobody thinks to schedule, is in the migration checklist nobody talks about. If your destination is a cloud platform, moving your back office to the cloud without losing sleep shows how the phases adapt for a hosted system.

Frequently asked questions

The honest summary: an ERP change disrupts operations when the plan ignores them. Phase the work, protect the calendar, rehearse the month, and staff the war room. The business keeps trading, and the project keeps its promises.