Almadar A company in KAFD that's customized Odoo without anyone owning ongoing maintenance is one annual release away from a system nobody can safely touch.
Once an Odoo implementation is live, three things need continuous attention: the annual version upgrade, the health of third-party and custom modules, and day-to-day configuration change as the business evolves. Businesses that treat go-live as the end of the project typically find themselves two versions behind within eighteen months, at which point upgrading becomes a project rather than a maintenance task.
Managing the annual upgrade
Odoo releases a major version each year and supports a limited number of prior versions. Upgrading requires testing every custom module, every third-party app and every integration against the new release, then migrating data. Staying current is materially easier than catching up, which is why we plan upgrades as a scheduled annual activity rather than a response to an approaching end-of-support date.
Module health and dependencies
Third-party modules from the Odoo app store carry their own maintenance risk. A module that is no longer updated by its author becomes a blocker at the next upgrade, and this is particularly acute for ZATCA e-invoicing modules where a regulatory change requires a prompt update. We monitor the modules in use, track their maintenance status and flag replacements before they become urgent.
Operational support
Beyond upgrades, support covers what the business actually asks for: a new report, an additional user with the right access rights, a workflow change after a reorganization, a new tax rule, investigating why a stock movement did not post. Much of this is configuration rather than defect, and having it handled by people who know your specific setup is faster than raising it through a generic channel.
A common Saudi scenario
A Riyadh distributor two versions behind current needs a ZATCA specification update applied. The certified e-invoicing module supports it only on newer Odoo versions. What should have been a small compliance update becomes a full upgrade project under deadline pressure, costing several times what an annual upgrade cadence would have.
Support models and knowledge transfer
We scope support to the client's internal capability, from a full managed service to specialist backup for upgrades and integrations while an internal team handles daily configuration. Either way the objective is documented configuration, a maintained module register and a client team that can make routine changes safely, which reduces dependency rather than entrenching it.
Documenting the environment properly
Support is only fast if the environment is documented: which modules are installed and at what version, which are customized and why, which integrations exist and what they depend on, and who holds administrative access. We maintain this register as part of the support arrangement, because the alternative is that every issue begins with an hour of rediscovery. It also underpins customization planning and makes handover between support providers, or back to an internal team, genuinely possible rather than theoretical.
Riyadh businesses relying on community or partner e-invoicing modules face the highest upgrade urgency, since ZATCA specification changes cannot wait for a convenient upgrade window.