What Happens to a Custom App When Odoo Upgrades?

Odoo ships a new major version roughly once a year, and upgrading a live database, especially one with custom modules installed inside it, is a genuinely well-known risk area. Custom modules need to be migrated to whatever changed in the new version's module API and ORM conventions before they'll even install, view XML can reference fields that moved or were renamed, and any custom Python code that inherited a standard model needs to be checked against whatever changed in that model upstream.

A custom app that lives outside Odoo and talks to it only through the external API isn't part of the Odoo upgrade process at all: there's no module to migrate, no view XML to update, nothing that needs to be reinstalled. It keeps running exactly as it did before, continuing to call the same API methods against the newly upgraded database. The only way it breaks is if the upgrade changed something about the specific fields or methods that app actually calls, which is a much smaller and more predictable surface than "everything installed inside Odoo."

In practice, it's usually one of a short list: a field the app reads or writes was renamed or removed on the Odoo side; a model gained a new required field, so a create call that didn't set it starts failing; a business method the app calls changed its expected arguments; or an access right or security group configuration changed in a way that now blocks the API user from something it used to be able to do. None of these are exotic. They're the same kind of change that could affect any integration against any evolving system.

Before an upgrade reaches the production Odoo database: run the custom app's actual API calls against a staging copy of the upgraded instance first, not production directly. Check Odoo's own release notes for the specific modules the app depends on (Sales, Inventory, Purchase, whichever apply). Confirm the dedicated API user's access rights and any assigned security groups still exist and mean the same thing. And re-verify the field types and shapes for the specific models the app touches, since even a subtle type change (a field that used to be a plain string becoming a selection field, for instance) can cause silent data issues rather than an obvious error.

A meaningful amount. An integration built to fail loudly and specifically (a clear error naming the field or method that didn't behave as expected) is far easier to fix after an upgrade than one that fails silently or produces subtly wrong data. So is one that keeps every Odoo-specific field name and model reference in a small, identifiable part of the codebase rather than scattered everywhere. That turns "check if this upgrade broke anything" into reviewing a short, known list instead of an open-ended search.