What an Odoo partner handover should include

Most companies that change Odoo partners do it for ordinary reasons: the partner has moved on to bigger projects, response times have drifted, the original consultant left, or the company simply wants its system on a server in its own name. Whatever the reason, the handover goes best when you already hold everything you need before the conversation starts.

This is the checklist we would want any company to run through, whether or not it is leaving. Every item is something you should hold anyway, for the same reason you keep a copy of your own insurance policy. A good partner hands all of it over without fuss, and asking for it is a normal part of owning a business system.

1. The database, in a form you have restored yourself

A database backup you have never restored is a hope, not a backup. Ask for a full PostgreSQL dump of production, then restore it somewhere that is not the partner's server and log in.

• Self-hosted by the partner: a pg_dump in custom format (pg_dump -Fc) or the zip that Odoo's database manager produces, which contains dump.sql, the filestore and a manifest.json.
• Odoo.sh: Odoo.sh keeps seven daily, four weekly and three monthly backups of production, including the filestore, and the project's Backups tab lets you download them. Make sure someone at your company has access to the project.
• Odoo Online: the database administrator can download a zip from the database manager on odoo.com. The partner does not need to be involved at all.

Write down the exact Odoo version, including the minor version (for example 17.0 or saas~17.2), and the PostgreSQL version it came from. The manifest in an Odoo backup zip records both.

2. The filestore, which is not in the database

Odoo stores attachments, product images, scanned bills and generated PDFs as files on disk, under the server's data directory in filestore/<database name>. The database only holds pointers to them. A dump without the filestore restores cleanly and then shows broken images and missing attachments everywhere.

A quick sanity check after restoring: open a few old vendor bills with scans attached, a product with an image, and a sent invoice. If they open, the filestore came across.

3. The code, with its full history

A zip file of the current custom modules is not enough. You want the git repository itself, with every branch, tag and commit, because the history is the only record of why something was changed and who changed it.

• A full clone of the repository (git clone --mirror keeps every branch and tag), or better, ownership of the repository moved to an account your company controls.
• Every git submodule listed in .gitmodules, with access to each one. Private submodules on the partner's account are a common gap: the main repository clones fine and then the submodules fail.
• The exact commit deployed to production today, so you can tell the running code from work in progress.
• Python dependencies (requirements.txt or equivalent) and the addons_path order used in production.
• For paid modules from the Odoo Apps Store: which odoo.com account bought them. Downloads and updates for new versions come from that account.
• For Odoo.sh: which GitHub account or organization owns the repository the project builds from.

Check the contract for who owns custom code. Many implementation agreements assign it to the customer; some license it instead. Either way, it is better to know before the conversation than during it.

4. The server configuration

If the partner hosts Odoo on their own servers, ask for the non-secret parts of the setup: the Odoo configuration file with passwords removed (workers, memory and time limits, proxy_mode, db_maxconn, max_cron_threads, data directory), the reverse proxy configuration, the service definition, and the operating system, Python, PostgreSQL and wkhtmltopdf versions. The last one matters more than it sounds: PDF reports can render differently on a different wkhtmltopdf build.

5. Credentials and accounts

The goal is that nothing important depends on a login only the partner holds.

• An administrator user in Odoo that belongs to a person in your company, with two-factor authentication on.
• The database manager master password (admin_passwd in the config file), if the partner self-hosts.
• The hosting account: who is the owner of record, and can you be made one?
• Domain registrar and DNS provider logins. These are often registered by whoever set up the website years ago.
• The Enterprise subscription, if you have one: whether it is contracted directly with Odoo S.A. or through the partner, and who is named as the customer. Odoo's own support can tell you.
• API keys created for integrations, and which Odoo user each one belongs to. A key tied to a partner employee's user stops working when that user is archived.

6. Integrations

List every system that talks to Odoo, and for each one note who holds the account on the other side: payment providers and their webhooks, shipping carriers, bank feeds, e-commerce connectors, tax services, EDI, marketplace connectors, and any script someone wrote that calls Odoo's API. OAuth apps for Google or Microsoft sign-in and mail sync are registered in someone's cloud tenant; find out whose.

Webhooks and OAuth redirect addresses point at a specific domain. If the domain changes during a move, each one has to be updated on the other side.

7. Scheduled actions

Scheduled actions (Settings, Technical, Scheduled Actions, visible in developer mode) run on their own: sending reminders, fetching mail, syncing stock with a web shop, posting recurring entries. Export the list of active ones with their interval, next run and the user they run as. A custom scheduled action that emails customers is the kind of thing that fires unexpectedly from a restored copy, which is why every test restore should be neutralized (more on that below).

8. Mail setup

Mail is the piece most often forgotten until invoices stop going out.

• Outgoing mail servers and incoming mail servers configured in Odoo, and the mailbox accounts behind them.
• The catchall and bounce aliases and the alias domain, which decide where customer replies land.
• The DNS records that make mail deliverable: MX, SPF, DKIM and DMARC. If Odoo sends as your domain, those records must allow the server it sends from.

9. DNS and the website

Export the full DNS zone for every domain Odoo uses: the main site, the Odoo address, mail, and any portal or shop subdomain. Note the TLS certificate setup. A cutover is mostly a handful of DNS changes, and they are much calmer when you already have the zone file.

10. Backups and documentation

Ask where backups are kept, how long they are retained, and when a restore was last tested. Ask for whatever documentation exists: the list of customizations and why each was made, Studio changes, open tickets, known issues and any runbook. Even an incomplete list saves days.

Verify on a copy before you say anything

With the dump, filestore and code in hand, do a trial restore on a machine the partner does not manage. Neutralize the copy first so it cannot send mail, run scheduled actions or call payment and carrier services: Odoo 16 and later include an odoo-bin neutralize command for exactly this. Then check:

• You can log in with your own administrator user.
• The installed module list on the copy matches production, and every module's code is present in your repository.
• Attachments and images open, and an invoice PDF prints.
• Record counts for a few key models (partners, invoices, stock moves) match production on the day of the dump.

If all of that works, you hold your system. Whatever you decide next, stay, leave or renegotiate, you are deciding from a position where the business keeps running regardless.

A note on timing

Do not combine a partner change with a version upgrade. Moving hosting and changing versions at the same time doubles the number of things that can go wrong and makes it hard to tell which change caused a problem. Move first, on the version you run today, and upgrade once the new setup is stable.

What Odoo's own agreements say about changing partners, and the order that keeps the conversation friendly, are on our page about switching Odoo partners. If your Odoo is on Odoo.sh, see leaving Odoo.sh for the platform-specific details.

If the partner has gone quiet, or the project stalled before go-live, our Odoo rescue page describes what to secure first and how a takeover runs.