The Odoo Partner Vetting Kit

Odoo ships a major release every year. A partner who has never moved a real client from version 16 to 17 or 17 to 18 is going to be learning on your money. The specifics they give you predict how they will handle your future upgrades.

Over-customization is the single biggest predictor of long-term Odoo failure. A partner who cannot point to a single moment where they pushed back on a customization request has never pushed back. They are an hourly biller, not an advisor.

Module sprawl is one of the most expensive Odoo mistakes. Every installed module adds complexity, training surface, performance load, and upgrade risk. A good partner recommends fewer modules than the client expects, not more.

Data migration is the most underestimated phase in any ERP implementation. Importing a CSV is five percent of the work. The other ninety-five percent is cleaning duplicates, mapping fields, reconciling years of legacy errors, and validating with department heads. Most cost overruns trace back to this stage.

Local tax compliance is where regional Odoo deployments live or die. UAE Corporate Tax, Saudi ZATCA Phase 2, VAT, withholding tax, and local audit reporting are partner-built or partner-maintained territory. Whichever module handles your tax compliance becomes the most important piece of code in your entire deployment.

Most Odoo implementations succeed at go-live and then drift over the next twelve months. A "small request" goes in, then another, then another. After a year, the deployment has accumulated a hundred undocumented changes that no one can untangle. Governance is the only defense.

Without a defined support model, you are on time and materials forever. Every ticket becomes a billable hour, and the partner has zero incentive to deliver stability. A defined SLA aligns their interests with yours.

Data ownership is where lock-in happens. If the only way to access your Odoo database is through your current partner, you do not own your data. You are renting it.

Partner-replaceability is the inverse of vendor lock-in. The more painful it is to leave, the more leverage the incumbent has over pricing and quality. A well-defined exit clause keeps the relationship honest while it lasts.

Ambiguous acceptance criteria are how implementations become perpetual. Without a written definition of done, the partner can always find more to bill for, and the customer can always find more to ask. Both parties drift, scope creeps, and go-live is "next month" for eighteen months.

The number one bait-and-switch pattern in Odoo sales is the senior consultant who runs the pitch, then disappears once the contract is signed. A junior delivery team takes over, makes rookie configuration mistakes, and the senior reappears six months later to "rescue" the project at premium rates.

Methodology is the difference between a structured implementation and an expensive improvisation. The discovery-to-hypercare sequence is canonical. A partner who cannot describe their stages in two minutes is making it up as they go.

This is the sharpest single question in this entire kit. The partner's answer reveals their philosophy in one sentence. Standard-first partners build maintainable systems. Habit-first partners build the customer's current dysfunction into expensive code.

UAT determines whether the system actually works for users. Sandbox UAT with sample data hides every configuration gap that real-world data exposes. Demos with clean test records make every workflow look smooth; the same workflows break when run against ten years of legacy partner records, half-completed sales orders, and duplicated SKUs. Rollback determines whether a failed go-live becomes a four-hour incident or a four-week catastrophe. The rollback question is the one nobody asks and the answer that separates competent partners from optimistic ones.

Most SME Odoo implementations skip this entirely, then blame the partner when scope drifts and timelines slip. A defined steering committee with named members and decision authority is the joint mechanism for keeping the project on track. The partner asking for it is a signal of maturity.

Each hosting option has hard limits. Odoo Online is simplest but limits customization and gives you 24-hour RPO/RTO. Odoo.sh adds Git-based deployment and staging branches. Self-hosted gives full control but transfers all DevOps responsibility to you. A partner who recommends a platform without naming its bottlenecks does not know the platform well.

Customers who get Git access only at handover discover the partner has made undocumented decisions for months. By that point the cost of rework is prohibitive. Day-one access keeps the partner honest and gives you a complete audit trail.

This question is the technical proxy for "are you a real engineering team or a shop full of consultants writing code in the browser?" Partners with no CI/CD typically ship breaking changes directly to production, then bill you for the incident response.

The Odoo Apps Store is heavily uneven. A poorly maintained module can break with the next upgrade and lock you out of moving forward. OCA (Odoo Community Association) modules are typically higher quality because they have peer review and explicit maintainership, but even OCA modules can become unmaintained when their original sponsors lose interest. A partner who installs random apps without vetting is creating future upgrade debt. A partner who has never had to deal with an abandoned dependency has not run an Odoo deployment long enough.

Integration debt is the silent killer of Odoo deployments. Point-to-point integrations are fragile and explode with every change. Event-driven and middleware-based integrations are more maintainable. A partner who has never had an integration survive two upgrades has never built one properly.

The most common Odoo security failure is configuring access via Groups alone and ignoring Record Rules. Result: a warehouse user can see supplier costs, or a junior accountant can change customer credit limits. RBAC done right requires both groups and record rules, designed before the first user is created. SSO and MFA are the table-stakes identity controls for any organization above ten users. IP whitelisting and encryption at rest matter the moment you start handling regulated data.

Finance audit trails are the single most important security control in any ERP system. They are also the most commonly broken by careless customization. A clean audit trail makes statutory audits straightforward. A broken one makes them existential.

Three real regulatory regimes converged on the GCC market in the last three years: UAE Federal Decree-Law No. 45 of 2021 (PDPL) with full enforcement coming January 2027 and fines up to AED 5 million; Saudi ZATCA Phase 2 e-invoicing, mandatory and integrated into Odoo natively via the l10n_sa_edi module; and UAE Corporate Tax effective for financial years starting June 1, 2023. A partner serving this market who cannot speak fluently to all three is undertested.

Odoo Cloud commits to 24-hour RPO and 24-hour RTO for paid subscriptions, per Odoo's own security documentation. Anything stricter requires either Odoo.sh paid HA, or a self-hosted high-availability architecture. Untested backups are the most common failure mode in ERP disaster recovery. A partner who has never restored from backup in a drill cannot promise you they will be able to in a real incident.

Vendor master data fraud is one of the most common ERP exploits. A user with both vendor-creation and payment-approval rights can create a fake vendor, send invoices, and approve their own payments. Segregation of Duties (SoD) is the standard control that prevents this. It needs to be designed into the security model, not bolted on later.

ERP exposes habits. Once everything is visible, the casual approvals, the spreadsheet-of-record only Mariam maintains, and the off-system discounts become impossible to hide. People resist because they are losing autonomy, not because they cannot click the buttons. Two days of click-training does not solve this. It is a change management problem dressed as a training problem.

Without a defined train-the-trainer process, the customer becomes permanently dependent on the partner for every small question. Every "how do I create a custom report" becomes a billable ticket. A competent partner builds your internal capacity deliberately, because long-term clients buy more advisory work than short-term ticket-fillers.

Hypercare (the intensive post-go-live support period) is where most undocumented dependencies surface. Without specific SLA tiers, "support" becomes the partner's interpretation of urgency, which is rarely the customer's. P0/P1/P2 definitions force the partner to commit to response times that match real business impact. Partners with poorly defined hypercare extend it indefinitely, billing premium rates. Partners with no hypercare leave you on standard support from day one and bill you for incidents that should have been included.

Fixed-fee aligns partner incentives toward closing scope efficiently. Time-and-materials aligns them toward extending it. Neither model is universally right, but the choice determines how scope discussions go for the next twelve months. The warranty period defines what counts as "fix the bug we created" versus "new work we bill for." Without a rate card, every change-request becomes a fresh negotiation.

Intellectual property of custom Odoo modules is contractual territory. The default in many partner agreements is that the partner retains IP, which means leaving them later becomes much more expensive. Git repository access from day one is the practical control. Source code escrow is the heavy-weight version for mission-critical custom code, where a third-party escrow agent releases the code to you if the partner fails commercial obligations.

Most lock-in is built quietly. By the time you want to leave, the cost of leaving is prohibitive. Asking this question upfront forces the partner to design exit-ability into the engagement. A partner who has cleanly transitioned even one previous client has the discipline to do it again.

Almost nobody does this. Without baseline metrics captured before implementation, you can never defensibly prove ROI later. Order processing time, days to close books, inventory accuracy, customer service response time, error rates: these need to be measured in the pre-Odoo world to be compared to the post-Odoo world. The partner who suggests this is the partner planning to be evaluated on results, not on hours billed. The "who instruments it" question is critical because the work is genuine effort: data extraction from legacy systems, spreadsheet baselines, time studies. If nobody is assigned, it does not happen.

Reporting strategy is a fork in the road that creates technical debt if you choose wrong. Native Odoo dashboards are fast but limited. Studio reports cover most SME needs but become unwieldy at scale. External BI tools require a read replica and analyst skills but give you full flexibility. Odoo 19 newly supports a read-only replica which changes the calculus. A partner who recommends without explaining trade-offs is choosing what they know how to build, not what is right for you.