Skip to Content

Odoo Community vs Enterprise: migrating to my own server

Why I left Odoo Enterprise online, how I migrated, and who I recommend it to.
November 10, 2026 by
Odoo Community vs Enterprise: migrating to my own server

Migrating my ERP: from Odoo Enterprise online to Odoo 19 Community on my own server

Sector: ERP, information systems, self-hosting

Period: August 2026, then day-to-day operation

Role: client and implementer, for my own companies

In August 2026, I left my online Odoo Enterprise subscription for Odoo 19 Community, installed on my own server. Here is Odoo Community vs Enterprise as I lived it: why I left, how the migration went, what got stuck, and who I would (or would not) advise to do the same.

Background

I was using Odoo Enterprise in its online (SaaS) version to run all my administration: four websites, two companies, three languages (French, English, Spanish), accounting, CRM, the online shop, appointments, a blog and online courses. Over the years I had also adapted the tool with Odoo Studio, Odoo's no-code editor, in particular to build a data model specific to an insurance business.

From one year to the next, when the subscription came up for renewal, Odoo started charging for custom code. With Studio, I had built a filter to sort and rank leads with Marketing Automation, and it counted as lines of code. Beyond a certain number of lines, you pay: in my case, my extra lines cost me about USD 150 more per year on the subscription. Odoo's subscription agreement describes the mechanism: code-based customisations, including those built with Studio, are charged monthly per block of 100 lines of code. And its public pricing page adds that installing Studio or adding a company to your database automatically moves you to the "Custom" plan. I was in both situations.

Problem

The question was not only the price. It was: what am I paying for, and what do I get out of it?

  • My customisations were locking me further into the most expensive plan, even though they were modest.
  • With Claude Code, Anthropic's AI tool that writes and tests code, I could now write proper Odoo modules myself, where Studio only allowed adjustments.
  • Odoo is twenty-five years of successive layers: menus, screens, settings. Learning all of it is expensive, and I had no wish to impose it on anyone working with me.
  • My data stayed with the vendor, and programmatic access (the API) is part of the most expensive plan.

The goal: keep everything useful, lose no history, and take back control of the tool.

Solution

1. Take inventory before touching anything

I retrieved the full backup of my database from Odoo's interface, then restored it on my server, as is, as a reference database. First finding: 215 of the installed modules had no equivalent in the Community edition. I sorted carefully: what I keep (websites, shop, CRM, accounting for two companies, projects, events, online courses), what I drop (payroll, helpdesk, subscriptions, social media, which I either did not use or already covered with other tools).

2. Convert the database rather than re-import everything

Instead of creating an empty database and re-importing the data, I converted a copy of the original database. The tricky part: uninstalling a module also deletes what it created. The data built with Studio (the insurance model and its 162 custom fields) would have disappeared in cascade. So I detached it from the Enterprise modules before uninstalling them. It survived, forms included.

3. Replace what is missing with proven open-source modules

For accounting, I used modules from the OCA (Odoo Community Association), the community that maintains hundreds of open-source Odoo modules: financial statements, balance sheet and profit and loss, VAT balances, bank statement import, reconciliation, fixed assets, automatic exchange rates. For online appointments, an OCA booking module, plus a public booking page. I avoided app-store modules without a serious track record.

4. Write what exists nowhere else

Four in-house modules, written with Claude Code and reviewed by me: syncing my availability with my calendar, with a video-conference room created for each appointment; translation and usability of the booking page; the origin of each calendar event; automatic statement import from an online bank account.

5. Switch the websites over, then secure operations

On 22 August, the four domains were pointed to the new server, with certificates, outgoing e-mail and scheduled tasks put back in order. Then came the foundations: daily backup, off-site copy, restore test, website monitoring, manual and controlled updates, never automatic ones. The original database stays on the server, read-only and invisible from the web. It has already helped me restore items lost along the way.

What was hard

I will not pretend everything went smoothly. The real obstacles:

  • Translations. On a three-language website, a careless edit to a translated page overwrites the other two languages. You have to work language by language, and check.
  • Invisible settings. On first start, one missing setting put every image in error. The public booking page, for its part, only existed in English: I translated it.
  • What Community lacks. Some tax localisations, such as the mandatory e-invoicing of certain countries, are Enterprise-only. I had to go through an external provider's portal.
  • Operations. In September, an automatic update of the container engine stopped the ERP, which did not restart on its own: eight and a half hours of downtime. It is fixed and tested, but this is exactly what an online subscription spares you from handling.

Result

  • A single Odoo 19 Community installation for four websites and two companies, in three languages.
  • History preserved: accounting entries, contacts, opportunities, pages, blog posts, online courses.
  • The original database kept as a read-only reference.
  • In-house modules that do exactly what I need, versioned and documented.
  • And above all, an ERP I run in plain language.

That last point changed the way I work. An MCP server (Model Context Protocol, the protocol that lets an AI connect to a piece of software) links Odoo to Claude. I no longer click through menus: I ask. "Find the unreconciled supplier invoices", "translate this page into English and Spanish", "prepare the month-end close". The AI does the work in Odoo, and I check it. I describe the setup in the claudeVPS article. Direct consequence: no need to train anyone on Odoo's screens. Odoo 20 also offers an MCP connection, but its built-in AI features now consume paid credits.

Odoo Community vs Enterprise: who I recommend it to

I recommend it if…

  • you customise Odoo, run several companies or want to connect other tools through the API;
  • you want to keep your data in-house and choose the AI that works on it;
  • you have someone, in-house or external, to operate the server: backups, updates, monitoring.

I advise against it if…

  • you depend on Enterprise-only apps (payroll, helpdesk, Studio, some tax localisations) with no open-source alternative that suits you;
  • a single company with no customisation is enough for you: the online Standard plan remains simpler;
  • nobody will look after the server. A self-hosted ERP without operations is an outage waiting to happen.

What I take away

The Community edition is not "free Enterprise". It takes work at the start and discipline afterwards. But completed with OCA modules, code written with AI and plain-language access, it gives me more possibilities than the subscription I left. The real difference is not in the features: it is in owning the tool.

If you are asking yourself the question for your business, I can help you decide, then migrate and operate. See Your tools and your data, or book a 20-minute call.

Sources

Tags: Odoo, Odoo Community, Odoo Enterprise, ERP migration, self-hosting, OCA, MCP, Claude Code

DataTerra — Territorial intelligence, from satellite to drone
Geospatial reports, drone services and software for operators