Odoo Community to Enterprise migration

Start with an inventory. Before any Enterprise subscription code is entered or any database is copied, list every custom and third-party addon on the Community server, including the Odoo version it targets, the source it came from, the license terms that apply, the developer or vendor who maintains it, and the business process it supports. Record the addon paths and the database each one is loaded into. Many teams find modules they no longer use, or modules installed by a former developer that nobody on the current team can explain. Those should be removed from the migration scope rather than carried across.

Next, check dependencies. For each module, read its manifest and identify every declared dependency, then check whether any of those dependencies are Enterprise-only or come from an Enterprise app. A module that depends on an Enterprise application will not install on a Community build, so the migration direction matters here: moving to Enterprise removes that particular problem, but the reverse check still matters if a test copy is ever restored to Community. Also look for code that imports Enterprise-only Python packages, extends views defined in Enterprise apps, or calls web services that depend on a specific edition or subscription.

Then confirm that each module installs and loads on the Enterprise build in a test database, not in production. Installing is only the first step. Load the main screens, run the business processes the module supports, check scheduled actions, reports, portal pages and any external API calls, and review the server log for deprecation warnings or errors. Some modules install cleanly but fail when a user opens a particular form. Record the result for each module as installs, loads, passes functional tests, or needs porting. The modules that need porting become the input for the upgrade service and developer estimate, which the upgrade and support section covers in more detail.

Plan for plan-dependent features. On Odoo's pricing page, custom modules and external API access are included only in the Custom plan, and only Custom can be hosted on Odoo.sh or on-premise. Confirm with Odoo which plan the organization is contracted under and whether that plan covers every custom module and every integration that calls the external API. If an integration uses the API from a plan that does not include it, that integration will fail after the move regardless of how well the module was built. Do not assume that a module that works on Community works unchanged on Enterprise. Test it, including login, permissions, record rules and any feature that behaves differently in the Enterprise apps it now sits beside.

Ask your implementation partner or Odoo to confirm, in writing, the target version and its support window, whether each module has a version-matched release for that version, which Enterprise apps your modules depend on, whether the external API is included under your plan, and what the upgrade service will port automatically versus what a developer must change by hand. Ask the partner to show the test results for each module, not only a list of modules that installed. The written answers should be attached to the scope so that porting work is quoted and scheduled before cutover, not discovered during it.

Verification has to answer two questions before the Enterprise database is trusted with live transactions: does the converted database behave like the Community original for the business processes your teams run every day, and if it does not, can you return to Community without losing data. Run the checks on a neutralized copy of the production database, not on production itself, and record each result as you go. Start with the subscription and module state. Confirm that the subscription code has been accepted, that the Enterprise apps your design requires show as installed, and that no Community-only module has been removed by accident. Odoo activates Enterprise on-premise databases with the subscription code, so the check is whether the activation is visible in the database and in the apps menu, not whether someone recalls entering it.

Next, compare the module list and installed versions before and after the conversion. Export the list of installed modules with their versions from the Community backup and from the converted copy, then diff the two. Expect Enterprise modules to appear as new entries and expect no existing custom or third-party module to change state without a reason. Any module that is missing, marked uninstalled or running a different version needs an explanation before go-live. This comparison is the cheapest check in the plan and often catches the problems that business users only discover weeks later, such as a reporting module that silently stopped loading.

Then run business smoke tests that follow real documents through the system. The scripts depend on which apps you use, but a typical set is a sales order confirmed, invoiced and paid; a stock move from receipt through delivery with the valuation posted; a payslip run or an accounting period close, if those apps are in use. Use test data that mirrors live cases, including a multi-company or multi-currency record if your design uses them. Also check scheduled actions and outgoing mail on the neutralized copy. Confirm that scheduled actions that should not run in a test environment are disabled, and that outgoing mail is routed to a sink so no customer or supplier receives a message from the copy. Record which scheduled actions were active and who approved their state.

Confirm that restore from backup works before you rely on it. Restore the Community backup to a separate environment and confirm it starts and reconciles, then restore the post-conversion backup in the same way. A backup that has never been restored is an assumption, not a control. Decide the rollback point in advance. Keep the Community backup, with its filestore, until the agreed point, and define that point in writing, for example the first production transaction posted to the Enterprise database or the first scheduled run that writes to external systems. Before that point, rollback means restoring the Community backup and repointing users, with a known and limited loss of changes. After it, rollback means reconciling transactions made in the Enterprise database by hand, which is not clean. Name the approver for each decision.

Finally, record the results as change evidence: the module diff, the subscription check, the smoke test outputs with names and timestamps, the scheduled action and mail settings, the restore test results, and the signed rollback point. Store them with the change record so an auditor, an internal reviewer or a future upgrade team can see what was verified and by whom. Confirm with your own controls owner which evidence format and retention period apply to your organization, since those depend on your environment and any framework you are assessed against.

The migration is only finished when someone owns the database after go-live. Start by recording who holds the Odoo Enterprise subscription, which contact receives renewal notices, and what happens to activation if that person leaves. Subscription renewal is an operational dependency: an on-premise Enterprise database is activated with a subscription code, so a lapsed or misassigned subscription can block the team from running the Enterprise modules they depend on. Add the renewal date to the team's calendar with two named owners, and confirm with Odoo how the subscription is tied to your database and hosting plan before cutover.

Track the Odoo version and its standard support end date as a recurring item, not a one-time fact. Odoo's supplied support dates show how the window moves: Odoo 18.0 (released October 2024) receives standard support until September 2027, Odoo 19.0 (September 2025) until September 2028, and Odoo 20.0 (September 2026) until September 2029. Odoo 17.0 standard support ended in September 2026. These dates are examples of the pattern, so confirm the current version and end date on Odoo's support documentation whenever you review the runbook. Standard support includes security patches, and those patches stop when standard support ends for your version, so the end date sets your upgrade deadline.

Plan for mandatory major upgrades. On Odoo Online and Odoo.sh, major version upgrades are required every two years, so a database that stays on one version is not a steady state you can keep. Odoo's upgrade service works through an upgraded test database, which your team must test before moving production. For on-premise deployments, the upgrade service requires an Enterprise subscription. Put the next upgrade window on the calendar, record which custom and third-party modules need porting, and budget the test cycle as recurring work. Ask any partner for the upgrade approach in writing, including who runs the test database checks.

Backups and restore tests need the same discipline. Back up the PostgreSQL database and the filestore together, because attachments and documents live outside the database and a restore that brings back only one of them leaves records broken. Schedule a restore test on a schedule your team can keep, into a separate environment, and record the time it took and any manual steps. Use database duplication with neutralization for test copies, so outgoing email, payment connectors and scheduled actions do not reach real customers from a non-production environment. Record the retention period and the person who approves a restore.

The runbook is the document that keeps all of this working when people change. Keep it internal to your operations and security team, because it names subscription contacts, access paths and restore procedures. Hand over a shorter version to your partner or new administrators: the module inventory (every Enterprise, custom and third-party module with its version and owner), the upgrade path from the current version, and the test database process. Keep subscription commercial terms, pricing and contract records with finance and procurement. Review the runbook at each upgrade and each subscription renewal, and confirm the current support dates with Odoo rather than relying on this page.