Changing Your Odoo Partner: What to Collect Before a Project Handover

Reviewed: 27 October 2026 | References: Odoo 20 documentation and its subscription agreement | Estimated reading time: 9 minutes

Key points

• Establish what changes: service provider, account control or hosting.
• A database backup is not the entire project.
• Do not experiment with an import on the existing production environment.
• Test restoration and essential workflows before approving the handover.

When should you consider changing your Odoo partner?

You may be considering a change because support is slower than your operation needs, or because your requirements now need different expertise. The system may already work, while responsibility for supporting it remains unclear. Before deciding, establish what can remain, what needs to change and what must be tested.

You can start a discussion with ToDoOps by describing the problem and your hosting setup. You do not need to send credentials or a database. The handover package below is prepared before approving the transition; completing it is not a condition for an initial conversation.

Start with the business question: do you need a different support provider, repairs to parts of the implementation, or a hosting move as well? Keeping these needs separate helps define the work and avoids assuming that functioning parts must be rebuilt. This guide combines documented Odoo procedures with our practical assessment recommendations; it does not decide the terms or code rights in an individual contract.

What will actually change?

The service relationship. Who handles requests and acts as your contact with Odoo? The Enterprise agreement addresses a change of service contact and includes a notice requirement when changing the main contact [1]. That does not by itself terminate the implementation agreement with your existing provider or establish an obligation to deliver every piece of code. Check the notice conditions in your subscription and the termination and handover terms of the implementation contract separately.

Database ownership and account access. Who controls the subscription, who is the database administrator, and who can download a backup? Odoo Online database management requires administrator access. Its documentation describes a ZIP backup, but the download option can be disabled for large databases, requiring an alternative through support [2]. The database’s Transfer Ownership procedure is a separate support request; it is not simply another name for changing your partner [2].

Hosting. The database may stay on Odoo Online after changing provider. A provider change does not inherently require a hosting change [3]. A move between Online, Odoo.sh and an on-premises environment needs a version-compatible route. Online’s intermediary SaaS versions are not supported by Odoo.sh or on-premises until a suitable major-version upgrade [3]. Moving back to Online does not permit non-standard modules, and the Custom plan does not mean arbitrary server code can run on Online [3]. Subscription and support coordination may also be required.

Keep the product terms separate when comparing proposals: Standard and Custom are plans; Community and Enterprise are editions; One App Free is a different offer. Odoo.sh hosting, implementation and custom-code maintenance are not simply included in the subscription headline price; their applicable terms and charges need review [5].

The practical handover package

Collect these items with the current and proposed teams, within your permissions and agreements. You do not need every item to request an initial assessment. This is a verification checklist, not a claim that every existing contract requires all of these deliverables.

The import documentation covers database transfer and separately addresses adding modules to the project’s repository [4]. Review data, attachments, code and licences together: possessing a backup file alone does not prove that the handover is complete.

Record your actual version and hosting type. The team needs to match the requirements against that environment before choosing a migration route or recommending an upgrade.

A hypothetical example

A distributor notices slower support and repeated changes to the person managing its account. It explores a different provider without changing its live system.

While preparing a handover checklist, it discovers that the database administrator account is registered to a former employee of the provider and that it has no copy of the custom code. It addresses those gaps, then arranges a backup, restores it in a test environment and checks a complete sales workflow before committing to a transfer date.

This is an illustrative scenario, not a ToDoOps customer case or a project-duration estimate.

Test, restore, accept and prepare a rollback

1. Use a test environment. Online test duplicates are temporary, with external actions disabled by default [2]. Do not turn that default into a guarantee that every copied environment is isolated: inspect the actual settings. An import into Odoo.sh overwrites the target branch’s data, so the existing production branch must not be used for experimentation [4]. The final cutover follows an approved plan after testing and preserving the required recovery copy.

2. Verify restoration. Check that the database runs, users can access it with the intended permissions, and expected balances and records are present. Backups and restoration do not establish a promise of zero downtime or zero data loss. Odoo’s disaster-recovery objectives are not a timetable for a partner handover [6].

3. Accept operating results. Test transactions from your business rather than checking application names: purchase and receipt, sale and delivery, an invoice, a management report, opening attachments and a task under each important role. Record the expected result and the person who approves it.

4. Define rollback before cutover. Establish who decides to return, under what conditions and to which saved state. Agree support responsibility during handover and any necessary overlap. Record the cutover time, who receives incident reports and how transactions created after the last backup will be preserved. Restoring an older copy may exclude those transactions unless the plan accounts for them.

What increases the work, and what can remain?

More work may be needed when custom code is extensive or its ownership is unclear, third-party modules lack documentation, hosting changes as well, or important accounts are controlled outside your company.

Keeping compatible hosting, largely standard configuration, available documentation and appropriate account control can reduce the work. In that situation, the change may concern support responsibility more than a technical migration. This is our analytical assessment, not a rule that determines every project.

For evaluating the proposed provider, use our Odoo partner selection guide. Its questions can be applied to ToDoOps as well as other providers.

Frequently asked questions

How much does changing an Odoo partner cost?

The cost follows the work: support on the existing environment, repairs to custom modules, or a hosting move with broader testing. User count alone does not establish that scope. Start with the problem and hosting type, then establish what can remain before implementation is priced.

How long does a handover take?

Access, documentation, module compatibility, notice requirements, cooperation and acceptance tests affect the schedule. A support-provider change may not need technical migration at all. The project schedule is also different from any planned service interruption; neither should be promised before assessment.

Can the database stay on its current hosting?

It may be possible: service provider and hosting are separate decisions. If a move from Online to Odoo.sh or on-premises is proposed, ask for a requirement-based reason and verify version compatibility, custom modules and subscription terms rather than treating migration as automatic.

What should I prepare before contacting you?

Describe the problem, your business activity, the current hosting if known, and any special modules or connections. That is enough to begin. Do not send passwords, a database or customer records in the first request; any later sharing should follow the assessed need and suitable authority and protection.

Must the system be implemented again from scratch?

Assessment determines that. Working configuration and data may be retained while specific gaps are addressed; an incompatible module may need more work. Request an explanation of what remains and why any part must be rebuilt, supported by a test of the result.

Start by assessing what needs to change

Before choosing a complete migration or accepting a rebuild, establish the problem and the parts that already work. The purpose is to identify what must be collected and tested, what can be preserved and who owns each next step.

Discuss your existing project with ToDoOps. Tell us your activity, the problem you want to resolve and the hosting type if you know it. That starts a focused assessment before a new delivery scope is approved.

References and limits

[1] Odoo Enterprise Subscription Agreement, version 13 dated 24 September 2026: partner/service-contact definitions and notice requirements.

[2] Odoo 20 documentation: Odoo Online management, backup download, ownership transfer and test duplicates.

[3] Odoo 20 documentation: changing hosting, version compatibility and non-standard modules.

[4] Odoo 20 documentation: creating an Odoo.sh project, importing a database, modules and subscription registration.

[5] Odoo’s official pricing page: Standard, Custom, subscription inclusions and separately priced work.

[6] Odoo Cloud Hosting Service Level Agreement: recovery objectives are not a project-specific migration promise.

The checklist, scenario and acceptance suggestions are ToDoOps analytical guidance, not customer results or vendor guarantees. References were reviewed on 27 October 2026. Full source URLs and the claim ledger are retained in the internal editorial record.