Iterative go-live: migrate and integrate without stopping operations
The weekend cutover that switches everything on at once looks clean in the plan. On the plant floor and in billing, it's usually when operations get held together with Excel.
If you manufacture or distribute, fearing the big bang is rational. A Saturday-to-Sunday ERP cutover promises "on Monday we're on Odoo." In practice, it also promises stuck invoices, inventory that doesn't match and a team improvising in spreadsheets while someone restarts the plan.
The alternative isn't dragging the project out forever. It's an iterative implementation: waves with migration, integrations and training sequenced so operations never stop.
Why the heroic cutover fails in real operations
The big plan assumes that:
- Data comes out clean the first time.
- Every role learned what they needed in the theory workshop.
- Peripheral integrations respond on Monday at 8:00.
- There are no rush orders, in-transit inventory or half-finished closes.
In manufacturing and distribution, that list almost never holds. An ERP go-live isn't an IT event: it's a change in how you receive, pick, produce and invoice. If you compress it into a weekend, people with Excel become the safety net.
You don't need to invent downtime hours or error rates to see the risk. It's enough to have lived through a Monday when you couldn't invoice or trust your stock.
Waves: what it really means
Iterating isn't "going slow for the sake of it." It's choosing cuts the business can tolerate:
- By process (purchasing and inventory before full MRP; invoicing for one channel before all of them).
- By warehouse, plant or business unit.
- By document type or product family.
Each wave includes its share of Odoo data migration, its test with real users, Odoo training tied to actual use, and its "ready to expand" criteria. The system goes live piece by piece. And it stays live, because people are already working in it before the big announcement.
Sequenced migration, not "all history on Saturday"
Migration is where many big bangs break. A healthy sequence usually looks like this:
- Clean and freeze master data (products, contacts, accounts) with business owners.
- Bring over the open items operations needs (orders, stock, pending invoices), validated on the floor.
- Decide which history stays available for lookup or archive, without bloating the ERP on day one.
- Repeat the load rehearsal until operations and finance sign off on the quality criteria (not just IT).
Each wave migrates its own part. You avoid the drama of "if stock fails, payroll and eCommerce fail too."
Integrations: the other thread that can't survive a big bang
Payment gateways, external WMS, eCommerce, banks, EDI. If they're all cut and reconnected the same night, you have too many simultaneous points of failure. In an iterative approach:
- You identify which integration is critical for the current wave.
- You leave explicit temporary bridges (with an end date) when needed.
- You test with realistic volume, not just the happy path.
The goal is continuity. Not a flawless architecture diagram on kickoff day.
Training when it hurts (and helps)
Training three weeks before cutover leads to forgetting. Training on the day of chaos leads to panic. In waves, you train each role when its flow goes into production: with their products, their customers, their exceptions.
That's adoption, not an attendance checklist. Business implementations fail on adoption, not features. The launch sequence is part of designing for adoption.
What it looks like in the KAI Consulting method
In Odoo Implementation we work like this:
- Discover. What can't stop (invoicing, fulfillment, production). Where the real cutover risk is.
- Design. Configure before customizing. A wave plan, with exit and rollback criteria for each stage. Prototypes with the floor team.
- Implement. Iterative launches: migration, integrations and training sequenced so operations never stop.
- Evolve. After each wave (and after full go-live), Support and Evolution: SLAs, adjustments and next capabilities.
It's not a lab project or a roadmap presentation. It's live delivery, in pieces the business can absorb.
Signs your plan is still a big bang in disguise
- A single "point of no return" date for the entire scope.
- Training is a generic course disconnected from the wave.
- Migration gets tested once, "if there's time."
- No business owner signs off on data quality for each stage.
- Plan B is "we'll use Excel for a few days," with no limit and no owner.
If that sounds familiar, rewrite the plan around operational continuity.
A practical next step
List the three flows that, if they fail on Monday, stop cash or fulfillment. Design the first wave around just one of them. Everything else waits, deliberately. That discipline is usually the difference between a go-live that sticks and one that gets told as "we went live, but…"
At KAI Consulting we take Odoo live through iterative launches: from the first workshop to go-live, without asking operations to survive a heroic weekend. If fear of the big bang is on the table, let's talk about how to sequence yours.