The Odoo implementation guide we wish every projectstarted with

Most Odoo projects we are called into have the same shape: the software was installed correctly, the data was migrated hopefully, and go-live revealed the difference. This is the implementation guide we wish every project had started with.

Start with the data, not the modules

Odoo will happily import whatever you give it. That is the problem. Duplicate customers, three spellings of the same supplier, open orders from 2019 that nobody closed — all of it imports cleanly and then poisons every report you run afterwards.

Before any module is switched on, we insist on three artefacts:

1. A data inventory. Every source system, every export, and an honest count of records in each. The number is always larger than the estimate.
2. A deduplication pass. Usually 8–15% of customer and supplier records are duplicates. Merge them before migration, not after, because post-migration merges break foreign keys you will spend weeks repairing.
3. A cut-off policy. Decide what migrates and what stays read-only in the old system. Migrating eleven years of history feels thorough and mostly buys you eleven years of bad data in a new database.

The demo works because someone curated the data. Production fails because nobody planned for the exceptions already sitting in the database.

Which Odoo, and where it runs

For most businesses we recommend Odoo Online or Odoo.sh on a current long-term release (17 or 18 at the time of writing). Self-hosting makes sense only when you have a specific reason — custom modules that need server access, or data that cannot leave your infrastructure.

• Odoo Online — fastest to start, least customisable. Right when your processes fit Odoo rather than the other way round.
• Odoo.sh — our default. Staging branches mirror production, so every migration phase can be rehearsed exactly as it will run.
• On-premise — justified for regulated data or heavy custom modules, and only with someone who will own the upgrades.

The modules that actually matter

Odoo sells breadth; implementations succeed on depth in four or five modules. For manufacturing and distribution, the order that works is:

1. Inventory and Purchase first. Stock accuracy is the foundation everything else reports on. If this is wrong, the financials built on top of it are fiction.
2. Sales and Invoicing second. Wired to the same stock truth, so the storefront stops overselling.
3. Manufacturing (MRP) third. Bills of materials deserve their own phase because they encode tribal knowledge nobody has written down.
4. Everything else after go-live. CRM, helpdesk and marketing automation are easier to adopt once the operational core is trusted.

Rehearse the migration, then rehearse it again

Every migration phase runs at least twice in staging: once to find the discrepancies, once to prove the fix. Each phase has a tested rollback, because the question is never whether something goes wrong but whether you can reverse it in minutes rather than days.

On a recent consolidation of four Odoo instances into one, the third rehearsal caught a chart-of-accounts mapping error that would have misposted six weeks of transactions. The rehearsal took an afternoon. The alternative would have taken a quarter to unwind.

Train the users, not the approvers

Training budgets get spent on the team that approves the system. The team that uses it gets a PDF. Reverse that. We train in the staging environment against the migrated data, so the first day on the new system feels like the fiftieth day of practice — because it is.

When Odoo is the wrong answer

We are an Odoo partner and we will tell you when not to buy it: when you need multi-entity consolidation across dozens of legal entities with complex intercompany rules (look at Dynamics 365 Finance), when your sales process genuinely needs Salesforce CPQ, or when your problem is a single integration rather than an ERP at all.