Odoo support after go-live: who does what, and what to put in the contract

Go-live is the start of the system's working life, not the end of the project. Within a few weeks, users will ask for a new report, a VAT code will need adjusting, an integration will break after a change on the other side, and a new Odoo version will appear on the calendar. Good Odoo support is what keeps the system trusted by the finance team, the warehouse and the sales desk.

This page explains how support and Odoo maintenance are divided between the publisher and your integrator, what a contract should contain, how upgrades work, what to budget and how to change provider if the relationship no longer works.

What Odoo itself provides

Odoo, the publisher, supports the product through its subscription. According to its pricing page, the included support is unlimited email access on weekdays (24/5), in English, French, Spanish or Dutch. The e-learning platform and version upgrades are part of the package too.

That is useful, but be clear about its limits:

• It covers the standard product, not the way your business has configured it.
• It does not know your chart of accounts, your approval flows or your custom modules.
• It is not a service desk for your users. Questions from the shop floor or the accounts team need a first line that knows your set-up.
• It is an email channel, not a promise of on-site help or a named consultant.

Odoo also lists some services as outside the scope of its upgrade service level, so read the upgrade documentation before assuming that "upgrade included" means "everything migrated for you".

Licences and who may support the code

Odoo 19 Community is released under the LGPLv3 licence. Odoo 19 Enterprise is released under the Odoo Enterprise Edition licence v1.0, which may be used only with a valid Enterprise subscription for the right number of users. In practice, this means a support contract is only half of the picture: the subscription itself must stay valid and sized for the users who actually log in. Backend users count as paying users; portal users, such as customers and suppliers, do not.

What your integrator provides

The integrator is the party that knows your database. Its support offer usually has three layers.

Application support

Incident handling and user help: errors, blocked documents, access rights, printing problems, wrong tax codes, failed bank imports. This is the layer that users feel every day, so it deserves the most detailed definition in the contract.

Application maintenance (TMA)

In French-speaking markets this is called TMA, short for application maintenance; in UK contracts you will see "managed service", "ongoing maintenance" or "application management". It covers:

• preparing and testing version upgrades;
• keeping custom modules compatible with new releases;
• monitoring scheduled actions, mail queues and integrations;
• reviewing user rights and housekeeping;
• applying security and bug-fix patches in agreed windows.

Evolutions

New fields, a changed approval route, an extra connector, a new warehouse, a new company in the group. These are change requests, not incidents, and they should be quoted or drawn from a pre-paid pool of hours. See Odoo customisation for how to keep changes upgrade-safe, and Odoo integrations for the connectors that most often need ongoing care.

Splitting the work: a practical table

Versions, upgrades and support life

Maintenance planning rests on the way Odoo versions are supported. Each major version receives three years of standard support after its release, on Odoo Online, Odoo.sh and on-premise installations. Extended paid support exists afterwards, but only on Odoo.sh (for a limited set of versions) and on-premise. Security fixes are provided only during standard support; in extended support, assistance and bug fixes remain possible only where technically feasible.

According to the supported-versions page:

Two consequences follow.

1. A system on a version past standard support has no security fixes from the publisher. For a business that handles customer data, payroll and bank details, that is a governance issue, not only a technical one. Ask your integrator to show you the support horizon of your version at every annual review.
2. Intermediate "SaaS" versions are a different path. They appear every two to three months, exist only on Odoo Online and carry no extended support. They suit teams happy to follow a fast cadence; many UK mid-sized businesses with custom modules prefer to stay on major versions.

On Odoo Online and Odoo.sh, upgrading to a major version is mandatory every two years, and intermediate versions must be upgraded within weeks of the next release. A notice is sent in advance. The upgrade procedure includes obtaining an upgraded test database so that the new version can be validated before production. Use it: run your month-end close, a VAT return, a payroll run and your most complex sales cycle on the test copy before approving the date.

Read Odoo versions and editions to choose between versions, and Odoo migration if you are moving from another system or from a much older Odoo.

UK points to cover in your maintenance contract

A UK business has compliance deadlines that do not move for an upgrade window. Make sure the contract speaks to them.

• VAT and Making Tax Digital. Who checks that the VAT configuration, the tax mapping and the digital submission route still work after each change? Our guide to Making Tax Digital and your ERP lists what to verify. Your accountant should know the planned upgrade date.
• Payroll and RTI. If you run payroll through Odoo or through a connected tool, a release must not interrupt Real Time Information submissions. See payroll and RTI in an ERP and Odoo payroll and HR.
• Month-end and year-end. Ask the integrator to avoid upgrades and large deployments during closing periods, and to be reachable for the first close after a change.
• Multi-site and multi-nation set-ups. A group with sites in England, Scotland, Wales or Northern Ireland may need support hours that match the busiest sites, and an escalation path that does not depend on one person.

What to ask for in an Odoo support contract

A contract should make the service testable. The main items:

Scope and exclusions

List the modules, databases, environments (production, staging, test) and integrations covered. State clearly whether custom modules are covered, whether third-party apps from the Odoo ecosystem are covered, and what happens when an external supplier is the cause of a fault.

Service levels

Ask for response times and, separately, resolution targets by severity: system down, major function blocked, minor issue, question. Hours of cover matter more than headlines: a business with an early warehouse shift or weekend e-commerce trade may need more than office-hours cover. Agree how the clock starts and stops, and how the integrator reports on performance.

Channels and first line

Define how users raise a request (ticket portal, email, phone), who may raise it, and whether your key users filter requests before they reach the integrator. A named contact and a back-up reduce delays on complex cases.

Upgrades and patching

State who plans upgrades, how many test cycles are included, what happens to custom modules that break, and what is billed outside the contract. Without this, the upgrade becomes a surprise quotation.

Evolutions and reporting

Set a method for estimating and approving changes, a backlog you can see, and a regular review to prioritise it. Quarterly reviews work well for most businesses.

Security, backup and continuity

Clarify who owns backups, restoration tests, access management and the handling of leavers. If the system is self-hosted, see Odoo hosting and cloud for the options.

Documentation, ownership and exit

Require that custom code, configuration notes and the list of installed apps are yours, delivered on request. This is the clause that makes any later change of provider possible.

What to budget

Do not look for a single figure. A realistic budget for Odoo maintenance is made of separate lines:

• the Odoo subscription, sized to the backend users, with the plan you need; see Odoo pricing for the published formulas;
• the integrator's support fee, typically monthly, which depends on the number of users, the number of custom modules, the hours of cover and the service levels;
• an upgrade allowance, since each major upgrade is a project in its own right, sized by the volume of customisation;
• an evolution pool of hours or credits for changes;
• hosting and monitoring, if you do not use Odoo Online;
• training for new joiners and for new features; see Odoo training.

A heavily customised system costs more to maintain than a near-standard one, because every custom module is code that must be tested at each release. That is one more reason to challenge each customisation before it is built. For the build phase, see Odoo implementation.

Changing support provider

Companies change provider for ordinary reasons: slow responses, staff turnover at the integrator, a growing group that needs more cover, or a first partner that was chosen mainly for the implementation. A change is manageable when handled in order.

1. Check your contract. Look at notice periods, ownership of code and any handover duties.
2. Collect the assets. Source code of custom modules, access to the database and server, the list of installed apps, integration credentials, user lists and open tickets.
3. Commission an audit. The incoming provider reviews the database, the customisations and the version status. This is the same exercise as in Odoo audit and project rescue, and it avoids inheriting hidden problems.
4. Plan a handover period. Keep the previous provider reachable while the new one takes over incidents, and avoid switching in the middle of a close or an upgrade.
5. Reset the service levels. Use the change to correct what was missing in the old contract.

If you are choosing a new partner, how to choose an Odoo partner and our wider guide to choosing an ERP integrator set out the questions to ask. Our introduction service is free for you: we match your needs with an integrator and do not carry out the project ourselves.

Keeping support costs under control

Several habits reduce both the number of tickets and the size of the bill.

• Appoint key users who handle first-line questions and filter requests.
• Keep a register of customisations, with the reason each one exists.
• Stay close to standard. Every custom behaviour is a future test.
• Review the backlog of evolutions at set intervals rather than ticket by ticket.
• Upgrade before the end of standard support, not after.
• Document the processes as well as the system, so that a change of staff does not trigger a flood of questions.

If you are still comparing options before you commit, see the Odoo alternatives page, and for the UK context, Odoo in the UK. To discuss support for an existing or planned Odoo system, use our introduction service and describe your users, your customisations and your hosting model.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.