Odoo Support After Go-Live: What You Are Actually Buying

The support proposal arrives after everybody has stopped paying attention. The project is delivered, the last invoice is settled, and a two-page document appears carrying one number and a list of reassuring nouns: maintenance, monitoring, assistance, updates, priority handling. Nobody interrogates it, because interrogating it feels like distrust at the moment the relationship is warmest.

Eleven months later there is an argument, and it is almost never about the number. It is about whether the thing that went wrong was covered — and both sides are sincere, because the document was written in a vocabulary that let each of them read it differently. That argument is avoidable, and avoiding it costs about two hours at the point where nobody wants to spend them.

In this region the document is often called an AMC — an annual maintenance contract — a term inherited from equipment. A chiller either runs or it does not. A business system fails in a dozen partial ways that are not failures at all, and most of what you will ask for in year two is not maintenance at all.

Four products wearing one word

Before you look at the price, separate what it is paying for. There are four things, they have almost nothing in common, and they are routinely sold as one line.

Break-fix. A scheduled job stops running, a report throws an error, a posting rule that behaved for six months meets a document shape it has not seen. This is the only one of the four that is genuinely unpredictable, and so the only one with the economics of insurance: a known amount against an unknown one.

User questions. How do I credit a partially delivered invoice. Why does this report show a figure the other one does not. These are not defects. They are the residue of training, and their volume is a statement about your induction process rather than about the software.

Change requests. A new report, an extra approval level, a tax code, another entity. None of this is support in any meaningful sense — it is development, because it produces something that did not exist before and that somebody now owns forever.

Version work. Everything that must happen because the software moved. A project with a test plan, not a ticket.

If a single monthly figure covers all four, you have bought a bundle whose composition nobody can describe, the supplier included. The damage is diagnostic. At the end of year one you want to know one thing: is this system fragile, or are these people undertrained? Different problems, different remedies, different owners — and a bundled fee makes the question unanswerable. A supplier who reports tickets by cause, separating defect from design gap from training gap from data, hands you the answer every month for nothing. That is the split that makes post-go-live measurement useful at all, argued in what to measure in the ninety days after go-live, and it belongs in the contract as a reporting obligation — not least because under a flat fee the supplier's margin improves every time you do not call.

The four shapes a support price comes in

There is no correct structure; anybody who says theirs is the honest one is describing their cost base rather than your risk.

A percentage of licence value is administratively simple and structurally wrong: support effort scales with what was built, not with how many people log in. Two systems with identical licence values — one lightly configured, one carrying three integrations and a bespoke document pack — generate entirely different workloads, so one buyer subsidises the other, and rarely the complicated one at that. The five-year version of that arithmetic is the five-year number.

A retainer with a bucket of hours is easy to govern once you settle what is usually left silent: whether unused hours roll forward, what the minimum increment charged against a ticket is — rounding every two-minute answer up to an hour moves the effective rate more than any negotiation on the rate — and whether the bucket covers change requests or only defects.

Time and materials is the cheapest structure for a stable system and the most honest. Its hidden cost is behavioural: when every question carries a visible price, your team stops asking, and a company that has stopped asking is accumulating workarounds.

Fixed cover against defined severities buys availability rather than hours. It suits an exposure that is a stopped operation rather than an unanswered question, and it is correctly the most expensive, because the supplier carries capacity you may never use.

Five questions then decide what any of them costs: what counts as a chargeable unit, whose clock measures it, what hours the cover runs, what carries forward, and who may authorise spend. Every dispute we have seen about a support invoice traces to one of them being unwritten.

Response time is not resolution time

Read any support contract and count how many times it commits to a response. Then count the commitments to a resolution.

The asymmetry is almost total, and it is not a trick. A response is an acknowledgement: somebody read the ticket, classified it and said what happens next. It is cheap, measurable and entirely within the supplier's control. A resolution depends on what the defect turns out to be — a configuration error fixed in ten minutes, a behaviour in the core product neither of you controls, or a problem nobody can reproduce until your accounts team recreates the document that caused it. So a supplier can hit every response target with perfect discipline while your invoicing has been unusable for two days.

Do not react by demanding resolution guarantees on everything: a supplier who offers them is either pricing a large margin for the ones they cannot control, or planning to argue about severity when the moment comes. Ask for three things instead.

Severity defined by the business, not by the module. Severity one is not "an error in Inventory". It is "no goods can be despatched", "no invoice can be issued", "payroll cannot be run", "the statutory return cannot be produced". Write those yourself: the supplier's version will be organised around their team structure, not your month.

A workaround obligation, separate from the fix. What matters when the warehouse is standing still is that you can transact again by whatever route, not that root cause is understood. A contract naming only the fix leaves you waiting for a diagnosis while trucks queue.

Reported resolution times, even where they are not guaranteed. A supplier who publishes their median time to restore by severity is accountable in the only way that survives a hard defect.

And write down the working week. Engineers who work Monday to Friday and a warehouse that despatches on Saturday make a contract that reads as covered and is not. State the hours, the public holidays, what changes in Ramadan, and what an out-of-hours call costs.

Hypercare ends on a date somebody chose

Hypercare is the intensive period after go-live when the people who built the system are still holding it. It is priced inside the implementation and always has an end.

Define that end as a stated number of weeks after the actual go-live date, never as a calendar date. Go-live dates move, and a hypercare period pinned to a date silently shortens every time the project slips — which is exactly when you need it most.

Then consider the following morning. During hypercare you are supported by named people who were in the room when your approval matrix was decided. Afterwards you are supported by a queue, staffed by competent people who were not. What has to cross that boundary is context, and context does not transfer by goodwill. It transfers as a deliverable, and belongs in the implementation contract as one: the configuration decisions and the reasoning behind each, the customisation register, an integration map naming the owner at the far end of every interface, the scheduled jobs and what breaks if each fails, and the master-data standards. If that pack does not exist on the last day of hypercare, the support contract you are about to sign is a contract to have your own system explained back to you at a consultant's rate.

The behavioural half of this period — the doubt, the fatigue, the workarounds hardening into procedure — is a separate subject, set out in why the most dangerous day of your project is not day one.

Your custom code has a clock on it, and the clock is not yours

Odoo publishes standard support for each major version for three years, covering helpdesk support, bug fixing and security updates; beyond that window, extended support is available for a mandatory additional fee. That is a clock, and it runs whether or not anybody in your company is watching it.

Here is the part that decides the money. Odoo's support covers Odoo. It does not cover the module somebody wrote for you, the report built to your document design, or the interface to your bank or your e-invoicing provider. At every version change each must be reviewed, adjusted and re-tested — and the re-testing is yours whoever does the technical work, because only your people can say whether the output is right.

Which means the customisation register produced during implementation is not documentation. It is a forecast of your future support cost, and should be read as a price list. Every entry needs five columns: what it does, which business rule it encodes, which standard objects it touches, who asked for it, and who signs off that it still works. Add a sixth — the effort to carry it across one version — and refresh it annually. Without that column it is a list; with it, a budget line that appears in your model before your inbox. It is also the strongest argument for keeping the register short, a decision taken during the project and drawn in configuration or customisation.

Write the exclusions down, in the contract, on purpose

An unstated exclusion is not a saving. It is an argument with a later date on it.

Buyers resist this because a list of exclusions reads as a list of things the supplier will not do. It is the opposite: exclusions are what make the inclusions mean something, and each exists whether or not it is written. The mistake is to write the exclusion and stop. Each needs a route by which it is bought, or you have not excluded the work, only made it slow.

Commonly excluded	Why	How you should be able to buy it
New reports, fields, screens	It creates something somebody then owns	Fixed day rate, valid for a stated period
Adding users, entities, warehouses	Configuration work with a real duration	Priced per unit, before you need it
Anything arising from a version change	A project, not a ticket	Scoped annually from the customisation register
Third-party and store apps	Their author fixes them, not your partner	Registered, with each renewal date
The far end of an integration	Your partner does not control the other system	Name the far-end owner and their rate
Training and re-training	Continuous, and driven by your turnover	An annual allowance, not a ticket queue
Data corrected after a user error	Otherwise support becomes a cleaning service	Chargeable, and reported so you see the pattern

One definition matters more than the whole table. What counts as a defect? The only workable answer is a departure from written acceptance criteria or documented behaviour. Without them, every "it never used to do that" is an argument about two people's memories, and the party with better records wins regardless of who is right.

That reverses the usual assumption. The boundary of your support contract was not set when you signed it. It was set months earlier, by how well the implementation was documented.

The internal owner, and what they do to your bill

The general case — a system without an accountable person drifts rather than fails — is made in the five-year number. What is specific to a support contract is narrower.

Triage happens before escalation. A supplier receiving raw tickets straight from users is paid consultant rates for a job a competent internal person does better, because they know which of your two Ahmeds raised it and what he was trying to do. Whatever share of your tickets are user questions rather than defects is the share you outsource at the wrong price.

Somebody can say no. Change requests arrive one at a time from whoever is most annoyed. Without an internal owner holding authority, the supplier prioritises by whoever emails hardest, and the system acquires features nobody would approve as a list.

The register stays true. It forecasts your upgrade cost only while accurate, and stops being accurate the first time a change goes unrecorded.

The monthly report gets read. A supplier who sends a report nobody opens will, without any dishonesty, stop putting difficult things in it.

The largest lever on a support bill is not the day rate but whether one named person filters and governs the flow — and the second largest is whether there are two of them, because one internal owner is a single point of failure with annual leave.

The exit question, asked while everybody still likes each other

Support contracts renew until the day they do not, and that is a bad day to discover what you own. Odoo's openness makes leaving possible, not automatic: the lock-in is never the licence, it is undocumented code and credentials in somebody else's account. Ask four questions now, while the answers are cheap.

The database. Not "we take daily backups". A full dump, in your possession, that you have restored somewhere else at least once. A backup nobody has ever restored is a belief, not a control.

The custom modules. Source code, in a repository your company owns, with the licence stated and a note on how it is built and deployed — not a zip file emailed by a developer who has since left.

The documentation. The same handover pack described above, which serves hypercare and exit alike.

The credentials. Domain, DNS, hosting account, the subscription itself, the mail relay, the payment gateway, the e-invoicing provider account. The question about each is whose name is on it — because if your partner is the customer of record for your own subscription, you are a sub-tenant of your supplier, and every conversation about leaving starts from there.

None of this implies distrust of the incumbent. It implies that the incumbent is a company with its own staffing, strategy and bad years. What you buy with these four answers is the ability to change your mind, which is much of what choosing an Odoo partner is really about. If the questions already feel confrontational, that is its own situation with its own sequence: rescuing a stalled Odoo project, not a support negotiation.

The companies that should not buy a support contract from us

We sell support. Read this with that in view: we would rather sell a small contract that gets used than a large one that gets resented into cancellation.

A near-standard system with no custom code and no integrations, hosted by the publisher. If nothing was built, very little can break in a way that is yours to fix, and the platform is maintained by somebody whose entire business is maintaining it. What you need is a block of hours, not a monthly commitment.

A company whose ticket flow has genuinely gone quiet, with documentation and two internal people who know the configuration. Renewing out of anxiety is insurance against a risk you have already retired. Let it lapse, keep a rate agreement on file, and buy help when you need it.

A company whose remaining problem is training. If the tickets are overwhelmingly questions rather than defects, a retainer is an expensive way to run an induction programme. Spend the same money on structured training and an internal super-user network, and the problem shrinks permanently instead of being answered repeatedly.

And the inverse, just as plainly. You need contracted cover if you run custom modules, if an integration's far end is outside your control, if you are self-hosted, if a broken invoice run becomes a compliance event, or if the only person who understands your configuration might resign.

The test takes five minutes. Write down what would happen if the system stopped at the worst hour of your worst week — the last despatch before a holiday, the day the return is due. If the honest answer is "we would email somebody and wait", buy cover. If it is a name, a runbook and a restored backup, you may not need it.

Where this leaves you

Support is the part of an ERP relationship that is negotiated last, priced laziest and lived with longest.

Four things make it work, and none is the rate: knowing which of the four jobs you are buying and having them reported separately; severity defined by what stops in your business, with a workaround obligation as well as a fix; exclusions written down with a purchase route beside each; and a named person inside your company at the front of it, who is the difference between a support contract and a dependency. Everything else follows from documentation that either exists or does not.

If your system is already live and the contract belongs to somebody else, an independent read of what you are paying for, what it excludes and what you would take with you is where an IT governance engagement usually starts. If you are still before signature, the support terms are not a separate document for later — they belong in the implementation contract, alongside the handover pack that makes them enforceable, and that is how we scope an Odoo implementation.

Source note

Odoo's standard support window — three years per major version, covering helpdesk support, bug fixing and security updates, with extended support beyond that period subject to a mandatory additional fee — was checked against Odoo's administration documentation, "Standard and extended support" (https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html), on 26 August 2026. No price for standard or extended support is stated here because we have not verified one. Vendors change support policies; confirm the current position before building it into a budget.