The software rarely failed. The project did.
When an ERP programme is eleven months late and nobody can say what remains, the instinct is to blame the platform. In our experience that is almost never where the fault lies. The common causes are a specification that described the wrong operation, customisation used to avoid organisational decisions, a data migration that was never reconciled, and a partner who took instructions instead of giving advice.
That distinction matters commercially. Replatforming costs more than recovery and takes longer, and it is the right answer less often than vendors claim. But it is sometimes the right answer, and continuing then costs more than restarting. Which of the two you have is a question of evidence, and it can be settled in about two weeks.
Is this happening to your ERP?
The implementation is endlessly delayed
Go-live has moved more than twice and nobody can produce a credible list of what remains.
Users have gone back to Excel
The system is live, but the real work happens in spreadsheets that are emailed around and reconciled by hand.
The accounting numbers cannot be trusted
Finance maintains a parallel set of records because the ledger does not agree with the operation.
Inventory does not match reality
Stock in the system and stock on the shelf diverged at go-live and were never reconciled.
Performance has degraded
Reports time out, screens are slow, and scheduled actions overrun into working hours.
There are too many custom modules
Nobody can list them, explain why each exists, or say what breaks if one is removed.
Integrations fail regularly
Interfaces break on every update and someone reruns them manually each morning.
The previous partner has gone
Handover never happened, no documentation exists, and the code has no comments.
Upgrading has become impossible
You are three versions behind and every quote to upgrade approaches the cost of reimplementation.
What the engagement actually includes.
Audit
Two weeks, on site and in the codebase. We review configuration, custom modules, database, accounting, inventory, integrations, infrastructure, security, performance, data quality and documentation — and rank every finding critical, high, medium or low.
Written verdict
In week two you receive a recommendation with numbers behind it: recover, partially replatform, or reimplement — with the cost, duration and risk of each option stated plainly. We will tell you if the right answer is to stop.
Stabilise
Before improvement, we stop the bleeding: the performance problems, the accounting discrepancies, the failing integrations and the inventory variance that are costing you now.
Recover
Component by component, against the Keep / Fix / Rebuild / Remove framework — so the effort goes where it changes something, not uniformly across everything.
Transition
A documented architecture, a named owner on your side, an upgrade roadmap, and a support arrangement that does not recreate the dependency you have just escaped.
Six stages. The decision happens in week two.
Keep. Fix. Rebuild. Remove.
Taking over an Odoo implementation does not automatically mean rebuilding everything. Most environments we audit contain a good deal that works, a manageable amount that needs correcting, a small number of components that should be rebuilt, and a surprising quantity that should simply be deleted.
Functionality that works correctly and is upgrade-safe. We leave it alone and document it, so the next partner does not rebuild it either.
Functionality that can be corrected efficiently — a configuration error, a broken control, a report reading the wrong source.
Components where repair would cost more than replacement, or would leave technical debt that blocks the next upgrade.
Customisations nobody uses, features superseded by standard Odoo, and obsolete integrations still running every night.
On a typical rescue, more than a third of the custom code we audit can simply be deleted — because newer Odoo versions now do it as standard.
A written verdict, then a stable environment.
The audit is a standalone engagement with its own deliverable. You can act on it with us, with your existing partner, or with your internal team — the document is yours either way.
What we look at during a technical audit. We work in the codebase and the database, not only in the interface.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
Will you tell us to reimplement so you get a bigger project?
The audit is a fixed-scope, fixed-fee engagement, and the recommendation is written before any implementation proposal exists. Most of the environments we audit are recoverable, and we say so — recovery is the smaller piece of work.
Can you work with our existing partner rather than replacing them?
Yes. Some clients want the audit and the roadmap and then have their existing team execute it. That is a legitimate outcome and we will hand over cleanly, including a briefing session with the partner if you want one.
What if there is no documentation and the developer has gone?
That is the normal starting position for a rescue. We reconstruct the as-is architecture from the codebase and the database. It adds time to the audit, and it is the first thing we fix.
Can you recover a heavily customised environment?
Usually, and often by removing rather than repairing. Heavy customisation from an older version frequently duplicates what newer Odoo does as standard, so a meaningful share of the code can be retired rather than migrated.
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.