Four ways to switch from your old system to the new ERP — how each works, and how to choose.
An ERP implementation eventually reaches one unavoidable question: how do we switch from the old system to the new one? This page compares the four rollout strategies — big bang, phased, parallel, and pilot — how each one works, where each one fits, and what to watch out for on go-live day.
This page covers go-live strategies only. If you came here for the stages of an ERP project — planning, design, development, testing, and the rest — read them in the ERP implementation guide .
Here is the whole decision in one table — then a few lines on each strategy.
| Strategy | How it works | Best for | Watch out for |
|---|---|---|---|
| Big bang | Everyone switches on one date | Smaller companies, simple setups | Highest risk on go-live day |
| Phased | Roll out by module, team or site | Multi-site or complex businesses | Longer overall timeline |
| Parallel | Old and new systems run side by side for a while | High-risk areas like finance | Double data entry while both run |
| Pilot | One team or site goes first, then the rest | Testing the setup before a wide rollout | Pilot results may not match other sites |
Everyone — every user, every process, every site — switches to the new ERP on a single date. It is the fastest path and suits smaller companies with simple setups. It is also the highest-risk go-live: if something breaks, everyone feels it at once, so it demands the deepest testing and a clear rollback plan before cutover.
You roll out by module, team, or site across a series of smaller go-lives. Each phase is a smaller, lower-risk cutover, and the lessons from one phase carry into the next. The trade-off is a longer overall timeline, with periods where old and new processes run side by side.
The old and new systems run side by side for a while, which is why it suits high-risk areas like finance — the old system stays the source of truth until the new one proves itself. The cost is double data entry while both systems run, plus the reconciliation work to keep them matching.
One team or site goes live first, and the rest follow once the setup has proven itself in real use. It is the safest way to test the implementation before a wide rollout. Watch out that pilot results may not match other sites — a different process or cleaner data can make the pilot look easier than the full rollout will be.
Five questions decide it:
How big is the company? More users, departments, and processes usually point toward a phased rollout.
How many sites do you run? Multi-site businesses often phase by location or pilot one site first.
How much risk can you carry on go-live day? Low risk tolerance pushes toward parallel or phased.
How much downtime can you accept? If downtime is unacceptable, a parallel run keeps operations going.
How much capacity does your team have? Parallel and phased ask more of the team over a longer period than big bang does.
There is no single right answer — the rollout follows your size, your sites, and your risk tolerance. In our Odoo projects we plan the rollout together during project planning, and we keep go-live risk as low as your timeline allows. See which rollout we recommend for Odoo projects .
What is a big bang ERP rollout?
A big bang rollout switches every user and process to the new ERP on a single date. It is the fastest path, but it is also the highest-risk go-live: if something breaks, everyone feels it at once. It suits smaller companies with simple setups, and it demands deep testing and a rollback plan before cutover.
Is a phased rollout safer?
Generally, yes. Each phase is a smaller go-live, so there is less to fix at once, and the lessons from one phase carry into the next. The trade-off is a longer overall timeline, with periods where old and new processes run side by side.
How long should we run systems in parallel?
Long enough to prove the new system on your critical processes — for finance, that usually means at least one full monthly close — but not so long that double data entry wears the team down. Set the exit criteria before you start, so the parallel run ends on evidence, not on habit.
Can we combine strategies?
Yes, and most real projects do. A common mix is a pilot to validate the setup, then a phased rollout for the rest of the business. Another is running finance in parallel while other modules go live in phases.
Which ERP rollout strategy should we choose?
It follows from five questions: how big the company is, how many sites it runs, how much go-live risk it can carry, how much downtime it can accept, and how much capacity the team has. Map your answers against the strategies above.