Odoo implementation
One project lead, one schedule, and as little code as possible.

An Odoo project rarely fails on technology. It fails when the scope moves every fortnight, when migrated data is wrong, or when users discover the software the day before go-live. Our method is built around those three risks.
The scope is written before we start. The free assessment produces a list of flows, a schedule and a price. Anything outside it is discussed — and priced — separately.
Data is verified before it is posted. From Sage, the general ledger, chart and partners are migrated in five tooled steps; the Odoo trial balance is reconciled with the Sage one account by account. From Excel, we analyse your files, propose the column mapping and import as drafts.
Users practise before go-live. A neutralised copy of your database serves as a training ground, payroll runs in parallel for a month, and each role is trained on its own screens.
We stay close to standard Odoo. Custom development is justified when it earns more than it costs at every upgrade — which is rare. When it is, we write it as an installable, documented add-on you can remove.
Seven steps, one week per module.
An Odoo deployment rarely fails on technology; it fails on a blurry scope, dirty data and users trained too late. Our method deals with these three risks in order: one week of scoping, one module delivered per week, training as we go.
- 1
Kick-off
One launch meetingEveryone around the table: your management, your key users, our project manager and consultants. Objectives, scope, schedule, ground rules (WhatsApp group, weekly check-ins, training database). The project starts the same day.
- 2
Scoping
1 weekWorkshops per trade: what Odoo does out of the box, what changes in your habits, what is really missing. Every gap is settled — Studio, a Senedoo add-on or an adapted process — and the module plan is set, in the order you need them.
- 3
Business processes, module by module
1 week per moduleFor each module (accounting, sales, purchases, stock, till, payroll, projects…): import of your data and configuration, on your real products, partners and journals. The module is tested end to end with your key user before moving to the next.
- 4
Training per module
At the end of each moduleAs soon as a module is configured, its users are trained, per role, on the training database with your documents. Every procedure can become a three-minute video tutorial. Nobody waits for the end of the project to practise.
- 5
Final acceptance
1 weekYour key users replay the complete flows — order to cash, hiring to payslip — on the migrated data. Every gap is fixed and signed off. Go-live is only decided when everything is green.
- 6
Go-live and stabilisation
D-day, then 4 weeksProduction start on a Monday morning with a consultant on site. The next four weeks are a stabilisation phase: reinforced support, fine adjustments, answers within minutes on WhatsApp.
- 7
Keeping it alive
No time limitThe support contract takes over: WhatsApp group, watch on Odoo upgrades, tax changes, new modules on demand.
Our principles
If standard Odoo covers 90% of the need, we adapt the process, not the tool. Every custom development is a debt you pay at every upgrade.
What is missing is done with Studio, our installable add-ons, or our VPS synchronised through webhooks and crons. Your database stays standard: always up to date, never locked in.
A first lot in production in six to ten weeks; a multi-company group or a network of shops in three to six months. Each lot has its own quote, known before we start.
One key user per trade on your side, one project manager on ours, one WhatsApp group in between. Decisions are made in workshops, not by e-mail.
A call or a WhatsApp message to our sales contacts — or leave us a message and we call you back within one working day.
Odoo.sh or on-premise? We bring you back to SaaS.
An Odoo.sh or on-premise database ages with its Python modules: every postponed version, every server to maintain, every developer who left. We migrate it to Odoo SaaS, latest version, without losing your data or your automations.
- 1
Database audit
Version, installed modules, custom developments, volumes, integrations. For each custom module: what standard Odoo does today, what Studio or our add-ons cover, what must live on our synchronised VPS. You receive a migration plan and its price.
- 2
Version upgrade
The database is upgraded to the current SaaS version through Odoo's upgrade service, on a test copy. Custom modules are removed; their data is kept in standard or Studio fields.
- 3
Rebuilding the specifics
Automations, reports, connectors: rebuilt without code in the database — Studio, server automations, webhooks to our VPS. Every function is tested against the old database, on your data.
- 4
Acceptance and switch
Your key users test on the copy; we rehearse the migration, then run it for real over a weekend. On Monday your teams find their screens, their history and their habits — on a database that updates itself.
No hosting to pay for or watch, no backups to check.
Odoo SaaS updates continuously: never again a version-upgrade project.
No custom code in the database: any Odoo partner can take over your database tomorrow.
A call or a WhatsApp message to our sales contacts — or leave us a message and we call you back within one working day.
Still on Sage? Senedoo helps you move to Odoo (at last).
Sage keeps your books. Everything else — quotes, stock, till, payroll, reminders, dashboards — lives in spreadsheets and e-mails. Odoo does in one software what you do today in five. And the migration is verified to the franc, or not posted.
