How We Rescued a Business Held Ransom Over Their Own Odoo.sh Database

The situation

A services business in regional Australia had been using Odoo for about two years. Their Odoo partner had set up the system, handled the hosting on Odoo.sh, and provided ongoing support. The relationship had been fine — not great, but functional.

Then the client decided to switch partners. The reasons were typical: slow response times, costs creeping up, and a feeling that they weren't getting value for money. They found a new partner (not us, at this stage) and gave their current partner notice.

That's when things got ugly.

What went wrong

The partner controlled everything

The Odoo.sh subscription was under the partner's account, not the client's. This is more common than you'd think. Many Odoo partners set up Odoo.sh projects under their own umbrella account — sometimes for legitimate operational reasons, sometimes for leverage.

The result: the client had user-level access to their own Odoo system, but they didn't have administrative access to the Odoo.sh platform itself. They couldn't:

• Download a backup of their own database
• Access the Git repository containing their custom code
• Manage the Odoo.sh subscription or billing
• Invite a new partner to the project
• Migrate the database to another hosting provider

The partner refused to cooperate

When the client asked for their database and codebase to be handed over, the partner stalled. First it was "we'll get to it next week." Then it was "there are outstanding invoices that need to be settled first" — invoices the client disputed. Then it was silence.

The client was stuck. Their entire business ran on this Odoo instance — CRM, accounting, project management, timesheets, invoicing. Hundreds of thousands of dollars of financial data, years of customer history, and active projects — all locked behind an account they didn't control.

How we got involved

The client reached out to us after finding tryexcept online. They were frustrated and anxious — they needed their system to keep running, but they needed to break free from a partner relationship that had become adversarial.

We started with an honest assessment of their options:

• Option 1: Negotiate directly with the partner — We helped the client draft a formal request for database transfer, citing their rights to their own business data under Australian law.
• Option 2: Escalate through Odoo — We contacted Odoo SA directly, explaining the situation. Odoo has processes for partner disputes, and in cases where a client's data is being withheld, they can intervene.
• Option 3: Legal notice — As a last resort, we recommended the client engage a solicitor to send a formal demand letter.

What we did

Phase 1: Getting the data out

We pursued Options 1 and 2 simultaneously. Through Odoo SA, we were able to establish that the data belongs to the client, regardless of whose account the Odoo.sh subscription sits under. Odoo's support team were helpful once the situation was explained clearly with documentation.

After two weeks of back-and-forth — and a formal legal notice from the client's solicitor — the former partner finally provided a database dump and the Git repository.

Phase 2: Auditing what we received

We didn't trust the handover blindly. We verified:

• The database dump was complete and not corrupted
• All filestore attachments (PDFs, images, documents) were included
• The Git repository contained all custom modules
• No data had been tampered with or deleted
• Financial records matched the client's last known state

Everything checked out — though we did find that the "custom modules" were largely just configuration exports wrapped in module scaffolding. The client had been paying for custom development that was mostly standard Odoo configuration.

Phase 3: Migration to self-hosting

The client didn't want to be in this position again. They asked us to migrate them to self-hosted Odoo on infrastructure they owned and controlled. We set up:

• A managed VPS with the client as the account owner
• Odoo deployed with proper production configuration (workers, memory limits, proxy)
• Automated daily backups to a separate storage location the client controls
• SSL certificate, monitoring, and alerting
• Full documentation of the server setup — the client can take this to any provider

The migration from Odoo.sh to self-hosted took 3 days, including DNS cutover and verification. Zero downtime for the client's staff.

The lesson

This situation was entirely avoidable. The core issue wasn't technical — it was ownership and control. When your Odoo partner controls your hosting account, your database backups, and your code repository, you're not a client — you're a hostage.

How to protect yourself

• Own your Odoo.sh subscription — The Odoo.sh project should be under your company's Odoo account, not your partner's. Your partner can be added as a collaborator.
• Have admin access to your hosting — Whether it's Odoo.sh, a VPS, or on-premise, you should have root/admin access. If your partner won't give you this, that's a red flag.
• Keep your own backups — Even if your partner manages backups, maintain an independent backup that you control. Automated, off-site, tested regularly.
• Own your code repository — If custom modules are developed for you, the Git repo should be under your account (GitHub, GitLab, Bitbucket). The partner can be a contributor.
• Get it in the contract — Your agreement should explicitly state that all data, code, and configurations belong to you, and that the partner will provide a full handover within a reasonable timeframe upon termination.
• Test the exit — Before you're in a crisis, verify that you can download a database backup, access the Git repo, and log into the hosting dashboard. If you can't, fix it now.

Stuck in a similar situation?

If you're locked out of your own Odoo system, struggling to get data from a former partner, or want to migrate to infrastructure you control — get in touch. We've been through this before and we know exactly how to handle it. We'll get your data back and set you up so this can never happen again.