An order recorded twice in the warehouse. An invoice that was not generated correctly, and nobody notices until the customer complains. A custom module someone built two years ago that no employee dares to touch anymore, “in case something breaks.” If any of these sounds familiar, your company has probably reached the point where Odoo stops being “the system that was implemented” and becomes a tool that needs ongoing support, with someone in charge every day, not just when something blows up.

That recurring support, with a scope agreed with the provider, is called ongoing Odoo support. This article explains what it really includes (and what it does not), the signs that you already need it, how it differs from a version migration, and when you may not need it yet.

Implementation and ongoing support: two different services

An Odoo implementation is a project: it has a scope, a schedule and a go-live date. Ongoing support is something else: it starts the day after that launch and stays with the system while the company keeps operating on it, without the fixed end of a project (even though the agreement that governs it has its own term).

  • In the implementation, the goal is for the system to go live working as defined.
  • In ongoing support, the goal is for the system to keep working as processes, staff, data volume and Odoo's own versions change.

Mixing up the two is one of the most common reasons a company ends up with an Odoo instance that “worked fine at first” and later became a problem. The duplicate order at the start of this article can have different causes—a specific configuration, a custom module, an integration with another system or core Odoo itself—and pinning down which one requires a diagnosis, not a guess: that is exactly the kind of review that tends to fall through the cracks once the implementation project “is closed” and nobody is keeping a close eye on the system.

What an ongoing Odoo support service includes (and what depends on the agreement)

Comprehensive ongoing support typically covers:

  • Incident resolution, with a defined channel for reporting issues.
  • Assessment of version upgrades, before deciding whether and when to apply them (not the full migration itself; see below).
  • Maintenance of customizations: custom modules, integrations with other systems (invoicing, payments, logistics) and automations added on top of core Odoo.
  • Monitoring of how the system is running, to catch a performance drop or a recurring error before a user notices.
  • Infrastructure support and functional support: the first makes sure the server and environment are up; the second makes sure the system handles business processes properly. A complete service covers both.
  • Help for the internal team with small requests: a new report, a permissions tweak, a minor process improvement.
  • Backups and continuity, checking that backups exist, are tested and make it possible to restore the system if something goes wrong.

What separates well-designed support from improvised support is not this list (which on paper tends to look similar across providers), but the limits that come with it, because without clear limits the list is an empty promise:

  • What depends on the plan. Not every support agreement covers the same things: hours included per month, number of incidents, whether monitoring is proactive or on request only. This is defined in the agreement, not assumed.
  • Service hours. Ongoing support defines the time window in which incidents are handled (for example, business hours) and whether there is a channel for emergencies outside that window. Without this being defined, “ongoing support” can mean very different things to the provider and to the customer.
  • Response time vs. resolution time. They are two different things and should not be confused: response time is how long it takes someone to pick up the ticket and start working on it; resolution time is how long it takes until it is actually solved. A serious agreement defines both clearly, even if resolution time can stretch when it depends on a third party (Odoo itself, an external integration, a hosting provider): a fast response with no commitment on resolution leaves the problem half-solved.
  • What counts as a “small improvement” and what does not. Adjusting a report, changing permissions or adding a field to a form usually falls within ongoing support. A complete new module, an integration with a system that did not exist before, or a change that affects several processes at once is no longer a small improvement: it is a development with its own scope, quoted and planned separately (even if the same team that provides support carries it out).

Signs that your company needs ongoing Odoo support

Some typical signs that an Odoo instance has been left without proper support:

  • Version upgrades get postponed year after year “because we're afraid something will break.”
  • Each incident is solved by a different person, with no common approach and no record of what was done.
  • Custom modules were built by different providers over time and nobody has a full view of how they interact with each other.
  • When someone on the internal team who “knew their way around” Odoo leaves the company, the knowledge leaves with them.
  • Small improvement requests pile up on a list that never gets addressed, because there is no service dedicated to handling them.

If any of these sounds familiar, you are probably already paying the cost of not having ongoing support, even if it never shows up on a specific invoice: team hours spent fixing problems in a rush, decisions postponed for fear of breaking something, and a growing dependence on whoever knows the system “by heart.”

Maintenance and version migration: two different scopes

Odoo releases a new major version regularly, with functional improvements and technical changes that can affect existing custom modules. It pays to split this into two separate decisions, which are often mistakenly lumped together:

  1. Assessing when to migrate can indeed be part of ongoing support: whoever provides support keeps a close eye on Odoo's release calendar and recommends, on technical grounds, when to upgrade and when to wait one more cycle.
  2. Carrying out the full migration is a separate job: adapting custom modules to the new version, testing that everything still works and doing a dry run in a test environment before applying the change in production, following the path Odoo's own documentation recommends for major upgrades. It is usually budgeted separately, unless the support agreement explicitly covers it.

On end of support for a version, it is worth clarifying a point that is often stated loosely: Odoo distinguishes a standard support period per version from the option, under specific conditions, of buying paid extended support. The end of standard support for the version your company uses does not automatically mean you are left without any kind of assistance overnight: it means there is a decision to make—upgrade within a reasonable time frame, assess whether extended support applies to your case, or migrate—and that decision is best made with time to spare, not forced by an emergency.

When ongoing Odoo support makes sense (and when it does not)

It makes sense when any of the following applies:

  • Odoo runs business-critical processes (sales, inventory, invoicing, manufacturing) and a failure there has a real cost, not just an annoyance.
  • There are customizations or integrations specific to your company that nobody on the internal team fully understands.
  • The internal team is already busy with day-to-day work and has neither the time nor the technical profile to handle upgrades, configuration incidents or monitoring.
  • Depending on a single person (internal or external) to keep the system running is a risk the company does not want to take.

You do not need it, or another arrangement may be enough, when:

  • The company has an internal team with real technical capacity to resolve configuration incidents, follow up on upgrades and maintain existing integrations: in that case an external provider may not be necessary, although the system still needs that maintenance, whoever provides it.
  • Odoo use is limited (few users, simple processes, no critical customizations) and adjustments are occasional, not constant.
  • The company has just migrated and is still within the project's warranty or post-implementation support period: check exactly what that period covers, because it does not always include proactive monitoring or improvements, only fixing defects in the project just delivered.

In these last cases, per-incident support may be enough instead of an ongoing support agreement. The choice depends on how much day-to-day processes rely on Odoo running without interruption, and on whether someone, inside or outside the company, is responsible for making that happen.

How we handle ongoing Odoo support at DCisGlobal

In practice, this is what we do:

  • When we take over an inherited installation—an Odoo instance implemented by another provider or by the internal team itself—we start by mapping its actual state: which custom modules it has, which integrations are active, which version it runs and how far it is from current standard support. We avoid touching production until we have that full map, unless a real emergency requires stepping in sooner: in that case, we keep mapping in parallel.
  • We record decisions, not just resolved incidents: why an upgrade was postponed, why a change was ruled out, which alternative was considered and not used. That keeps someone from reopening, a year later, a discussion that already took place, or repeating a mistake that was already known.
  • We test changes before applying them in production, in a separate environment, especially before a version upgrade or a change to a custom module. The rule is simple: no change that could affect a critical process is applied first to the system the company uses every day.
  • We keep knowledge from living in a single head. We document how each installation is built (configuration, customizations, integrations) so support does not depend on one particular person “remembering how” a customer's system works. If that person is unavailable one day, someone else can keep solving issues.

Imagine an SMB that implemented Odoo two years ago with a freelancer who no longer works with them (this is a hypothetical example, not a real DCisGlobal client). Nobody documented the three customizations in the invoicing system. Every time Odoo releases a new version, the company postpones the upgrade “just in case,” and it is now two versions behind. In a case like this, the first thing we do is not upgrade: it is map what each customization does, document it, and only with that map assess a staged upgrade path, tested in a test environment before touching production.

This service is part of our open-source systems service, where we implement and provide ongoing support for Odoo (and other open-source systems) with this same approach. If your company already uses Odoo and you are not entirely sure what state that installation is in—how up to date the version is, how well the customizations were documented, who responds when something fails—you can start with our self-assessment or book an assessment with the team directly. It helps us evaluate your specific case and define what kind of support makes sense for your company.

Dino Cisterna — DCisGlobal