Odoo Consulting: When You Need a Consultant

You need Odoo consulting services when a decision in front of you is expensive to reverse and nobody on your team has made it in Odoo before. The usual cases are choosing edition and hosting before you sign, settling company structure and localization before the first entry is posted, rescuing a stalled project, planning an upgrade that carries custom code, and expanding into a new country. You usually do not need a consultant for questions about how a standard feature works, for bugs, or for one well-specified development task, because Odoo's own support covers the first two and a developer covers the third.

Consulting is not a phase you buy once. It is a handful of moments across the life of an Odoo database, most of them after go-live. Below are those moments, the signals that one has arrived, what a consultant should hand you, and how to keep the engagement small. Every Odoo document quoted here is the 20.0 version, checked on 13 October 2026.

What Odoo's own support will and will not do

It is easy to assume that an Odoo Enterprise subscription includes someone to tell you how to set the system up. It does not. The Odoo Enterprise Subscription Agreement limits support tickets "exclusively" to questions about Bugs "or guidance with respect to the use of the standard features of the Software", and states that questions "related to development or customizations may be covered through the purchase of a separate service agreement" (Odoo Enterprise Subscription Agreement, §4.5).

The same agreement defines a Bug as a failure causing a stop, a traceback or a security breach that "is not directly caused by a defective installation or configuration". If your invoices post to the wrong account because a tax was set up wrongly, that is a configuration problem, not a Bug. Design questions such as "one company or two?" or "who approves purchase orders above which level?" sit with you, or with someone you hire to help you decide.

That gives a simple routing rule for any Odoo question:

The question	Who answers it
Is this standard feature broken?	Odoo support (Enterprise), or your hosting and support provider
How does this standard feature work?	Odoo documentation, Odoo's tutorials, Odoo support
Which way should we set this up for our business?	A consultant, working with your finance and operations leads
Odoo does not do this at all. Can it be built?	A developer, after someone has confirmed standard Odoo really cannot do it
Who keeps it running week to week?	Your administrator, or a support and maintenance provider

Source: the scope of support and the Bug definition in the Odoo Enterprise Subscription Agreement.

The seven moments at a glance

Moment	The signal	What becomes hard to undo
1. Before you sign	You are comparing ERPs, or a demo showed features nobody has mapped to your processes	Hosting type and edition
2. Before the first posting	More than one legal entity or country, or an accountant who has not seen the chart of accounts	Fiscal localization and company structure
3. A stalled project	The go-live date has moved and nobody can list what is left	Sunk cost and the team's trust in the system
4. Before an upgrade	Your version is near the end of standard support and you run custom modules	Custom code that blocks the upgrade
5. Expansion	A new subsidiary, country or warehouse	Localization and inter-company flows
6. Workarounds	Spreadsheets beside Odoo; exports to fix numbers by hand	Data quality
7. Integration sprawl	Nobody can say which system owns customer or stock data	Duplicates and conflicting records

Source: Odoo's upgrade, fiscal localization and Odoo Online documentation, quoted in each section below.

1. Before you sign: edition, apps and hosting

Hosting decides what you are allowed to build. Odoo's documentation is blunt: "Odoo Online is incompatible with custom modules or modules from the Odoo Apps Store" (Odoo Online documentation). If your processes need even one custom module, you need Odoo.sh or a self-hosted server.

Fixing this later is its own project: Odoo's upgrade documentation states that an upgrade does not cover switching editions, changing hosting type or migrating from another ERP (Odoo upgrade documentation).

What you should get: a fit-gap list by process (standard, configuration, Studio, custom or integration), a recommended edition and hosting type with reasons, and the risks you are accepting.

2. Before the first entry is posted: localization and company structure

The fiscal localization package is the set of country-specific modules behind your chart of accounts, taxes and statutory reports. Odoo's warning is short: "Selecting another package is only possible if no entry has been posted" (Odoo fiscal localizations).

The same page settles a structural question that is easy to get wrong. Branches "always follow the parent company's localization", so "entities operating in different countries should be set up as companies, not branches". An overseas entity set up as a branch to save effort will post under the wrong country's rules.

What you should get: a signed decision on companies versus branches, the localization for each company, and your accountant's sign-off on the chart of accounts before the first test posting. The settings that become hard to change once live data exists are listed in our Odoo implementation checklist; this guide is about when to bring in help for them.

3. When an implementation stalls or keeps growing

The go-live date has moved more than once. The same requirement comes up in meeting after meeting. The estimate for "customization" keeps rising. Nobody can list what is configured, what is custom and what is left.

A consultant here reviews rather than builds: what exists in the database against the signed scope, then a choice between continuing, cutting scope to what go-live needs, or changing approach. The reviewer should not be the provider whose work is being reviewed. If you ask an implementation firm, including us, to review another provider's project, ask up front whether it would bid on the remaining work.

What you should get: an inventory of configuration and custom code, open items ranked by whether go-live needs them, and a re-baselined scope you can hold any provider to.

4. Before a version upgrade that carries custom code

Odoo gives each major version three years of standard support (helpdesk support, bug fixes and security updates); after that, extended support "requires an additional fee" and is offered only on Odoo.sh, for a limited number of versions, and on-premise (Odoo standard and extended support). The same table shows that standard support for Odoo 17.0 ended in September 2026, and lists the planned end as September 2027 for 18.0, September 2028 for 19.0 and September 2029 for 20.0. If you still run 17.0, this moment has already passed.

The deadline depends on hosting. On Odoo Online a major-version upgrade is mandatory every two years; on Odoo.sh you get two more years after the three years of support; a self-hosted database can stay on its version indefinitely, which Odoo does not recommend (Odoo upgrade documentation).

Custom code is what makes an upgrade a consulting question. A database with custom modules "cannot be upgraded until a version of your custom modules is available for the target version", and the subscription agreement leaves it to you to validate the upgraded database, "to analyze the impact of changes and new features implemented in the Target Version", and to adapt extensions that are not covered (Odoo Enterprise Subscription Agreement, §4.3).

One detail catches teams out. Upgraded test databases are neutralized: scheduled actions are disabled, outgoing mail servers are replaced by a fake one, payment providers and delivery carriers are reset to test mode, and bank synchronization is off (Odoo upgrade documentation). A test plan that only clicks through screens misses those flows.

What you should get: every custom module and Studio change with a keep, replace-with-standard or retire decision; a test plan covering your real business flows, including the neutralized ones; and the order of work. Our Odoo migration service carries out the upgrade once those decisions exist.

5. When you add a company, a country or a warehouse

Expansion re-opens early decisions. A subsidiary in another country needs its own company and localization, per the branch rule above. A second warehouse or a logistics provider raises questions with no single right answer: a shared or separate product catalogue, which warehouse fulfils which orders, how inter-company sales and purchases post.

What you should get: a diagram of the target structure, the settings each new company needs, and test scenarios for inter-company and inter-warehouse documents, run in a copy of production before the new entity trades.

6. When people work around the system

Watch for spreadsheets beside Odoo, monthly exports to recalculate tax or margin, data typed twice, and requests for "a report" that turn out to be a process gap. Each workaround has one of four causes: training, configuration, process design, or a genuine gap in Odoo. Only the last needs code.

What you should get: for each workaround, the cause and the fix at the right level, whether training (our Odoo training service), a setting, or occasionally development.

7. When integrations multiply

The first integration is usually planned; the third or fourth tends to arrive one urgent request at a time. The symptoms are duplicate customers, orders in the shop but not in Odoo, and stock levels that disagree between channels.

What you should get: a data-ownership map naming, for each entity (customer, product, price, stock, order, invoice), the system of record, the direction of sync, its trigger, and what happens when one side is down.

When you do not need a consultant

Consulting is overhead when the question has a known answer. You can usually skip it when:

• You need to know how a standard feature works. Use the documentation, Odoo's tutorials and, on Enterprise, a support ticket.
• Something in standard Odoo is broken. That is a Bug and belongs in a support ticket.
• You need one well-specified change, such as a report layout, a field or a small module. A developer is the efficient choice; see our hire-a-developer service.
• It is routine administration: users, access for existing groups, email templates, a new product category.
• Your setup is small and standard: one company, standard apps, no custom code, no history to migrate.

A consultant also cannot take decisions that belong to you. Pricing policy, approval authority and who may post to a closed period are business decisions; a good consultant frames the options and consequences, and your people choose.

A quick self-test for any decision

Answer these for the specific decision in front of you, not for the whole project:

• Will this be hard or impossible to change after go-live or after the first posted entry?
• Has nobody on the team made this decision in Odoo before?
• Does it affect more than one department, and do finance and operations disagree?
• Does the right answer depend on your Odoo version, edition or hosting?
• Has someone quoted custom code without checking whether standard Odoo already does it?
• Would a wrong answer surface later, at month-end, at audit or at the next upgrade?

Two or more "yes" answers on the same decision is a reasonable threshold for bringing in a consultant for that decision. One or none usually means documentation, support or a developer will do.

How to scope a consulting engagement so it stays small

Engagements that pay off are scoped around decisions, not hours:

1. Write down the decisions you need made, usually three to five. "Help us with Odoo" cannot be delivered or accepted.
2. Ask for a written decision record per question. Meeting notes are not a deliverable.
3. Require the work in a copy of your database, a duplicate of production or an upgraded test database, so recommendations come with screens, not slides.
4. Set the exit in advance: the engagement ends when each decision record is signed.
5. Name an owner on your side for each decision. The consultant frames; your owner decides.

A decision record needs no special tool:

Decision:            (one sentence, phrased as a choice)
Options considered:  (each option, with the Odoo setting or feature it uses)
Chosen option:
Why:                 (tied to your process, version, edition and hosting)
What it rules out:   (what becomes hard to change later)
How we will verify:  (the test document, report or reconciliation that proves it)
Owner and date:

What goes wrong with Odoo consulting, and how to spot it

• Slides with no Odoo screens. Nobody has checked that Odoo behaves the way the slides claim.
• Every answer is custom code. Ask which standard screen comes closest and why it falls short. If the consultant cannot show it, the gap has not been analysed.
• Advice not tied to version, edition or hosting. "Odoo can do that" is only true for a particular combination; on Odoo Online, no custom module is possible at all.
• No written decisions. Six months later, advice nobody can find is advice lost.
• An open-ended retainer with no deliverable. Ongoing advice can help during a build, but each period should end with something you can read.
• Marking their own homework. A provider reviewing its own stalled project has a conflict of interest, however honest it is.
• Ignoring the upgrade path. Any recommendation that adds custom code should say who adapts it at the next version.

Where Odovation fits

Our Odoo consultancy service follows the order this guide describes: a business assessment, then solution architecture (apps, hosting, integrations and a phased roadmap) and a business case, with oversight during the build if you want it. Consultancy can be engaged on its own, for an upgrade assessment, a company-structure review or a second opinion on a stalled project; implementation is a separate decision. If you know which decision you are facing, send it to us and we will give you a straight answer on whether it needs a consultant at all.

Frequently Asked Questions

Does an Odoo Enterprise subscription include consulting?

No. The Odoo Enterprise Subscription Agreement limits support tickets to Bugs and guidance on standard features, and states that development or customization questions may need a separate service agreement. Problems caused by a defective installation or configuration are not Bugs, so design and configuration decisions fall outside support.

Can we implement Odoo without a consultant?

Sometimes. A single company on standard apps, with no custom code and no history to migrate, can often be set up from the documentation with careful testing in a duplicate database. Several legal entities, countries, custom modules or integrations multiply the decisions that are hard to reverse, and that is when a short engagement costs less than correcting a wrong decision later.

When is the best time to bring in an Odoo consultant?

Before you sign, and in any case before the first accounting entry is posted, because Odoo's fiscal localization documentation only allows selecting another localization package if no entry has been posted. After go-live, the natural moments are before a version upgrade and before expanding into a new country or company.

Do we need a consultant for an Odoo version upgrade?

You do if you run custom modules, Studio changes or integrations. Odoo's upgrade service converts the database, but the subscription agreement leaves it to you to validate the result, analyse the impact of the new version and adapt extensions that are not covered, and custom modules must be ready for the target version before the upgrade can run.