How to migrate from Odoo Online to self-hosted Odoo without losing control of the data
Most operators who run Odoo Online and want custom or Apps Store modules on infrastructure they control are really asking three questions: which plan they are on, which edition they will run on their own servers, and which version path takes them from their current release to a supported target. The move depends on all three. Effort rises with the amount of customization and the number of apps in use, so a database with a few standard apps and no custom code is a very different job from one with Studio changes, third-party modules and external API connections. Start by checking your plan against Odoo's pricing page. That page places custom modules, external API access and hosting on Odoo.sh or on-premise in the Custom plan, so the first decision is whether your current subscription can support the target you have in mind.
The short answer on effort is that it is set by four drivers: the number of apps, the amount of custom code and Studio configuration, the size of the database and filestore, and the number of integrations that must be rebuilt or re-pointed. No duration can be given before those are counted. Ask each candidate partner to inventory them first, then to price the work from that inventory. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the inventory, the version steps, the backup and restore steps and the test cycles should all appear in the signed scope. A quote that cannot point to these items is not yet a quote you can compare.
Edition choice shapes both control and cost. Odoo's source for Enterprise is not publicly available, and an Enterprise database on your own servers is activated with a subscription code, so confirm who holds that subscription and how it is transferred before the infrastructure is built. Odoo's upgrade service requires an Enterprise subscription for on-premise use, and the Community edition has no access to it. If you choose Community, you will plan upgrades without that service. On the version side, Odoo Online and Odoo.sh require major upgrades every two years, and standard support for Odoo 19.0 runs until September 2028 while Odoo 20.0 runs until September 2029. Confirm your target release against Odoo's support documentation at the time you plan the move.
Control of the data means your team owns the database, the filestore, the credentials and the backups from the first day on your servers. Plan how the backup is exported from Odoo Online, how the database and filestore are restored, and how a neutralized test copy is made for rehearsals. Odoo documents database duplication with neutralization for test copies, which keeps outbound email and payment connectors from acting on live records during testing. Before switching users over, run the upgraded test database through the same checks you will use in production, including sign-in. Odoo documents LDAP sign-in, Google and Microsoft OAuth and two-factor authentication, so decide which of these your staff will use before cutover. Keep the rollback path and the final data sync window in the written plan.
Which Odoo Online features carry over and which need a new decision
This table compares the Odoo Online capabilities you use with what a self-hosted Odoo deployment requires, and what to do during migration. Read the Custom plan and Enterprise flags first, because they decide whether a feature can move at all. Rows marked for confirmation depend on Odoo's current documentation for your target version.
| Capability | On Odoo Online | Self-hosted target | Migration note |
|---|---|---|---|
| Installed apps | Plan limits apps: One App Free allows one app, Standard includes all apps | Community or Enterprise edition, with Enterprise apps needing a subscription | Confirm the edition of each app in use with Odoo before choosing the target edition |
| Custom modules | Available only on the Custom plan | Deployed into your own server code and addons path | Custom plan needed for Odoo.sh or on-premise hosting. Check each module against the target version |
| Odoo Studio customizations | Available only on the Custom plan | Studio is an Odoo app, so availability depends on edition and subscription | Custom plan flag. Confirm with Odoo whether Studio changes export, or plan to rebuild them as modules |
| External API access | Available only on the Custom plan | API served from your own domain and server | Custom plan flag. Update every integration's base URL and credentials, then test each call |
| Multi-company | Available only on the Custom plan | Company records restored with the database | Custom plan flag. Test company structure, access rules and inter-company records after restore |
| User sign-in | Odoo account sign-in on the hosted service | LDAP, Google Sign-In, Microsoft Azure OAuth, Facebook and two-factor authentication are documented | Choose the method before cutover and confirm the configuration steps with Odoo's LDAP and sign-in docs |
| Filestore (attachments) | Stored and managed by Odoo | Stored on your server and must be restored with the database | Confirm with Odoo how the filestore is packaged and restored, then check attachments on test records |
| Subscription and upgrades | Major versions are mandatory every two years on Odoo Online | Enterprise databases are activated with a subscription code. Community has no upgrade service access | Enterprise flag. Plan the intermediary version path and standard support dates for the target release |
Why the Odoo plan tier decides whether the move is possible
Before any export runs, confirm that your current Odoo plan allows the move at all. Odoo's pricing page places Odoo.sh and on-premise hosting under the Custom plan only. The One App Free and Standard plans are listed as Odoo Online only. For a team that wants to run its database on servers it controls, or on Odoo.sh, the target hosting type is therefore tied to a plan decision that sits with Odoo's commercial terms, not with your technical work.
The same page lists multi-company, Odoo Studio, external API access and custom modules under the Custom plan. These are the features most often behind a move to self-hosting. A business that uses several companies in one database, depends on Studio views and automations, or calls Odoo from another system through its API may find that the features it relies on are not available on the tier it currently pays for. If the database contains custom modules, you cannot install them on Odoo Online in the first place, so the reason for leaving is usually one of these gaps.
For a team on One App Free or Standard, the practical consequence is that the move may require a plan change before the target environment can be built. Ask for the exact entitlements in writing: which apps are included, whether your database can be downloaded in the form you need, and whether your subscription transfers to a self-hosted Enterprise installation. Odoo's documentation describes on-premise use as requiring an Enterprise subscription, and the Community edition does not include access to the upgrade service. Those two points change the cost of the project and the sequence of steps, so they belong in the decision before the target is chosen.
Confirm current plan terms with Odoo before you choose a target. Plan names, included features and hosting options are commercial terms that Odoo can change, and the pricing page is the public reference, not a contract. Ask Odoo or your reseller to confirm, in writing, the plan that includes the features you need, the hosting types available on it, the subscription treatment after the move, and any fees for changing plans mid-subscription. Record the answers with the date you received them, because they determine which of the later steps apply to you.
Make the tier check a gate in the project plan. If the required features are only on Custom, the budget and approval for that plan come first, then the target environment, then the backup and upgrade work. If the features are not needed and the team can stay on a lower tier, the migration may be a plan-cost decision rather than a hosting project. In both cases, write down which features are in use today, because the feature inventory is what you will test against after the switch and it is also the basis for the plan conversation.
Which documented paths move the data and the sign-in setup
Odoo documents several ways to get data out of Odoo Online and into an installation you run, and separate methods for how users sign in. Each path suits a different stage of the move, so the choice depends on whether you are building a test copy, a production cutover or a new sign-in model.
Backup download from Odoo Online
This is the starting point for taking a copy of the Odoo Online database and filestore out of the hosted service. Confirm in the current Odoo documentation which backup format is produced, whether it includes the filestore, and how the backup is restored onto your own server. Also confirm whether the backup can be taken from a database at its current version or whether an intermediary upgrade must come first.
Packaged installers and source installation
Odoo documents packaged installers and source installation for on-premise hosting. Packaged installers suit a standard server build, while source installation gives your team control over Python, PostgreSQL and module paths, which matters when you run custom or Apps Store modules. Check the prerequisites and supported operating systems for the version you target before choosing a method.
Database duplication with neutralization
Duplicating a database and neutralizing it produces a test copy that does not send live email, trigger scheduled actions against real partners or hold live payment settings. Use it to rehearse the restore and test custom modules before cutover. Confirm in the Odoo on-premise documentation exactly which settings neutralization disables, and add your own checks for integrations that Odoo does not reset.
Enterprise subscription activation
On-premise Enterprise databases are activated by entering the subscription code. Your subscription has to cover the self-hosted deployment, and the Custom plan is the only plan Odoo lists as hostable on Odoo.sh or on-premise. Confirm with Odoo how an existing Online subscription is transferred or re-issued, because the transfer steps and any timing constraints are not part of the researched facts for this page.
LDAP sign-in with user creation
Odoo documents LDAP authentication, including optional creation of a user on first login from a template user. This suits organizations that already hold staff identities in a directory. Decide whether accounts should be created automatically or pre-provisioned, and test how group membership and deprovisioning are handled, since deleting a directory entry does not necessarily disable the Odoo user.
OAuth sign-in and two-factor authentication
Odoo documents Google Sign-In, Microsoft Azure OAuth and Facebook sign-in, along with two-factor authentication. Choose the provider that matches your identity source, and confirm in the current documentation how each provider is configured, which login methods remain available as fallback, and how two-factor enrollment is enforced. Test the sign-in path with real staff accounts before cutover.
How the Odoo version path sets the migration order
The version your Odoo Online database runs on decides the order of the migration, so confirm it before you choose a target. Odoo 20.0 was released in September 2026 with standard support planned until September 2029. Odoo 19.0 (September 2025) has standard support until September 2028, and Odoo 18.0 (October 2024) has standard support until September 2027. Odoo 17.0 standard support ended in September 2026. Standard support covers the first three years after a major release, and security patches are provided only during that window. A database running a version past its standard support window carries known exposure, so record the support end date for your current version in the migration plan and treat it as a deadline.
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, and Odoo runs them through its upgrade service. That service moves a database to a newer supported version by creating an upgraded test database, which should be tested before anything goes to production. For a migration, the upgrade becomes part of the cutover plan. Ask Odoo which upgrade your database is due for and when the upgraded test copy will be available. Then test custom modules, Apps Store modules, scheduled actions, integrations and printed documents against that copy, and log every failure with a named owner. The upgrade service requires an Enterprise subscription for on-premise use, and the Community edition has no access to it, so confirm that entitlement before the path is fixed.
An old database may need to pass through one or more intermediary versions before it reaches the target. Because the upgrade service moves a database to a newer supported version, a database several versions behind may have to advance in steps, with each step tested before the next one starts. Confirm with Odoo which steps are available for your database and whether each one is offered for your hosting type. Illustrative example: a database on a version whose standard support has ended might need one intermediary upgrade onto a supported release, then a second upgrade to reach the target, with a full test cycle for each. Plan the steps backward from the target version and the go-live date. The slowest custom or Apps Store module often sets the pace, so request compatibility status from each module's publisher or your developers for every version on the path.
Choose the target version on the self-hosted side with the support calendar in view. Odoo SaaS versions are released every two to three months and cannot use extended support, while paid extended support after standard support is limited to Odoo.sh for select versions and to on-premise. An on-premise Enterprise database is activated with its subscription code, and Odoo documents packaged installers and source installation, so the platform team should confirm which method fits its change control process. Duplicate the production database with neutralization to create test copies, and confirm exactly what neutralization disables in the copy before relying on it. Run one full rehearsal per upgrade step, agree the production freeze window in advance, and ask Odoo to confirm the support end date for the target release before sign-off.
How the migration runs from inventory to decommissioning the old instance
The sequence moves a live Odoo Online database to an instance you control, with each stage ending in a written check so that cutover happens only after the data, custom code and users have been proven on the new platform.
Inventory apps, custom modules and integrations
Before any server is chosen, the team lists every installed app, every Studio customization, every custom module, and every external connection such as payment, shipping, bank, identity or API integrations. Each item is recorded with its owner, its data volume and the users who depend on it. The inventory also notes which apps are Community or Enterprise only and which ones require a plan that Odoo Online does not offer for self-hosting. The step is done when the inventory has been signed off by the business owner and the technical lead, and every item has a stated keep, replace or retire decision.
Decide the target plan and edition
The team confirms which Odoo plan and edition the self-hosted instance requires, based on the inventory. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise and that multi-company, Odoo Studio, external API access and custom modules are included only in that plan, so these features must be checked against the requirements before the target is chosen. The decision between your own servers and Odoo.sh is recorded with the reasons, along with who holds the subscription. The step is done when the decision record names the plan, the edition, the hosting target and the owner of each.
Provision the target environment
The target is built either on your own servers, using the packaged installers or source installation Odoo documents, or as an Odoo.sh environment. For an Enterprise on-premise instance, the subscription code is entered to activate the database. The environment is set up with the chosen PostgreSQL and filestore layout, network access, backups, monitoring, TLS and the identity provider the business uses. Sizing depends on user counts, data volume and integration load, so it is confirmed against the inventory. The step is done when a fresh instance boots, its configuration is documented, and the operations team has run a restart and a restore test on an empty database.
Back up and restore into a test copy
The production database and its filestore are downloaded from Odoo Online through the backup function, then restored into the new environment as a separate test copy. Duplicated databases should be neutralized so that outgoing emails, payment connections and scheduled actions cannot reach real customers or banks while testing. Restore time and any errors are logged, and record counts, attachment counts and key balances are compared with the source. The step is done when the restored copy matches the source on agreed checks, and the neutralization steps are written down for reuse.
Run intermediary upgrades and test each one
If the source version is older than the version you intend to run, the database is moved through each supported major version in order, not in one jump, with the upgrade service or the documented path. Odoo's upgrade documentation says the result is an upgraded test database that should be tested before production, and that on-premise use requires an Enterprise subscription. Custom modules are ported and tested at each stop, because code that works on one version may fail on the next. Odoo's support windows, including the standard support end dates for each version, should be checked when the target version is picked. The step is done when each upgraded copy passes the written test script for its version.
Pilot with a small user group
A limited group of real users works on the migrated test copy for their daily tasks, such as sales orders, invoices, stock moves or approvals, while the business confirms that their processes run without workarounds. Their findings are logged with the module, the steps and the expected result, and fixes are retested on a fresh restore. Integrations are tested against sandbox endpoints where the provider offers them. The step is done when the pilot group signs the acceptance test for each process in scope and every open defect is either fixed or accepted in writing.
Run the parallel period
Both Odoo Online and the self-hosted instance run for an agreed period, and the same transactions are checked in both systems. The team compares reports, open items, stock valuations, tax totals and integration messages, and reconciles any difference before it is accepted. Sync and cutover rules are agreed in advance, including which system is the book of record on each day. The length of the parallel period depends on transaction volume and reporting cycles, so it is set in the plan rather than assumed. The step is done when reconciliation reports match on the agreed checks for the agreed period.
Cut over with a final data sync
Users are moved to the new instance during a planned window. Odoo Online is set to read-only or closed to new transactions, a final backup is taken and restored, and the delta since the last sync is loaded and checked. Integrations, DNS, email sending, payment connections and identity sign-in are switched to the new instance in a written runbook with a rollback point. The step is done when the final reconciliation passes, the rollback point is confirmed, and users have signed in and completed a test transaction on the new system.
Decommission Odoo Online after a confirmed period
Odoo Online is kept available in read-only form for a period agreed with the business, finance and compliance owners, so that late queries, audits and reconciliations can still be answered from it. Retention rules for the exported backups and the cancellation of the Odoo Online subscription are then confirmed with the vendor and recorded. The subscription is not cancelled until the business confirms that no open dependency remains. The step is done when the owner signs the decommissioning record, the final backup is archived under the agreed retention rules, and the subscription status is confirmed in writing.
What changes when the subscription moves to your own servers
The licensing check comes first because it decides whether the move is possible at all. An Odoo Online database runs under a subscription that Odoo manages. On-premise Enterprise databases are activated by entering a subscription code, so the target database needs a code tied to your subscription before it can run Enterprise features. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes custom modules, Odoo Studio and external API access. Confirm that your current plan covers self-hosting before you order infrastructure, and get the subscription code and its terms in writing.
Enterprise source code is not publicly available. It requires a subscription or partner access, so your deployment team cannot simply clone it from the public repository. The Odoo GitHub repository publishes the Community edition under LGPL-3.0, and the Enterprise applications have to come through your subscription or partner access. Build that path into the plan. Identify which installed apps are Enterprise, confirm how your engineers will obtain the code for installs and updates, and check that every Apps Store module and custom module in the database matches the same edition and version. A module that works on Odoo Online may depend on Enterprise code that the target does not carry.
If the target runs Community, the upgrade service is not available to you. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, and on-premise use of that service requires an Enterprise subscription. Community users have no access to it. This matters because Odoo Online and Odoo.sh require major version upgrades every two years, so a database moved off Online will still face version changes, now on a schedule your team controls. Decide before the move which edition you will run and who will carry each future upgrade, including test database work, custom module porting and the testing the upgrade documentation calls for before production.
Ask Odoo how the subscription transfers from Odoo Online before any cutover date is set. Confirm whether the subscription moves to the new database, how the code is issued, and whether any step requires Odoo to act on the Online account. Also ask what happens to the Online instance during the move and after it: whether it stays live for a parallel run, whether users can still sign in, whether a full data export is available, how long the instance remains available for rollback, and whether billing stops or continues. Record the answers in the cutover plan. A missing answer can lock users out of the old system before the new one has been verified.
What makes the migration cost more or take longer
This table lists the factors that move the cost and schedule of leaving Odoo Online for a self-hosted instance, and who carries each one. Read each row as a lever: the middle columns explain the effect and who pays, and the last column shows what you can do to reduce it. Recurring costs, such as upgrade cycles and infrastructure, continue after go-live, so ask for them separately in any quote.
| Driver | Why it moves cost or time | Who pays and whether it recurs | How to reduce it |
|---|---|---|---|
| Number of apps in use | Each app adds configuration, data mapping and test cases. Scope grows faster when apps share records and workflows. | Your team for internal time, the implementer for scoped work. One-time, though later app use adds upkeep. | Retire unused apps before migration and move only the processes that are still active. |
| Custom modules and version fit | Custom modules built for one Odoo version must be checked and ported to the target version, which takes development and testing time. | Developer, usually the implementer, one-time. Module maintenance recurs at each later major upgrade. | Inventory every module, record its version fit, and drop any that standard features now cover. |
| Studio customizations | Studio changes made in Odoo Online must be recreated or moved into code on your instance, and each one needs retesting. | Implementer or your team, one-time. Any Studio change you keep becomes code you maintain after go-live. | Log every Studio change and decide keep, rebuild or drop before the build starts. |
| Number of integrations | Each identity provider, payment, shipping or bank connection needs new credentials, endpoints and test transactions. | Integration developer one-time. Your credentials and bank access are yours, and third-party fees recur. | Confirm each connector supports your target version and assign an owner for every credential early. |
| Data volume and attachments | Large databases and filestore attachments lengthen export, transfer, restore and reconciliation, and raise storage needs. | Transfer effort is one-time. Storage and backup costs on your infrastructure recur. | Agree a data retention rule and archive old records and attachments you do not need before the transfer. |
| Number of intermediary upgrades | Odoo Online major versions are mandatory every two years, so an older database may need several upgrade steps, each tested before the next. | Whoever runs each step, usually the implementer or your team, one-time per step. Future upgrades recur. | Confirm the current version and upgrade path with Odoo before scoping, and plan to stay on a supported version. |
| Number of companies | Each company brings its own chart of accounts, fiscal settings, user access rules and reports, each needing checks. | Your finance team and implementer, one-time. Consolidated reporting needs ongoing review. | Migrate companies in waves and confirm which multi-company features your plan and version include. |
| Test cycles | Each test copy must be refreshed and validated. Failed cycles repeat data loads and fixes, which extends the schedule. | Business users for acceptance and implementer for fixes, one-time. Regression tests recur with later upgrades. | Set entry and exit criteria for each cycle and fix the scope so the number of rounds stays limited. |
| Cost of a parallel run | Running Odoo Online and the self-hosted instance side by side means two systems to keep in step and staff to reconcile both. | Finance and operations staff for reconciliation, time-bound. Odoo Online fees continue for as long as the subscription runs. | Keep the window short, freeze changes in the source system, and name which system holds the record. |
What usually goes wrong when leaving Odoo Online
Moving from Odoo Online to a server you run shifts responsibility for the database, files, sign-in and scheduled work onto your team. The failures below often surface after go-live, when users find missing attachments, unexpected emails or locked accounts. Each card names a check to complete before users move, so the cutover decision rests on evidence.
Upgraded test database left untested
Odoo's upgrade service produces an upgraded test database, and Odoo recommends testing it before it becomes production. Teams that skip this step often find broken reports, workflows or accounting postings only after staff return to work on the new system. Prevention: have finance and operations sign off a fixed list of invoices, payments, stock moves and reports, reconciled against the source database, and record the date each test was run.
Custom modules that break on the target version
Custom modules and Apps Store add-ons built for the source version may need porting before they load on the target release. Failures usually appear in views, deprecated methods or dependencies that were never declared. Prevention: list every installed custom and third-party module with its version, install them on the upgraded test copy, and confirm the upgrade log shows no errors and each module's key workflow completes end to end.
Missing filestore attachments
A database-only copy holds records, but attachments such as scanned contracts, supplier invoices and product images are stored in the filestore. Without it, users see blank links or broken previews on records that look complete. Prevention: take a full backup that includes the filestore, restore both parts to the target, and open a sample of attachments on invoices, employees and products to confirm each one loads.
Users locked out after the identity change
Sign-in on your own server depends on the method you configure, which may differ from how users signed in before. Users who relied on a Google or Microsoft account may find no matching login, and two-factor settings may not carry over. Prevention: choose the sign-in method before cutover, map each existing user to the identity they will use, and test an invited user, an administrator and a user with two-factor enabled on the target.
Scheduled jobs and mail copied from live
A copied database carries its scheduled actions and outgoing mail settings. If a test or new server runs them, it may send invoices, reminders or bulk emails to customers, or read from live mailboxes. Prevention: create non-production copies with Odoo's database duplication and neutralization option, review or disable scheduled actions and mail servers on every copy, and confirm before go-live that exactly one environment sends mail.
Cutover without activation or rollback
Enterprise databases on your own servers are activated by entering the subscription code, so activation must be confirmed before users arrive. A cutover without a rollback plan leaves no tested way back if the new system fails on day one. Prevention: put the activation, final data sync and go or no-go decision in a dated runbook, define the point at which you would revert, keep the source database untouched until sign-off, and rehearse the revert on the test environment.
What buyers ask before moving off Odoo Online
What drives the cost of moving off Odoo Online?
The main drivers are the number of apps and custom modules in use, the size of the database and filestore, how many intermediary upgrades the data must pass through, and how much process mapping the team needs before testing starts. Who is paid for what: you pay for your own hosting in your cloud or data center, the Odoo subscription tier that allows self-hosting, and the implementation partner's work under the agreed scope. Most of the implementation cost is one-time (planning, migration, testing and cutover). Hosting, backups, patching and support recur. Ask any quote to split these lines, to show which modules are Community and which need Enterprise, and to state what changes if the target Odoo version changes.
How long does moving off Odoo Online usually take?
Duration depends on scope more than on the platform itself: how many apps are live, how many years of history must come across, how many versions the database must pass through, and how much custom code needs porting. Testing is often the longest phase, because each upgraded test database needs its own review before production. Parallel runs and user acceptance also need calendar time, and your own staff's availability sets how quickly those steps move. We do not publish a standard duration. Ask for a written plan that shows the phases, the dependencies between them, and the sign-off points where your team must act.
What does a move off Odoo Online need from our own staff?
The move needs named people more than hours. Process owners confirm how each app should work after the move, and a data owner approves which records, history and attachments come across. Test users run scripted and ad hoc scenarios in the test database, including month-end, approvals and reports. An IT contact handles cloud accounts, DNS, certificates, email and any single sign-on setup. A business sponsor signs off each testing stage and the final cutover. Agree these roles and their time commitments in the scope before work starts, and ask the partner to list the decisions they expect your team to make and the date by which each one is needed.
Can our own IT team run the migration without an implementation partner?
Yes, a capable internal team can do it, but the work needs Odoo-specific skills as well as general Linux, PostgreSQL and deployment skills. Odoo documents source installation and packaged installers, and it documents database duplication with neutralization for test copies. The upgrade path is the hard part. The Odoo upgrade service moves a database to a newer supported version through an upgraded test database, and on-premise use requires an Enterprise subscription. Community has no access to that service. Check whether your team has done a version upgrade before, who will own the upgrade runbook, and who will carry patching after go-live.
Which Odoo plan do we need to run on Odoo.sh or on-premise?
According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise. Only Custom also includes multi-company, Odoo Studio, external API access and custom modules. The One App Free and Standard plans are Odoo Online only. Plans, features and prices change, so confirm the current tier with Odoo before you finalize the design, and check that the features you depend on are included. Ask the partner to list every feature, module and integration in your current setup, then map each one to the plan that supports it. This mapping often decides the licensing conversation more than the hosting choice.
Does our Enterprise subscription carry over to a self-hosted Odoo?
The Enterprise source code is not publicly available, so self-hosting Enterprise requires a subscription or partner access. On-premise Enterprise databases are activated by entering the subscription code, and on-premise use of the upgrade service requires an Enterprise subscription. Whether your current Odoo Online contract can be moved to a self-hosted deployment, and on what terms, is a question for Odoo, not for the implementation partner. Confirm with Odoo how the subscription is transferred, whether the contract changes, which users and apps are covered, and what counts as a new licence. Get the answer in writing before the target environment is built.
Which Odoo version should we target, and how long will it be supported?
Odoo standard support covers the first three years after a major release, including security updates and bug fixes, on Odoo Online, Odoo.sh and on-premise. Per Odoo's support documentation, Odoo 20.0 has standard support planned until September 2029, Odoo 19.0 until September 2028, and Odoo 18.0 until September 2027. Odoo 17.0 standard support ended in September 2026. Paid extended support is limited to Odoo.sh for select versions and to on-premise, and security patches come only during standard support. Odoo SaaS versions are released every two to three months and cannot use extended support. Ask which version your target environment will run and plan the upgrade cadence from that date.
What happens to our Odoo Online instance after we switch?
Confirm with Odoo, in writing, when your Odoo Online subscription ends and what access you keep afterwards. Keep the Online instance available, unchanged and backed up until your business sponsor has signed off the cutover and any retention period in your own policy has been met. Take a final backup and filestore export at cutover, and record the checksum and location of each. Decide who may still log in, and disable or restrict those accounts once users have moved. Do not delete the Online instance until the audit trail, reports and historical records have been verified in the new environment and stored where your policy requires.
How DeployOpen scopes, delivers and supports the migration
DeployOpen plans the move from Odoo Online to infrastructure you control as a fixed-scope engagement agreed in writing before work starts. The work covers the backup download, intermediary version upgrades, subscription transfer, filestore restore and testing, and it runs inside your own cloud accounts, data centers or air-gapped network.
How we scope
- Written scope lists the Odoo edition, target version, custom and Apps Store modules, and integrations to move.
- Scope confirms your target host, since Odoo's pricing page limits Odoo.sh and on-premise hosting to the Custom plan.
- Fixed-scope terms are agreed in writing before work starts, and quotes follow from that written scope.
How we build
- Backup download and an intermediary version upgrade path, tested on a database copy before any production change.
- Test copies use Odoo's database duplication with neutralization, kept separate from production until cutover.
- Subscription transfer, Enterprise activation with the subscription code, and sign-in configured with the LDAP or OAuth methods Odoo documents.
How we hand over
- Written runbook covering install method, backup schedule, restore steps, upgrade stops and module update procedure.
- Cutover checklist for switching users, with the final data check recorded.
- Test results and configuration records delivered, so your administrators can operate the system after handover.
How we support
- Standard support windows are set by Odoo, so the target version's end date shapes the upgrade schedule.
- Ongoing support, upgrades and testing can run as a retainer after cutover, priced from a written scope.
- Major upgrades are mandatory every two years on Odoo Online and Odoo.sh, so confirm the cadence for your target.
