The ERP you have to rebuild in three years.
Most Odoo implementations that get rebuilt were not badly built. They were built to match what the organisation already did, including the parts it did badly, and then customised heavily to preserve those habits. Two versions later the customisations block the upgrade, nobody remembers why they exist, and the only affordable path forward is to start again.
The decisions that determine whether that happens are taken in the first six weeks, before any configuration begins — what stays standard, what genuinely requires extension, which processes change to fit the platform and which processes the platform must be bent to fit. We treat those six weeks as the most important part of the project.
What usually goes wrong.
Configuration started before analysis finished
Consultants begin building in week two because the client wants visible progress. The design is then reverse-engineered from what was built.
Customisation as the default answer
Every gap between Odoo standard and current practice is closed with development, rather than by asking whether current practice should change.
Data migration treated as an import
Master data and opening balances are loaded from spreadsheets late in the project, and the reconciliation problems surface after go-live.
Integrations discovered, not designed
The bank file, the government portal and the eCommerce platform are remembered during UAT, when the architecture is already fixed.
UAT run by the project team
The people who built the system test the system. The departments that will use it see it for the first time in training.
Go-live treated as the finish line
The contract ends at hypercare, around day 90. The behaviours that decide whether the investment returns anything form on day 91.
What the engagement actually includes.
Business discovery
Two to six weeks on site, walking each end-to-end process with the people who run it. The output is a documented current state that the client's own managers confirm — not an interview summary.
Fit-gap analysis
Every requirement tested against a fixed hierarchy: Odoo standard first, then configuration, then integration, and only then customisation. Each decision is recorded with the reason, so it can be revisited at upgrade.
Solution blueprint
The future ERP environment defined before major build begins: processes, modules, entities, roles, security, integrations, migration scope, reporting, infrastructure and implementation phases.
Build & integrate
Configuration against the blueprint, extensions only where the blueprint approved them, and integrations designed as versioned contracts between systems rather than point-to-point scripts.
Data migration
Run as a controlled sub-project: extract, clean, map, migrate, reconcile, validate — with sign-off on opening balances and inventory before cutover, not after.
UAT, go-live & hypercare
Departmental test scripts signed off by the heads who own each area, a cutover plan with a documented fallback, then hypercare and a planned transition into support.
Seven stages, each with a gate.
Standard first. Customise last.
Every requirement passes down this hierarchy in order, and we document where it stopped. Customisation is not forbidden — it is the fourth answer, taken deliberately, with the upgrade cost understood at the time of the decision.
Odoo already does it. The process adapts to the platform. This is the answer most of the time, and the answer that survives upgrades.
Achieved through settings, fields, workflows, rules and reports. No code, no upgrade risk, fully supported by Odoo.
Another system already does it better, or owns the data. We connect rather than rebuild — as a versioned, documented contract.
A genuine business requirement no standard capability supports. Approved explicitly, documented, and assessed again at every upgrade.
Every hour of unnecessary customisation is paid for three times: once to build it, once to maintain it, and once to remove it at the upgrade.
A working ERP environment your team can own.
Every engagement produces the artefacts your internal team needs to run, change and upgrade the system after we leave. Documentation is a deliverable, not a courtesy.
Odoo is the digital core. These are the things it usually has to talk to on a regional implementation.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
How long does an Odoo implementation take?
For a single-entity operation with standard processes, three to five months. For a multi-company, multi-country group with integrations and migration, nine to eighteen. Anyone quoting a duration before discovery is quoting a template, not your project.
Should we implement everything at once or in phases?
Phased, in almost every case — but phased against operational milestones rather than module groups. Each phase should change one measurable thing. Big-bang is defensible only for small single-entity operations with a hard deadline.
How much customisation is acceptable?
There is no percentage that answers this. The test is whether each extension was approved against a genuine business requirement, documented, and assessed for upgrade impact at the time. Ten well-governed extensions are safer than three undocumented ones.
Can you take over from another partner mid-project?
Yes — that is a rescue engagement, and it starts with an audit rather than a plan. We will tell you in writing, within two weeks, whether the existing build is recoverable or whether continuing costs more than restarting.
What happens after go-live?
Hypercare for the first weeks, then a planned transition into support with a named owner on your side. Go-live is not the end of the relationship — the behaviours that decide whether the investment returns anything form after the project team leaves.
ERP governance after go-live.
The decision log is the asset. Most programmes throw it away at handover.
ERP StrategyWhy ERP projects fail at the operational layer.
Implementations rarely fail technically. They fail at the point where the software meets a process nobody agreed to change.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.