Every Odoo implementation reaches the same fork. You can switch the whole business over on one date, or you can move in stages and run two systems for a while. Everyone involved has an opinion, but the honest answer is that both approaches work. The wrong choice is usually made for the wrong reason: fear on one side, impatience on the other.
Here is what actually separates the two, and how to tell which one your situation calls for.
What the two options really mean
A big bang cutover means every module and every user goes live on the same date. The old system is frozen, opening balances are carried over, and from that morning there is exactly one place to work.
A phased rollout means going live in slices. The slice can be functional (accounting first, then inventory, then manufacturing), organizational (one company or branch first, then the rest), or geographic (one country, then the group). Whatever the cut, the defining feature is the same: for some period of time, part of your business runs on Odoo and part of it does not.
That overlap period is the whole subject. Almost every argument for and against either approach is downstream of it.
When big bang is the right call
- Your processes are tightly coupled. If a sales order immediately reserves stock and posts a cost entry, splitting sales, inventory and accounting across two systems means building those links twice: once as a temporary bridge, once for real.
- You are one legal entity with one operations team. A single company does not need a pilot branch. Everyone is close enough to the change to absorb it together.
- The old system is leaving on a fixed date anyway. An expiring license, aging hardware, a vendor who has stopped answering. If the exit date is set by someone other than you, phasing only compresses the final phase.
- Your data can move in one pass. If the cleanup work is manageable and the volumes are ordinary, a single migration is less work than staging the same data twice.
Big bang has a quiet advantage that rarely appears in a proposal: it forces decisions. Phased projects accumulate open questions, because there is always a later phase to defer them to.
When phasing is the right call
- You are a group, not a company. Multiple entities with different charts of accounts, tax regimes and operating models. Going live everywhere at once multiplies the risk rather than adding to it.
- One area is on fire and the rest is fine. If accounting is the problem and the warehouse runs on something that works, replace the accounting first and leave the warehouse alone until you have earned the right to touch it.
- One scope item is genuinely hard. Manufacturing, quality, or a field service flow with real customization behind it. These deserve their own go-live with undivided attention.
- Your team cannot absorb the change in one go. Training capacity is a real constraint, and it is the one most often ignored. People still have their day jobs during your project.
The cost that phasing hides
Phasing is usually presented as the safe option. It reduces the size of any single failure, which is true and valuable. What it does not do is reduce total effort, and the extra effort lands in places nobody budgets for.
- Disposable integrations. Every overlap needs a way to move data between old and new. You will build it, maintain it, argue about it, and then delete it.
- Double entry and reconciliation. Somebody keys the same transaction twice, or a nightly job does it and somebody checks it. That person is usually your best finance staffer, and this is not what you hired them for.
- Cutover happens more than once. Freezing balances, validating data, running the first close: each phase repeats the most stressful week of the project.
- Attention decays. Sponsors are fully engaged for phase one. By phase three the steering committee has stopped meeting and the open questions have no owner.
How to phase without stranding yourself
If phasing is the right answer, the design of the phases matters more than the decision itself.
- Cut along a seam, not through a process. The boundary between finance and operations is a seam. The middle of the order-to-cash cycle is not.
- Put accounting in the first phase in most cases. The general ledger is where every other process eventually lands, and reporting out of two ledgers is misery.
- Fix the end date of the overlap before phase one starts. Not the start date of phase two, the date the old system is switched off.
- Build the bridge as a file exchange, not a real integration. Accept that it is temporary and resist the urge to make it elegant.
- Master your data in Odoo from day one. Products, partners and the chart of accounts should have a single owner immediately, even while transactions still happen elsewhere.
Making the call
Count your legal entities. Count the processes that are genuinely coupled. Ask whether someone else has already set your exit date. Ask your managers, honestly, how much training their teams can take this quarter. Those four answers usually point the same way.
When they do not, one question settles it: can you name the exact date the old system gets switched off? If you can, phasing is a plan. If you cannot, phasing is a delay wearing a plan's clothing, and you should go live on one date instead. Our Odoo implementation service sequences this with the customer rather than for them, because the constraint that decides it is almost always internal, not technical.