How to Choose an Odoo Partner in the UAE: 12 Questions to Ask Before You Sign

We rescue Odoo projects. Not every month, but often enough to have a clear view of how they go wrong, and the cause is rarely the software. It is a partner who sold on price, staffed the project with juniors, customised instead of configuring, treated UAE VAT as a localisation pack to switch on, and disappeared after go-live. The business is left with a system that half works, a code base nobody else wants to touch, and a bill for the rescue that exceeds what a proper implementation would have cost.

This guide is the set of questions we would ask if we were buying. It is written for the owner or finance head choosing between Odoo partners in the UAE, and for each question it describes what a good answer sounds like and what a weak answer is hiding. Ask all twelve, in writing, and compare.

The twelve questions

Questions 1 to 3: the people and the proof

Odoo partners in the UAE range from one freelancer to firms with a hundred people, and many partners from outside the region sell into Dubai remotely. None of that tells you who will sit in your blueprint workshop. Ask for the names, ask what each person delivered in the last two years, and ask what share of their week is yours. A lead consultant spread across six projects is a lead consultant who will not be there when the warehouse goes live.

Version matters more than most buyers think. Odoo releases a major version every year and the accounting, inventory and manufacturing modules change meaningfully between them. A partner whose references are all on a version from four years ago will learn the current one on your project. Ask for live projects on the version you will use.

The reference should be a company you can actually call, of similar size, in a similar sector, with a similar module set. Ask the reference what went wrong and how the partner responded. Every project has a hard week; the partner's behaviour in it is what you are buying.

Questions 4 and 5: customisation discipline

Odoo is flexible, which is its strength and the most common source of long-term cost. A partner who answers every requirement with custom code will deliver something that works on day one and becomes a liability at the first upgrade, when every customisation must be retested or rewritten. The right instinct is configuration first, standard modules second, well-built custom modules only where the business genuinely differs, and a written list of those customisations with the reason for each.

Ask how custom code is organised, whether it is in separate modules under version control, whether it has been upgraded before, and what an upgrade will cost. A partner who cannot answer has not thought about year three of your system.

Question 6: UAE compliance in practice

"Odoo has UAE localisation" is true and insufficient. A competent partner should describe how the tax codes map to the FTA return including reverse charge on imports and designated zone treatment, how the Arabic and English invoice layout is produced, how WPS files are generated from payroll, how entity-level reporting supports corporate tax, and which Accredited Service Provider connector they propose for the e-invoicing mandate that begins in phases during 2027. If you have a Saudi entity, ask the same about ZATCA Phase 2. These answers take an experienced UAE consultant five minutes. They take a remote generalist a week of research. Our Odoo in Dubai guide sets out what the localisation does and does not cover.

Questions 7 and 8: migration and training

Data migration is the workstream most often underestimated by both sides. The partner should state who cleanses the legacy data, provide templates, run at least two full test migrations reconciled to the old system, and treat the final migration as a rehearsed event rather than a weekend scramble. Training should be by role, on your migrated data, with a second round in the weeks after go-live. One training day for everyone on demo data is a sign that adoption has not been planned.

Questions 9 to 12: support, price and contract

The weeks after go-live are when the real questions appear and when a partner who has been paid in full tends to disappear. Ask for a defined support period with named people and response times, and for the annual support contract that follows, with its terms visible now rather than negotiated under pressure later. Our annual support page describes what a reasonable contract covers.

On price, ask how the figure is built and what is excluded. A fixed price for a defined scope with assumptions on one page is the honest format; a single number is not. Licences should be shown separately from services. Our Odoo cost guide gives the ranges to check against. Payment milestones should follow deliverables you can verify, and a large upfront payment with the balance at go-live leaves the partner no reason to care about month three.

Finally, ownership. You should own your data in a format you can export at any time, and the custom modules built for your business, with access to the repository. A partner who retains ownership of your customisations has made changing partner expensive by design.

How Kaido approaches it

We would rather lose a project on these questions than win one by avoiding them. Every proposal we issue names the consultants and their allocation, lists the expected customisations with reasons, states the ASP connector and the compliance configuration, specifies two reconciled test migrations, ties payments to deliverables and gives the client ownership of code and data. We do this because it is the proposal we would want to receive, and because it removes the arguments later.

If you are evaluating partners now, send all of them these twelve questions in the same email and compare the written answers before any demo. If you already have a live Odoo system that a previous partner left half finished, our guide to rescuing a failed implementation explains how we assess what can be kept and what must be rebuilt.