Implementation
Scoping, configuration, data migration, user training and go-live. Sales, purchase, inventory and accounting as the standard core, extended from there.
One system for sales, purchasing, stock, manufacturing and accounting: live in weeks, not years
Partner-led deliveryAt a glance
Odoo ERP usually runs 8–14 weeks for one company. 4–6 months for manufacturing or several companies.
We sit with the people who use the system, walk the site, and read the network. No proposal before we understand how the work is done today and where it breaks.
Discover
1–2 weeks
Current-state map of systems and traffic
Ranked list of what is costing you time or money
A go / no-go recommendation, in writing
For Odoo ERPA two-week fit assessment: we map your processes onto standard Odoo and report on what fits, what needs building, and what you should change instead of customising.
Design
2–3 weeks
Solution architecture and integration plan
Bill of materials with lead times
Fixed-scope statement of work
Build & deploy
5–9 weeks single-company
Working increments on anything that takes more than a fortnight
Staged cutover with a tested rollback
Handover documentation as it is built, not after
Run & improve
Ongoing
Monitored uptime with agreed response times
Quarterly review against the original goals
Capacity and security roadmap, refreshed each quarter
The spreadsheet, the shared sheet, the paper note and the WhatsApp order all end up in the same posted entry.
Six places
stock_final_v3.xlsx
warehouse
Sales — Sheet1
shared drive
Delivery notes
paper, in a folder
Orders on WhatsApp
sales team
customers_2024.csv
old system export
Stock count
handwritten
One record
entered once · read by sales, stock and finance

Apps we switch on, in phases
Not week ten. The single best predictor of an ERP go-live going badly is dirty master data: duplicate customers, three spellings of the same supplier, stock items with no unit of measure, opening balances nobody can tie out.
We pull your data in week one, show you exactly how bad it is, and agree who owns fixing which part. It is the least glamorous part of the project and the part that decides the outcome.
Every requirement gets tested against standard functionality first. Only what does not fit becomes a customisation, and only after you have seen what the standard flow looks like and said no to it.
This is not laziness. Every custom line of code is something you will pay to re-test at every future upgrade, forever.
We do not switch everything on one Sunday night and hope. Modules go live in dependency order, with parallel running where the risk justifies it, and a documented fallback at every stage.
| Phase | Weeks | What happens | | --- | --- | --- | | Fit assessment | 1–2 | Process mapping, gap list, fixed-price proposal | | Configuration | 3–6 | Core apps set up, chart of accounts agreed | | Data migration | 3–8 | Extract, clean, load and reconcile, twice | | Custom development | 5–10 | Only the agreed gaps, built as modules | | Training | 9–11 | Role-based, on your own migrated data | | Go-live and hypercare | 12–14 | Staged cutover, two weeks of on-site support |
Manufacturing and multi-company work extends the middle, not the ends.
Odoo releases a new major version every year. You do not have to take every one, but falling more than two behind gets expensive. We put a version strategy in writing at handover so the upgrade is a scheduled decision rather than an emergency.
You receive
Who this is for
How it starts
A two-week fit assessment: we map your processes onto standard Odoo and report on what fits, what needs building, and what you should change instead of customising.
Start hereBecause most failures are not software failures. They are data failures and adoption failures. Master data that was never cleaned, and users who were trained for two hours the week before go-live. We treat both as first-class work items with their own budget lines, which is why our timelines look longer on paper and shorter in reality.
Often bought together
A call, then a written recommendation. No obligation.