Cómo migrar la comunidad Odoo a la empresa sin pérdida de datos

By the end of this recipe, your Odoo Community Edition database will be running on Enterprise with every record intact, every customization preserved, and every user logged back in within five minutes of cutover. Skill required: senior Odoo administrator with shell access to the Linux host. Time required: 4 to 6 hours of hands-on work plus a 30-minute downtime window. ECOSIRE has run this migration 50+ times across versions 15 through 19, and the recipe below is the deduplicated lessons from every one of those projects.

The reason most teams blow up this migration is simple: they treat it like an Odoo upgrade (which is odoo-bin -u all) when in fact it is closer to a side-by-side reinstall with a data graft. Community and Enterprise share the same database schema for stock objects, but they do NOT share the same module set. Modules like web_enterprise, account_accountant, documents, and helpdesk exist only in Enterprise. If you simply swap the addons path and restart, you will get a flood of KeyError: 'account.payment.term' errors at startup because Enterprise extends the Community models with new fields that have not been added yet.

What you will need

• Odoo version: must be the same major version on both sides. You cannot migrate Community 17 to Enterprise 19 in one step. Get to Enterprise 17 first, then run the version upgrade.
• Enterprise license: purchase your subscription from odoo.com or a partner like ECOSIRE before starting. You need the activation key.
• Server access: SSH with sudo to the host running Odoo. Cloud-hosted "Odoo.sh" sites have a different (much simpler) procedure — this recipe targets self-hosted Linux deployments.
• Disk space: at least 3x the current database size. You will keep the original community install around for rollback during the cutover window.
• PostgreSQL access: a psql connection with the database owner role. You will run a small handful of queries.
• Time: 4 to 6 hours active work, 30 minutes user-facing downtime, plus a 24-hour soak period before declaring victory.
• Backup: a fresh pg_dump plus a filestore tarball, both verified by restoring to a throwaway database. "Verified" means you opened the test database in Odoo and clicked through 5 random records.

The hardest part of this migration is not technical, it is communication. Tell the users a week in advance, freeze configuration changes 48 hours before cutover, and keep the original Community instance available read-only for 7 days post-migration so disputes can be settled by going back to source.

Step-by-step

1. Take a baseline inventory

Before you touch anything, capture the current state. Run psql -d production -c "SELECT name, state, latest_version FROM ir_module_module WHERE state='installed' ORDER BY name" > /tmp/modules-before.txt. Also dump record counts for the top 20 models: for m in res.partner sale.order purchase.order account.move stock.picking; do psql -d production -c "SELECT '$m' as model, COUNT(*) FROM ${m//./_}" >> /tmp/counts-before.txt; done. Verification: open /tmp/modules-before.txt and confirm it has more than 50 lines. If your database has fewer than 50 installed modules, you are probably doing this on the wrong database.

2. Download the Enterprise source

Get the matching Enterprise tarball from your Odoo customer portal. Extract it to /opt/odoo-enterprise-19/. The directory should contain about 70 modules including web_enterprise, account_accountant, helpdesk, documents, studio, and the country-specific accounting localizations.

sudo mkdir -p /opt/odoo-enterprise-19
sudo tar -xzf odoo-enterprise-19.0.tar.gz -C /opt/odoo-enterprise-19 --strip-components=1
sudo chown -R odoo:odoo /opt/odoo-enterprise-19
ls /opt/odoo-enterprise-19 | wc -l
# Expected: 65-75 modules depending on the build

Verification: ls /opt/odoo-enterprise-19/web_enterprise/__manifest__.py returns the file. If it does not, you downloaded the Community tarball by mistake.

3. Update the addons path

Edit /etc/odoo/odoo.conf. The addons_path line must list Enterprise BEFORE Community. Order matters: Odoo registers the first module it finds and Enterprise modules extend Community ones.

[options]
addons_path = /opt/odoo-enterprise-19,/opt/odoo/addons,/opt/custom-addons

Do NOT restart Odoo yet. Verification: grep addons_path /etc/odoo/odoo.conf shows the new line and Enterprise comes first.

4. Stop Odoo and snapshot the database

sudo systemctl stop odoo
pg_dump -U postgres -Fc production > /backup/pre-enterprise-$(date +%F).dump
sudo tar -czf /backup/pre-enterprise-filestore-$(date +%F).tar.gz /var/lib/odoo/filestore/production

Both files together are your rollback. If anything goes wrong in the next 30 minutes, you restore from these. Verification: both files exist, and the dump file is at least 80 percent of your raw database size.

5. Activate the Enterprise license

Start Odoo in single-thread debug mode to register the new modules without serving traffic:

sudo -u odoo /opt/odoo/odoo-bin -c /etc/odoo/odoo.conf --workers=0 --xmlrpc-port=8070

In another terminal, open a browser to http://localhost:8070, log in as admin, and go to Settings > Activate Enterprise. Paste your subscription code. Click Save. The system contacts odoo.com, validates, and refreshes the page. Verification: the top-right of every page now shows "Enterprise" instead of "Community".

6. Install the Enterprise module set

Settings > Apps > Update Apps List. Wait 60 seconds for the registry to refresh. Now search for web_enterprise and click Install. This pulls in 30+ dependent modules: account_accountant, mass_mailing, marketing_automation, helpdesk, documents, studio, industry_fsm, planning, appointment, plus any country-specific ones (l10n_us_check_printing, l10n_uk_hmrc_mtd, etc.).

The install takes 8 to 15 minutes depending on database size. Watch the log: tail -f /var/log/odoo/odoo-server.log. Verification: when the dialog closes you should see the new top-bar UI (the unified app launcher with module icons).

7. Run the data migration scripts

Most field additions are handled by the install step (Odoo runs _auto_init and creates the new columns), but a handful of records need backfilling. Save this as /tmp/migrate-enterprise.py and run it via odoo shell:

# Run with: sudo -u odoo /opt/odoo/odoo-bin shell -c /etc/odoo/odoo.conf -d production < /tmp/migrate-enterprise.py
# 1. Backfill default analytical accounts on existing AML rows
self.env.cr.execute("""
    UPDATE account_move_line aml
    SET analytic_distribution = jsonb_build_object(default_account.id::text, 100)
    FROM account_account default_account
    WHERE aml.account_id = default_account.id
      AND aml.analytic_distribution IS NULL
      AND default_account.account_type IN ('expense', 'income')
""")
# 2. Mark all existing employees as having timesheet access
self.env['hr.employee'].search([]).write({'timesheet_manager_id': self.env.user.id})
# 3. Create default helpdesk team for inbound support
if not self.env['helpdesk.team'].search_count([]):
    self.env['helpdesk.team'].create({
        'name': 'Customer Support',
        'use_alias': True,
        'alias_name': 'support',
    })
self.env.cr.commit()
print('Migration scripts complete.')

Verification: re-run your record-count query from step 1 and confirm no row counts have decreased. They should match exactly or grow slightly (because new helpdesk team and similar Enterprise defaults).

8. Re-test customizations

Every custom module needs a smoke test. Walk through the top 10 user workflows: create a sales order, validate an invoice, post a payment, confirm a stock picking, run a manufacturing order. Verification: each workflow completes without errors and the resulting records have non-null values in the new Enterprise-introduced fields.

9. Resume traffic on Enterprise

Stop the single-thread instance, restart Odoo with the production config, and re-enable the load balancer.

sudo systemctl start odoo
sudo systemctl status odoo
curl -I https://your-odoo-domain.com
# Expected: HTTP 200 and the X-Powered-By header

Verification: at least 3 real users log in, complete a transaction, and confirm everything still works.

10. Soak for 24 hours

Keep the rollback dump and the original Community binary on the server for 7 days. Watch the error log. Most issues surface within the first 4 hours from custom reports that hardcoded the absence of new Enterprise fields. Verification: 24 hours pass with zero new tracebacks in the Odoo log.

Common mistakes

• Migrating across major versions in one step. Always do Community-to-Enterprise on the same version, then upgrade. The Odoo upgrade tool does both at once but doubles the failure surface.
• Forgetting to update addons_path order. If Community is listed first, Enterprise overrides never trigger and you get a half-migrated database that looks fine but breaks on edge cases for months.
• Running db neutralize thinking it is harmless. It deletes mail server config, payment provider keys, and inter-company rules. Only run on staging.
• Skipping the soak period. 70 percent of post-migration issues surface within the first 24 hours. Have someone on call.
• Not freezing config changes 48 hours before. If a user adds a new fiscal position the day before migration, that change might not survive.

Going further

After the basic migration, layer on the Enterprise-only features that justified the license cost in the first place.

Documents module integration: configure folders for each department, set retention policies, and hook the module to your Sales and HR workflows. Documents alone often pays back the Enterprise subscription.

Studio for low-code customization: train the business team to do simple field additions and view tweaks in Studio so the developer team can focus on real engineering work. Studio's output is a regular Odoo module, so version-control it via the Export > As Module button.

MTD/SAF-T statutory features: in jurisdictions with electronic tax filing (UK MTD, France FEC, Spain SII, Portugal SAF-T, Mexico CFDI), Enterprise has the certified connectors. Configure the credentials and run a sandbox submission before the deadline.

Sign and DocuSign: replace external signature tools by routing every contract through Odoo Sign. The signed PDF gets archived in Documents and linked to the originating Sales Order.

For complex migrations spanning multiple modules and version bumps, our Odoo migration team can run the entire process as a managed engagement. We have completed 50+ Community-to-Enterprise migrations without a single data loss incident.

Frequently Asked Questions

Can I downgrade from Enterprise back to Community?

Technically yes by uninstalling the Enterprise modules in dependency order, but in practice you will lose data — the Enterprise-only models like helpdesk.ticket, documents.document, and appointment.type get dropped and there is no Community equivalent. Restore from the pre-migration backup instead.

What does the Enterprise license cost in 2026?

Standard pricing is around $31 per user per month for the Enterprise plan, with custom modules included free. There is also a "Custom" plan at roughly $47 per user that adds Studio and external API access. Multi-year commitments knock 10 to 20 percent off. Total cost of ownership compared to Community plus heavy customization usually breaks even at around 15 users.

Will my custom modules still work?

Yes if they were written cleanly. Modules that monkey-patch core code with _inherit and _inherits continue to work. Modules that replace entire views via arch_db overwrite need re-checking because Enterprise often adds new fields the Community view did not have.

How long does the actual cutover downtime need to be?

Plan for 30 minutes user-facing downtime. The entire technical procedure takes 4 to 6 hours, but most of that is preparation, license activation, and testing — work you do with traffic still flowing on the old instance. The actual switchover is just systemctl stop, pg_restore (no, you skip this in this recipe), systemctl start. Twenty minutes is achievable on small databases, an hour on databases over 50 GB.

If you would rather not learn this the hard way, ECOSIRE offers fixed-price Community-to-Enterprise migrations with a money-back data integrity guarantee. See our Odoo migration services page or read our companion guide on how to deploy Odoo on AWS EC2 with PostgreSQL 17.