On October 2, 2026, Bpifrance University published the replay of its course “ERP project: anticipate pitfalls and ask the right questions”. Its central message goes beyond software selection: success also depends on project organisation, internal teams and the decisions made before go-live.
One of those decisions is the rollout strategy. Should the legacy system be replaced in one cutover, should deployment proceed through business waves, or should the company begin with a pilot? The answer depends less on company size than on operational dependencies, internal decision-making capacity and the consequences of service disruption.
The decision you actually need to make
The choice is not simply between speed and caution. It is about deciding where to place the risk:
- A big-bang rollout concentrates risk in one cutover but limits the period during which two systems must coexist.
- A phased rollout spreads risk over time but extends temporary interfaces and duplicate procedures.
- A pilot reduces uncertainty before scaling but may create false confidence if the selected scope is not representative.
Before approving a rollout method, management should request a one-page decision brief from the project manager. It must identify which flows must move together, which processes can temporarily operate across two systems, which data must remain synchronised and how the company would return to the previous operating model.
This document should be approved before the implementation contract is frozen. Otherwise, the strategy may be selected by default according to the vendor’s or integrator’s usual method. As explained in our article on fixed-price ERP projects, transferring contractual responsibility does not remove the decisions that remain with the client organisation.
The available options
Big-bang rollout
The legacy system is stopped and the new ERP becomes the system of record for the entire scope on a common date. This approach avoids prolonged coexistence between two master-data environments and reduces temporary integration work.
It is most suitable when business processes are tightly connected. Sales orders, inventory, purchasing, accounting and invoicing may share data that must remain consistent. However, migration, testing, access rights, training and user support must all be ready at the same time.
Rollout through business waves
The ERP is activated progressively by end-to-end process, location, subsidiary or user group. A wave might cover the complete sales-to-invoice cycle before purchasing or inventory management is migrated.
The sequence should follow complete business flows rather than the software vendor’s module catalogue. Activating sales without addressing customer data, pricing, inventory and the related accounting entries may merely move the risk into temporary interfaces.
France Num recommends a progressive ERP rollout, allowing organisations to correct problems during adoption and avoid overwhelming users.
Pilot before wider deployment
A representative site, department or user population operates the ERP before it is extended. This must be a real production pilot rather than a demonstration: actual transactions, interfaces, access rights, data and support arrangements should be involved.
Exit criteria must be written before the pilot starts. They should cover business scenarios, blocking defects, data reconciliation, operational support and documented configuration decisions. Without those criteria, the pilot may continue without producing a clear go-or-stop decision.
The criteria that really matter
| Option | Cost | Timing | Dependency | Internal capabilities | Reversibility |
|---|---|---|---|---|---|
| Big bang | Migration, testing and support costs concentrated around cutover | Faster full coverage if preparation is complete | Strong dependency on the integrator during preparation and go-live | Business team available to test, decide and support users | Low after cutover if the legacy platform is stopped |
| Business waves | Spending distributed over time, with possible duplicate licences and temporary interfaces | Longer until the full target is deployed | Extended dependency on the legacy platform and synchronisation mechanisms | Ability to manage two operating models temporarily | Good for an individual wave, harder after several waves |
| Pilot | Initial spending limited to the selected scope, followed by industrialisation costs | Wider deployment delayed by the learning phase | Strong dependency on pilot users and scope representativeness | Key users able to document gaps and distinguish local issues from structural ones | High until wider deployment begins |
The relevant cost is not limited to the integrator’s invoice. Management must include key-user availability, duplicate subscriptions, temporary development, manual reconciliation, enhanced support and the effort required to restore the legacy system if necessary.
When to choose each option
Choose big bang only if every condition is met
The scope must be consistent, processes stable, data migration repeatable, interfaces tested end to end and rollback technically possible. Business owners must also have enough capacity to resolve issues during preparation and cutover.
SAP recommends that core ERP team members dedicate at least 25% of their time to the project, or approximately ten hours per week. If finance, operations, sales or logistics leaders cannot provide that capacity, a company-wide cutover becomes difficult to control, regardless of the integrator’s technical expertise. The recommendation and the main deployment approaches are described in SAP’s ERP implementation guide.
A critical interface that has not been tested, or a migration that cannot be rehearsed, should exclude big bang until the issue has been resolved.
Choose business waves when flows can be separated
This option works when every wave can produce a usable business outcome without multiplying manual re-entry. For each wave, the project manager should provide a matrix identifying the system of record for each dataset, temporary exchanges, control owners and the condition required to begin the next wave.
Consider an illustrative scenario: sales, inventory and invoicing all use the same product master data. A strict module-by-module rollout could create complex synchronisation requirements. A wave covering the full order-to-invoice flow may be more coherent, even if it activates several technical modules.
Choose a pilot when uncertainty is organisational
A pilot is appropriate when locations use materially different procedures, when business rules remain disputed or when user adoption is uncertain. The selected scope must contain the difficulties the project is intended to resolve. Selecting the most available but least representative department will not validate the wider rollout.
In an opinion concerning a common financial information system for several public agencies, France’s Interministerial Digital Directorate considered a simultaneous cutover across six agencies highly risky. It recommended starting with a pilot agency and using the feedback to industrialise subsequent deployment. The case is not a universal rule, but it illustrates the value of a pilot when local operating models differ. Read the DINUM opinion.
Use a hybrid path when no pure option fits
A practical trajectory may start with a representative pilot, continue through business waves and finish with a common cutover for the core elements that cannot be separated. Hybrid does not mean undefined: every stage still needs an owner, entry criteria, exit criteria and a rollback mechanism.
The hidden cost of each option
Big bang: the internal workload peak
The hidden cost is the simultaneous demand on business experts. During cutover, the same people may need to verify data, answer user questions, prioritise defects and continue running day-to-day operations.
Before the dress rehearsal, the project manager should deliver a sequenced cutover plan, an escalation directory, a control checklist and a tested rollback procedure. Signing a user-acceptance certificate does not replace this preparation; our guide to functional acceptance testing before sign-off explains the controls that should be completed.
Business waves: temporary arrangements that become permanent
Temporary interfaces often remain in place longer than expected. Master data begins to diverge, while employees maintain two procedures and reconcile inconsistent results.
For every wave, the data owner should maintain a reconciliation register containing the official source, synchronisation mechanism, open anomalies and planned retirement of the temporary interface. A workaround without a removal condition is likely to become part of the permanent information system.
Pilot: local exceptions presented as a common model
Pilot users may request adaptations specific to their department. If these are accepted without governance, the project industrialises local exceptions instead of establishing a shared operating model.
At the end of the pilot, the sponsor should lead a scale-up review. Its deliverable must classify each request as a common standard, a justified local variation or a rejected requirement. The pilot is not complete until those decisions have been documented.
How D1 Consulting approaches the decision
We turn the “big bang or phased rollout” discussion into a documented management decision. Through our IT project management service, we work on the client side, independently of the software vendor’s commercial schedule or the integrator’s preferred methodology.
Our approach produces four operational deliverables:
- A decision brief: compared options, assumptions, exclusion criteria and the sponsor’s decision.
- A dependency map: processes, data, interfaces, stakeholders and systems that must move together.
- A deployment path: wave sequence, approval gates, business responsibilities and rollback conditions.
- A go-live pack: cutover plan, controls, support model, communications and decision log.
We then run decision meetings, coordinate the integrator and business owners, supervise acceptance testing and prepare change management. This role is particularly relevant when the company has no internal IT director able to dedicate sufficient time to the programme, as discussed in our article on managing an IT project without a CIO.
👉 Book a free 30-minute diagnostic to compare your ERP rollout scenarios and identify the decisions that must be documented before your next cutover.
