Owning your system afterwards

The project ends and the partner steps back. What you are left holding decides whether your next five years are cheap or expensive.

The handover pack

Ask for these while you still have leverage — that is, before the final payment.

What	Why you need it
Git repository, in your company’s account	Every custom module with its history. Without it, changing partner means rebuilding.
Module documentation	What each module does, why it exists, what it depends on. Written for a developer who has never met you.
Configuration notes	The decisions: why valuation is set this way, why that tax exists, what the approval limits mean. Screens can be read; reasoning cannot.
Deployment runbook	How to update, restart and restore the system, step by step.
A tested restore	Not a backup policy — evidence that a restore was performed and the result checked.
Training recordings	So new joiners are not a fresh cost every time.
List of deliberate compromises	What was left undone, what was worked around, what was accepted as imperfect. This is the most useful document in the pack in two years.
Admin credentials	In your possession, not only the partner’s.

The last one is not paranoia. Companies discover the partner holds the only administrator account at the worst possible moment.

The backup test

The single most valuable hour after go-live: restore your backup to a spare environment and look at it.

Then check three things: it restored at all, the data is recent, and the attachments came back with it. Backups fail silently and quietly for months. The only proof is a restore.

Repeat once a year. Put it in someone’s calendar with a name against it.

Choosing your support arrangement

Option	Works when	Watch for
Retainer with the implementing partner	You have custom modules and no internal technical people	Make sure it covers questions and small changes, not only outages
Internal admin, partner on call	You have someone capable and enough volume to keep them busy	They need real training and time, not the role added to another job
Ad-hoc, pay per incident	Very simple, standard configurations	Response times are usually poor exactly when you need them

Whatever you choose, agree in writing: what counts as an incident, response times per severity, what is included versus billable, and who exactly answers.

Ask for a monthly or quarterly report — tickets raised, time spent, what keeps recurring. Recurring tickets are usually a training gap or a design problem, and both are cheaper to fix than to keep paying for.

Upgrades

Odoo releases a new version every year, and older versions eventually stop being supported. Upgrading is not optional forever.

Two things determine the cost, and you influenced both during the project:

• How much custom code you have. Every custom module must be reviewed, adjusted and retested at every upgrade. This is the invoice for every “just add this small thing” agreed during the build.
• Whether it is documented. Undocumented customizations have to be reverse-engineered before they can be migrated.

Practical approach: do not upgrade the moment a version ships, and do not wait until yours is unsupported. Roughly every two to three years, planned, budgeted and tested on a copy first. Ask your partner for an upgrade estimate once a year, so it never arrives as a surprise.

Avoiding lock-in

Being tied to one partner is a commercial position, not a technical one. What keeps you free:

• The code is in your repository.
• The database can be backed up and restored by you.
• Documentation is good enough for a stranger to read.
• More than one person in your company understands the configuration.
• Customizations are separate modules, not changes made inside Odoo’s own code.

That last point is worth checking explicitly. If a partner modified Odoo’s core files instead of building proper modules, you cannot upgrade and you cannot easily leave. Ask directly: “Is any of this built by changing Odoo’s own code?” The answer should be no.

An annual review

Once a year, half a day:

USERS ............ who has access, and should they still
BACKUP ........... restore tested on ......  by ......
VERSION .......... running ......  supported until ......
CUSTOM MODULES ... how many, still used, still needed
INCIDENTS ........ recurring themes this year
UNUSED APPS ...... installed but nobody uses them
COST ............. licences ......  support ......  changes ......
NEXT YEAR ........ upgrade planned?  new areas?  training needed?

Companies that do this spend less and are surprised less. It is a slow half day that repays itself the first time it catches an unsupported version or a backup that stopped running in March.