Odoo 17 to 18 upgrade: why it is on the critical path now
This section concerns a planned migration of a live Odoo 17 database to Odoo 18.0, and it sits on the critical path because Odoo 17.0 standard support ended in September 2026. Standard support covers security updates and bug fixes, so an instance still running 17.0 no longer receives the standard patches that would normally reach it. The database is not a sandbox. Sales orders, invoices, stock moves and employee records keep changing while the project runs, and your custom modules and integrations must keep working when the upgraded copy replaces production.
Odoo 18.0 was released in October 2024, and its standard support runs until September 2027. Choosing 18.0 as the target gives you a working version with a fixed end date, so the next major upgrade should be planned against that date from the start. A target of 19.0 or 20.0 is a separate decision with different porting work, and it should be made before the test database is requested, because the target version determines which module changes and data changes you test. Confirm the support dates for your chosen target on Odoo's documentation before you commit a date to your steering group.
Your hosting type changes how much room you have. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so the question is when the move happens, not whether it happens. On-premise deployments follow the standard and extended support rules: standard support covers the first three years after a major release, and paid extended support is limited to Odoo.sh for select versions and to on-premise. Security patches are provided only during standard support, so check exactly what any extended support agreement covers before you rely on it. Ask Odoo which versions and services apply to your edition and hosting type.
Start with an inventory that the test database will be measured against. List your exact edition, hosting type and subscription status, then record every custom module with its owner, every integration and every sign-in method, such as LDAP, Google Sign-In, Microsoft Azure OAuth or two-factor authentication. Odoo documents database duplication with neutralization for test copies on on-premise deployments, so confirm that your team can produce a neutralized copy safely. On-premise, the upgrade service requires an Enterprise subscription, and the Community edition has no access to it, so a Community instance follows a different route that depends on the same inventory.
The timing is the reason to start now. An upgrade into 18.0 needs time for module porting, a tested upgraded database, a user acceptance round and a cutover window, and each step depends on the people who know your custom code. Agree the target version, the owner of each module and a date for the test database request in writing with your partner or internal team. Expect the upgraded test database to be the first point where custom modules and integrations are exercised together, so plan staff time for that testing. Treat a missed date as a risk to report to leadership, because the support window does not move to accommodate the project.
What changes between Odoo 17.0 and 18.0 for your database and code
This table compares the support, licensing and hosting conditions that change when an Odoo 17.0 database moves to 18.0, and what each one means for your upgrade. Read each row as a decision point that sets your timeline, your upgrade method or your testing scope. The main takeaway is that 17.0 standard support has already ended, so confirm your upgrade entitlement and hosting plan before building a test copy.
| Change | Impact | Action needed |
|---|---|---|
| Standard support for 17.0 | Standard support ended in September 2026, and security patches are provided only during standard support. | Ask Odoo which extended support options apply to your version and hosting type before you set the upgrade date. |
| Standard support for 18.0 | 18.0 was released in October 2024, and standard support runs until September 2027. | Plan cutover so it lands inside standard support, and schedule your next upgrade against the September 2027 end date. |
| Upgrade service on-premise | Using the upgrade service on-premise requires an Enterprise subscription. | Confirm your subscription covers the upgrade service before you start database work. |
| Upgrade service on Community | The Community edition has no access to the upgrade service. | Choose a separate upgrade method for Community databases and confirm it before scheduling. |
| Hosting on Odoo.sh or on-premise | Only the Custom plan can be hosted on Odoo.sh or on-premise. | Confirm your plan is Custom before you design an Odoo.sh or on-premise target for 18.0. |
| Upgraded test database | The upgrade service produces an upgraded test database that should be tested before production. | Test custom modules, integrations, reports and key workflows on the upgraded copy, and record sign-off before cutover. |
| Functional and API changes | The 18.0 release notes are not summarized on this page. | Check functional and API changes against the official 18.0 documentation for each module you use. |
What to back up and inventory before the test database request
Four inventories should exist in writing before the test database request is made. Each produces a document or dataset that your team and DeployOpen can review, and together they define what the upgraded Odoo 18.0 instance must reproduce. Odoo 17.0 standard support ended in September 2026, so these records also set the order of the work.
Full database and filestore backup
Take a full PostgreSQL dump and a copy of the filestore, which holds attachments and documents, from the same point in time. Restore both into a separate environment and record the restore duration, any errors and row counts for key records such as sales orders, invoices and stock moves. Keep the restored copy neutralized, as Odoo documents for test copies, and confirm which outgoing services that disables. The artifact is a backup record and a restore test report that the team signs off before any upgrade work begins.
Custom modules and connector owners
List every custom module, third-party add-on and external connector in the instance. For each one, record the Odoo version it targets, the repository it lives in, any Python packages or scheduled actions it depends on, and the named person who maintains it. Modules without an owner are often the ones nobody tests after cutover. The artifact is a module register with one owner per row, which becomes the porting backlog for Odoo 18.0 and shows who must approve each change.
Enabled apps and Enterprise-only features
Export the list of installed and enabled apps, then mark each one that relies on the Enterprise edition or a subscription tier. Include capabilities that Odoo's pricing page ties to the Custom plan, such as multi-company, Odoo Studio, external API access and custom modules. Confirm current licensing with Odoo before the test request, because a change in plan or subscription affects which upgrade path is available. The artifact is an app and feature matrix showing which companies and teams use each capability.
Login and integration points
Record every route by which users sign in and every external system that sends data to or receives data from Odoo. Cover LDAP, including any user creation on first login from a template, Google Sign-In, Microsoft Azure OAuth, Facebook sign-in, two-factor authentication, and payment and shipping connectors. Note the endpoint, the credentials owner and the test case for each point. The artifact is an integration map with a pass or fail result for every entry, checked against the test database before go-live.
How the upgraded test database and neutralized copies fit together
The upgraded test database is the checkpoint between your Odoo 17 system and the Odoo 18 system you will run. Odoo's upgrade service moves a database to a newer supported version and produces an upgraded test database, which Odoo's upgrade documentation says should be tested before production. For this move, that copy is where you check ported custom modules, reports, accounting configuration, scheduled jobs and integrations against 18.0. Treat it as the place where problems are found and fixed, not as a copy you approve after a quick look. Each defect should be logged, corrected in the source code, and then verified on a fresh upgraded copy so the final cutover is based on a tested result.
Every test copy of production should be made through database duplication with neutralization. Neutralization is intended to stop outgoing email, scheduled actions and payment or shipping connectors from reaching live services while your team exercises the copy. Ask your partner for the list of what neutralization changes in your version, then verify it yourself. Check mail servers, scheduled actions, payment provider credentials, carrier accounts, webhooks and API tokens stored in system parameters. Send a test order and a test invoice, and confirm that no customer, supplier or carrier receives anything. Repeat this check on every copy, because a single missed setting can cause real-world side effects during testing.
The request for the upgraded test database is a step you need to plan with Odoo and your partner, not assume will be quick. Confirm in writing which database is submitted, when the request is made, what turnaround Odoo applies to it, and who coordinates the exchange on each side. Also agree what happens if a test cycle uncovers a blocking issue that requires a second upgraded copy. Ask your partner to build that wait into the test schedule so that module fixes, data checks and sign-off have room to run. Do not start the production cutover plan until the turnaround and the number of test rounds are both confirmed.
On-premise use of the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. Before you submit anything, confirm that the subscription covers the on-premise environment and the test use you intend. Decide who holds the subscription code, how many test copies the team expects to create, and whether the subscription stays active through the whole test cycle and the cutover. Record these answers in the project plan so that test activity is not interrupted by a licensing gap. If your organization runs Community, the path to 18.0 is different and is covered by the Community upgrade guidance elsewhere on this page.
The Odoo 17 to 18 upgrade sequence, with checks and rollback points
This sequence takes a production Odoo 17.0 database to 18.0 in eight ordered steps. Each step closes with a check that must pass before the next step starts, and a rollback point that names what is restored and from which backup. Production stays on 17.0 until the final cutover step is signed off.
Freeze scope and record the source version
The project owner and the implementation team agree the scope in writing and freeze configuration changes on production for the upgrade period. The team records the exact Odoo 17.0 build, Enterprise subscription status, installed apps, custom and third-party modules, and the database name. Before porting starts, the sponsor decides whether the target is 18.0 alone or a stop on the way to 19.0 or 20.0. Standard support for 18.0 runs until September 2027, for 19.0 until September 2028 and for 20.0 until September 2029. Check: the signed scope and version record match the running instance. Rollback point: none is needed yet, because production on 17.0 stays untouched and becomes the restore target for every later step.
Take and verify backups
The team takes a full database dump and a copy of the filestore from production, with writes paused for the window agreed in step one. Together these two parts form the complete restore set for this upgrade, so they are stored away from the source server and their checksums are recorded. The team restores the dump to a scratch server, signs in, and compares record counts for key models and a sample of attachments against production. Check: the scratch restore opens, and the counts and sampled attachments match. Rollback point: this verified backup set is what gets restored to production if any later step fails.
Inventory custom code and integrations
The team lists every custom module, its dependencies, server actions, scheduled actions, reports and external integrations, including any system that calls the Odoo API. Each item gets an owner and a decision: port it, replace it with a standard feature, or retire it. Changes made directly in the database, outside any module, are listed as well, because they do not appear in version control and are easy to miss. Check: every item has an owner and a signed decision, and the list has been compared with the module list on the source server. Rollback point: none is needed, since this step changes nothing on the source system.
Request and receive the upgraded test database
On an Enterprise subscription, the team requests an upgraded test database through Odoo's upgrade service, which moves a copy of the database to 18.0. Odoo's documentation says this test database should be tested before production is touched. Community deployments have no access to the upgrade service, so they follow the OpenUpgrade path instead. The team opens the upgraded copy and checks that the installed module list matches the inventory from step three, recording any module that is reported as unavailable or changed. Check: the upgraded test database loads, and its module list and record counts match the source. Rollback point: production stays on 17.0 and the upgraded copy is discarded, so no restore is needed.
Port custom modules and resolve deprecations
Developers update each custom module for the Odoo 18.0 framework, covering manifests, views, model methods and any interfaces that changed, then install the modules on the upgraded test database. Each change is committed to version control so it can be reviewed and reverted. Deprecation warnings are fixed at the source, and each module installs on its own before the full set is installed together. Check: all custom modules install without errors on the upgraded test database, and the server log shows no errors from them during installation. Rollback point: revert to the last commit on the source branch, then reinstall on a fresh copy of the upgraded test database. Production is unaffected.
Run functional tests on neutralized copies
The team creates test copies of the upgraded database with neutralization, so outgoing email, payment provider connections and scheduled actions cannot reach customers or suppliers. Test cases follow the processes that matter most, such as quote to invoice, purchase to receipt and month-end close, and each one is run by the process owner. Defects are logged with a severity and retested after each fix. Check: the process owners sign off the results, and no high severity defects remain open. Rollback point: discard the neutralized copies and fix the code on the branch. Production has not changed.
Merge and verify the filestore
The team combines the upgraded database with the filestore from the verified backup, placing the files where the upgraded database expects them. Attachment counts and checksums are compared with the backup manifest, and a sample of documents from each functional area is opened and printed. Any attachment that does not resolve is traced to its record before the database is accepted. Check: counts and checksums match the manifest, and the sampled documents open and render. Rollback point: remove the merged filestore from the test location and restore it from the verified backup archive. The production filestore is untouched.
Rehearse cutover, then go live
The team takes a fresh production backup in the agreed window, runs the full upgrade on a second copy, and times each stage against the cutover plan. The rehearsal repeats the checks from steps two, six and seven. The sponsor then confirms the go-live target. If it is 19.0 or 20.0, porting and testing are repeated for that version before go-live. Only after the rehearsal passes and a written go or no-go is signed is production cut over and monitored. Check: every rehearsal check passes. Rollback point: production remains on 17.0 until switchover, and if the cutover fails afterwards, the team restores the pre-cutover backup taken in this step.
How custom module porting and filestore merge shape the work
Custom code decides whether the upgraded database can be tested at all, so porting has to finish before anyone signs off on the 18.0 test copy. Every custom module, and every piece of logic built in Odoo Studio or written by an outside developer against 17.0, must be checked against 18.0 APIs, view structures and data models. In practice that means reviewing the module manifest and dependencies, Python model overrides and method signatures, XML views and inherited view references, QWeb templates, JavaScript assets and security access rules. If a module depends on a field, view or method that changed between the two versions, the port is not complete until that dependency is rebuilt or removed. Studio customizations are stored in the database itself, so they need the same review on the upgraded test copy.
The porting inventory is the first deliverable to plan around. List every custom module, its owner, its source (in-house, contractor, Odoo Apps Store or Odoo Community Association), and whether a 18.0 version already exists from that publisher. For each item, decide whether to port, rebuild on standard features, or retire it. Third-party modules often lag behind a new major version, so confirm their 18.0 availability with the publisher before committing a timeline. Your team should also decide who signs off on each ported module, because a module that installs without errors can still change business behavior, such as a computed price, an approval step or a report layout. Ask any partner quoting the work to base the quote on this inventory, not on a generic module count, and to state which items are out of scope.
The filestore merge is the step where files and database records are reconciled. In Odoo, attachments, documents, product images and generated PDFs live on disk in the filestore, while the database holds the records that point to them. After the upgraded database is created, each attachment record must still resolve to a file that exists and opens correctly. Verify this with counts of attachment records against files, a sample of documents from each business area, and a check that downloads from quotations, invoices and HR records work. Illustrative example: a quotation PDF attached to a sales order may still show in the list while its file is missing, and the error appears only when a salesperson opens it. Confirm with current Odoo documentation how the filestore is carried across for the upgrade service and for on-premise upgrades, and whether any path or permission settings change.
Testing depends on a neutralized copy, and the copy must be configured deliberately before anyone trusts the results. Odoo documents database duplication with neutralization for test copies, which is designed to keep a test environment from sending mail, running scheduled actions or reaching live integrations. Confirm in the current documentation exactly which settings are neutralized in your version, then re-enable integrations one at a time under test credentials. Build the test script from real business transactions across sales, purchasing, inventory and accounting, and include a document download from each area. Keep a record of which custom modules and attachments were verified, because that record becomes the evidence for cutover. Ask for the quote to show the module inventory, the filestore verification steps and the test cycles separately, so you can see what drives the cost and what you can take in-house.
What makes an Odoo 17 to 18 upgrade take longer
This table lists the drivers that most often lengthen an Odoo 17 to 18 upgrade, why each one matters and what to check before scope is agreed. Read each row against your own database, filestore and approval process, since the same app list can need very different effort across single-company and multi-company databases. Each driver should appear in the written quote with a measured count, the environment it runs in and the named sign-off owners.
| Driver | Why it matters | What to check |
|---|---|---|
| Custom modules | Each custom module must be ported to 18.0 and retested, and deeper changes to models, views or business logic need more review. | Count modules and lines of code, and identify any that override core models or depend on Enterprise-only features. |
| Third-party connectors and integrations | Connectors to payment, shipping, banking or identity systems need version checks and live-path testing after the upgrade. | List each connector, its Odoo 18 compatibility source and every external system it calls in production. |
| Apps in use and data volume | Heavier apps such as accounting, inventory and manufacturing hold more records and need more migration checks. | List installed apps, record counts for the largest models and any historical or archived data that must carry over. |
| Filestore size | Attachments live outside the database, so copying and checking them adds work and slows every test refresh. | Measure the filestore size and attachment count, and confirm how it will be copied to each test environment. |
| Number of companies and configuration | Each company has its own chart of accounts, taxes, journals and sequences that must be verified separately. | Count companies, shared records, currencies and fiscal localization settings that differ between companies. |
| People who sign off on tests | Each approval group needs scheduled time, and open issues return to the queue when approvers are unavailable. | Name the approver for each business process, their test scripts and the decision date needed before cutover. |
| Second environment for rehearsal | Without a rehearsal copy, the first full run happens on production-like data, which is where defects usually surface. | Confirm whether a neutralized copy of production can be refreshed for repeated test runs before go-live. |
How testing and rollback work before the cutover
An Odoo 17 to 18 cutover is only as safe as the evidence behind it. The cards below cover the test layers, the rehearsal, the decision gate and the rollback path, and they depend on each other: a rehearsal proves the scripts, the go or no-go criteria rely on the rehearsal results, and the rollback relies on a backup that was verified before anything changed.
Functional test scripts from real processes
Write test scripts from the business processes your staff run every day, such as quote to cash, purchase to pay, stock moves, month-end close and payroll runs, rather than from the module list. Each script should name the data it starts with, the steps, the expected result and the person who signs it off. Run the scripts on the upgraded 18.0 test database, and record every failure with its module and version so porting fixes can be traced back to a specific test.
Integration tests against neutralized connectors
Connectors to payment providers, banks, shipping carriers, identity providers and other systems must be tested without sending live transactions or writing to external systems. Use a neutralized test copy, point integrations at sandbox endpoints, and confirm that outbound messages are blocked or logged. Check the API and authentication paths that changed in the upgrade, and confirm the test environment cannot reach production credentials.
Rehearsal on a production-sized copy
Run the full upgrade at least once on a copy of production that matches its data volume, including the filestore, attachments and the largest tables. The rehearsal measures how long the database upgrade and module update take, exposes migration errors that small datasets hide, and gives the team a timing baseline for the cutover window. Ask the partner to record each step and its duration so the production runbook reflects what actually happened.
Go or no-go criteria
Agree the decision rules before the cutover, not during it. Typical criteria include: all critical process scripts pass, no open blocker defects in the integration tests, the rehearsal completed within the agreed window, the backup verification has passed, and named approvers have signed off. Each criterion should have an owner and a yes or no answer, so the cutover decision is made from written evidence.
Rollback to the verified pre-upgrade backup
The rollback plan restores the verified pre-upgrade backup of the 17.0 database and filestore, then reopens the 17 system for users. Rehearse the restore on the copy as well as the upgrade, and time it. Rollback is only clean if the backup was verified and no production writes happened after it. Agree in writing the window in which the team will accept rollback, who can call it, and what happens to transactions entered after the backup if it is invoked.
Freeze window and write control
Set a freeze on production writes from the moment the final backup is taken until the go decision is confirmed or the rollback is complete. Document who is allowed to make changes during the freeze, how users are told the system is unavailable, and how integrations that push data into Odoo are paused. Without this control, a rollback can silently discard valid transactions, so the freeze should be written into the cutover plan and checked by a named owner.
Questions buyers ask before outside help on the Odoo 17 to 18 upgrade
How much does an Odoo 17 to 18 upgrade cost?
No public price applies to this work, and the figure depends on the written scope. The main cost drivers are the number of installed apps, how many depend on Enterprise-only features, the amount of custom code that needs porting to 18.0, the volume and complexity of data to check after the move, and the hosting model. Some costs are one-time, such as the upgrade project and testing. Others recur, such as the Enterprise subscription that on-premise upgrades require and any support or retainer you choose afterwards. Ask any provider, DeployOpen included, to split the quote into analysis, module porting, testing, cutover and post-upgrade support, and to state which items are fixed and which depend on findings. Confirm current Enterprise subscription terms directly with Odoo.
How long does an Odoo 17 to 18 upgrade take?
Duration depends on the scope, so no fixed timeline applies to every database. The biggest variables are the number of custom modules and integrations, the number of test cycles your business needs, how quickly process owners respond, and how much data needs reconciliation. Timing pressure is real because Odoo 17.0 standard support ended in September 2026, while Odoo 18.0 standard support runs until September 2027. Ask for a schedule that shows analysis, porting, each test round, the cutover window and the rollback plan as separate phases. Ask the provider which assumptions the schedule depends on, such as the availability of your testers, and what happens if a test round fails.
Can our own team upgrade Odoo 17 to 18 without a partner?
Yes, an internal team can do the upgrade if it has the right skills and time. The work needs working knowledge of Python, PostgreSQL, the Odoo framework and module structure, Linux administration, Git for custom code, and a disciplined test process. Teams often underestimate the porting of custom modules and the reconciliation of data after the database moves. Enterprise customers running on-premise can use Odoo's upgrade service with a subscription, which changes the work from manual migration to testing the upgraded test database. Community users follow a different path with OpenUpgrade. Assess your team's capacity honestly, including the time your developers spend away from current projects, before deciding.
What does the business need to provide during the upgrade?
The business provides decisions, people and time, and the upgrade stalls without them. Name a process owner for each area in use, such as sales, inventory, accounting or payroll, so that someone can decide which behavior changes are acceptable. Assign testers who know the daily workflows and can run the same transactions in the test database that they run in production. Agree on who signs off each test round and the final cutover, and define what counts as a pass. Your team also needs to confirm the cutover window with operations and to freeze or plan changes to data during the window. Ask the provider to list these roles and time commitments in the written scope.
Should we upgrade to Odoo 18 or jump to 19 or 20?
The choice depends on your support deadlines, your custom code and what the upgrade service supports on your hosting model. Odoo 18.0 standard support runs until September 2027, Odoo 19.0 until September 2028 and Odoo 20.0 until September 2029, so a later target gives a longer support runway but may mean more changes in one project. Each major step still requires testing, so a multi-version jump adds risk unless the analysis supports it. Confirm with Odoo whether the upgrade service and your edition support the exact path you plan, and check the version-specific changes for each target. Read the separate pages on the Odoo 18 to 19 and Odoo 19 to 20 upgrades before you commit to a target.
Can Odoo Community users use the official upgrade service?
No, Odoo's upgrade service is not available to the Community edition. Odoo's documentation states that the Community edition has no access to the upgrade service, and that on-premise use of the service requires an Enterprise subscription. Community users who want to move from 17 to 18 typically use OpenUpgrade, a community project that migrates a database one major version at a time. OpenUpgrade work requires module coverage checks, ports for any custom or community modules you depend on, and full test runs before cutover. Read the Odoo upgrade documentation for the official position, and review the OpenUpgrade project materials for the migration method. Confirm module availability for your specific apps before planning the work.
Does an on-premise Odoo installation need an Enterprise subscription for upgrades?
Yes, Odoo's documentation states that on-premise use of the upgrade service requires an Enterprise subscription. The Enterprise source code is not publicly available, so Enterprise databases need a subscription or partner access, and they are activated by entering the subscription code. Community installations cannot use the upgrade service at all. If you run Enterprise on-premise and plan to upgrade, confirm with Odoo that your subscription covers the upgrade service, the target version and the number of databases involved, including test copies. Also confirm how Odoo handles subscription changes during the project, since a lapse could block activation or support. Ask your provider to list these checks as prerequisites in the written scope.
What should a written scope for this upgrade include?
A useful scope lists what is in and out, so that both sides can measure progress. Include the current and target versions, the edition, the hosting model, and every installed app, with its Community or Enterprise status. List each custom module, third-party module and integration, along with its owner and the work expected to port it. State the data volume, the environments involved, and how test copies are made and neutralized. Define the test rounds, acceptance criteria, cutover plan, rollback approach and sign-off roles. Cover post-go-live support and any exclusions, such as changes to processes or new features. DeployOpen works on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts, so ask any provider to put these items in writing.
How DeployOpen works on this upgrade
DeployOpen plans the Odoo 17 to 18 upgrade as a fixed-scope engagement, with the scope agreed in writing before work starts. The work runs against an upgraded test database that is tested before any production cutover, and it stays inside infrastructure the client controls.
How we scope
- Inventory every installed app, custom module and third-party connector running on the Odoo 17 database.
- Confirm whether the database is Odoo Online, Odoo.sh or on-premise, and whether it runs Enterprise or Community.
- Agree in writing which custom modules are ported, which are retired and which test databases are included.
How we build
- Request an upgraded test database for 18.0 and run it against a neutralized copy of production data.
- Port custom modules to the 18.0 API, then run functional tests for each business process the modules support.
- Check the filestore merge and attachment handling, and record every defect found in the test cycle.
How we hand over
- Document the module changes, configuration decisions and test results in a form your administrators can reuse.
- Walk through a rehearsal of the production cutover so your team knows the steps, owners and rollback points.
- Hand over the ported code in your version control system, with the deployment steps written for your environment.
How we support
- Agree a post-cutover window in the scope to fix defects found in the first working period on 18.0.
- Offer ongoing support, upgrades and testing as a retainer if you want continued help after the handover.
- Note that Odoo 18.0 standard support runs until September 2027, so plan the next upgrade path early.
