Odoo 20 Studio Upgrade: What Carries Over, What Breaks, and How to Test It Before Go-Live

Odoo Studio lets administrators change a database without writing a module. That convenience is also the reason Studio upgrades need a plan. The customizations are not part of Odoo’s standard code, yet they depend on it. Fields, views, automation rules, reports, and access settings all sit on top of standard models and screens that Odoo 20 may have changed.

This guide explains what Odoo’s upgrade service does with Studio customizations, what it leaves to you, and how to check every layer before you upgrade production. It covers Odoo Online, Odoo.sh, and self-hosted databases. Where Odoo’s documentation does not settle a question, the guide says so and tells you what to test.

How to read the labels in this guide

- Documented: stated in Odoo’s official documentation or release notes.

- Secondary: reported by a reputable third party and not confirmed on an official page.

- Recommended: good practice, not an Odoo rule.

- Verify: not confirmed in the sources available when this guide was written. Test it on your own Odoo 20 database.

Quick answer

 

- Odoo’s upgrade service converts Studio customizations when Studio is still installed and the subscription is active. Documented.

- Conversion is technical. It does not prove that your automations, reports, or permissions still behave as intended.

- Odoo lists automated actions that use Python code as outside the upgrade service level agreement (SLA). Review those by hand. Documented.

- A Studio export is not a backup. It is also not a documented way to carry customizations to a newer Odoo version. Documented.

- Request an upgraded test database, read the upgrade report, and test by role and by business process before you touch production.

1. What Odoo’s Upgrade Does With Studio Customizations

What the upgrade service covers

Documented. With an Odoo Enterprise subscription, Odoo upgrades the database to the newer version at no extra charge. The service covers standard apps and customizations created with Studio, as long as Studio is still installed and the matching subscription is still active. Developments covered by a maintenance-of-customizations subscription are also included.

What the upgrade service does not cover

Documented. Odoo’s upgrade terms list several services as not included:

- cleaning of existing data and configuration

- upgrading custom modules built in-house or by third parties

- code added to standard modules outside Studio, including code entered manually and automated actions that use Python code

- training on the new version

This wording has been in Odoo’s upgrade documentation since 2023. Verify that it is unchanged on the live 20.0 upgrade page before you rely on it.

The Python exclusion matters. Studio can create automation rules whose action is Python code. They are Studio objects, yet they fall under the exclusion. Treat “covered by the upgrade” and “guaranteed to work” as two different statements.

Conversion is not validation

The upgrade adapts the database technically. It cannot know that your approval flow depends on a certain field, that finance relies on a filter, or that a report must show one custom block. Odoo’s own documentation asks you to test the upgraded copy thoroughly and to report problems in standard behavior through its Support page, using the option for an upgrade under test.

Where Studio changes live

Documented. Studio groups its changes in a module named studio_customization and can export it as a ZIP file. The export holds the definitions of custom models and fields and the interface changes in XML.

In practice, the changes are database records, not source files:

Because none of this lives in a code repository, nobody can see a difference of what changed. That is why Section 3 starts with an inventory.

2. Choose Your Upgrade Path

Online, Odoo.sh, and self-hosted compared

 

Documented. The command form -t <target version> and the option to request a test through the upgrade platform page appear in the 20.0 upgrade documentation. The 20.0 page also describes a silent test upgrade run by Odoo’s Upgrade Team. If it succeeds in under 20 minutes, you can trigger the upgrade from the database. If it fails, request a test through the database manager. The passage seems to describe Odoo Online. Verify which hosting types it applies to.

Source version and timing

Secondary, citing Odoo’s documentation. You can upgrade directly to any supported version, and a smaller version gap is easier. Odoo supports each major version for three years. Version 17.0 standard support was listed as ending in September 2026 (planned). Check the current support table before you decide.

Databases that also have custom modules

Documented. Odoo defines a custom module as any module that extends standard code and was not built with Studio. A database with custom modules cannot be upgraded until a version of those modules exists for the target version.

Recommended. This affects Studio work too. Many Studio changes sit on views, models, or fields that come from a custom or third-party module. List every Studio item whose parent belongs to such a module. If the module is not ported, those items have nothing to attach to.

3. Build a Studio Inventory First

Odoo advises comparing your customizations with the new standard features and removing the ones that became redundant. You cannot do that without a list.

What to list

Switch on developer mode and use the technical menus. Menu names vary by version.

Capture a baseline

Record “before” values on a copy of production so that you can compare them later.

1. Field population. For each important custom field, count populated rows:

SELECT COUNT(*)                         AS total_rows,

      COUNT(x_studio_po_approval_ref)  AS populated_rows

FROM   sale_order;

2. List of manual fields. This includes fields created outside Studio, so review the result:

SELECT m.model, f.name, f.ttype, f.store

FROM   ir_model_fields f

JOIN   ir_model m ON m.id = f.model_id

WHERE  f.state = 'manual'

ORDER  BY m.model, f.name;

3. Visible records per user. For each test user, note how many records of key models they can see (Section 6).

4. Key reports. Save PDFs of printed documents made from real records.

5. Screens. Save screenshots of key forms.

Run queries only on a copy, in a read-only session. They apply to self-hosted and Odoo.sh databases. On Odoo Online, use the interface and exports instead.

Decide what each item becomes

4. Backups and the Studio Export

A backup and an export protect different things

 

Documented. The export screen lets you choose models and whether to include data and demo data. Odoo’s Studio pages for versions 18 and 19 describe these options. Verify the exact options on the 20.0 page.

Why the export is not an upgrade tool

Documented. Odoo warns that, before importing, the destination database should run the same Odoo version as the source and contain the same apps and modules. Studio does not add the underlying apps as dependencies of the exported module.

So an export taken on Odoo 19 is not a documented way to restore customizations on Odoo 20. The documented route is the upgrade service. Verify the warning text on the 20.0 Studio page.

A better use: a readable before-and-after record

Recommended.

1. Export Studio customizations from the production copy before the upgrade request.

2. Unzip the file and store it in a version-control repository.

3. After the upgrade, export again from the upgraded test database.

4. Compare the two sets of XML.

Treat differences as clues, not as proof. First confirm on a test database what your export includes, for example inactive views.

Backup details by hosting type

- Odoo Online: use the database manager. Documented: the download option can be disabled for very large databases.

- Odoo.sh: use the backup tools in the project, and keep a manual backup before production day.

- Self-hosted: back up the database and the filestore together. Recommended: restore the backup on a separate machine once, so you know it works.

5. Request the Test Upgrade and Read the Report

A test database is a safe copy, not a draft of production

Documented. Changes made on a test database are not carried to production. Odoo recommends requesting new test databases as work progresses, because upgrade scripts and your data keep changing.

What a test database switches off

Documented in Odoo’s upgrade documentation for earlier versions, with the practice continuing since. Verify on 20.0:

- Scheduled actions are disabled.

- Outgoing mail servers are archived and replaced with a non-working one.

- Payment providers and delivery carriers are reset to a test environment.

- Bank synchronization is disabled.

For Studio, the first point is the important one. Time-based automation rules run through scheduled actions. On a test database they will not fire by themselves, so “nothing happened” does not mean “it works.” Section 7 shows how to test them.

Read the upgrade report

Documented. When an upgrade request finishes, Odoo sends a success email with an upgrade report. The report is also available in Discuss for users in the Administration or Settings group. It lists changes made to your data, including custom views that were disabled.

Triage the report in three groups:

1. Blockers: disabled views on key screens, missing fields, and errors.

2. Behavior changes: renamed labels, moved fields, and changed menus.

3. Cosmetic changes: icons, spacing, and wording.

Odoo’s documentation suggests asking whether a view is inactive on the test database but active in production. Compare the two before you decide a view is broken.

Repeat until the result is stable

Recommended. Request a fresh test upgrade after each round of fixes and run the same tests again. Stop only when two consecutive runs show no new blockers.

6. Check Each Studio Component

Views and XPath

Studio stores a view change as an inherited view. The inheritance finds a place in the parent view with an XPath expression, then adds, moves, or hides an element there. If Odoo 20 changes the parent view, the anchor may no longer exist.

This inheritance adds a custom field after the payment terms on a sales order form:

<xpath expr="//field[@name='payment_term_id']" position="after">

  <field name="x_studio_po_approval_ref"/>

</xpath>

It works only while payment_term_id is present in the parent form. If Odoo 20 moves, renames, or removes that field, the inheritance cannot be applied and Odoo disables the view. Documented: Odoo disables views that fail during an upgrade and lists them in the upgrade report. Its guide for customized databases names XPath expressions that moved or were removed as a common cause.

What to check

• The upgrade report lists the view as disabled, or the screen no longer shows your field.
• The anchor still exists in the Odoo 20 parent view.
• Anchors that depend on position (for example, “the third group in the sheet”) are more fragile than anchors that depend on a named element. Recommended: review which kind each of your Studio views uses.

Find the failing views (self-hosted and Odoo.sh). Run this on a test copy:

SELECT v.id, v.name, v.model, v.write_date, d.module, d.name AS xml_name

FROM   ir_ui_view v

JOIN   ir_model_data d ON d.model = 'ir.ui.view' AND d.res_id = v.id

WHERE  v.active = false

AND    v.inherit_id IS NOT NULL

AND    d.module = 'studio_customization'

ORDER  BY v.model, v.id;

The query assumes that Studio views carry external IDs in the studio_customization module. Verify that on your database. Run the same query on production and compare, because some views may be inactive on purpose.

Log message to search for. An XPath that cannot be applied normally produces an error saying that the element “cannot be located in parent view.” Wording varies by version.

Fix. Open the screen in Studio and place the field again. Studio then writes a new inheritance with a fresh anchor. Recommended. For views that belong to a custom module, Odoo recommends fixing the code and using an upgrade script to reactivate the view or remove it. Documented.

Fields, models, and data

Documented. Odoo’s upgrade documentation describes a specific data-loss path. When a standard model is removed or merged into another, the standard upgrade scripts move the standard data to the replacement. They do not move custom fields that users created. The old table is then dropped, with the custom data still in it. Odoo’s example is an older release in which the invoice model was merged into the journal-entry model. Odoo states that such data cannot be recovered once the production upgrade is finished.

Odoo’s Upgrade Team can sometimes rescue the fields, but the work is manual and it must happen before the production upgrade. Give the team the field names, the model they were on, the reason they were removed, and the model or field where they should go.

Why this matters for Odoo 20. Odoo 20 replaces some standard structures. Reported examples include account groups replaced by parent accounts and asset models replaced by depreciation models. Secondary, quoting the release notes. If you added Studio fields to a model of that kind, raise it with Odoo before production.

What to check

• Compare the field-population counts from Section 3 before and after the upgrade.
• Compare selection values, defaults, required flags, and relation targets for each critical field.
• Odoo 20 makes the technical names of new Studio fields more readable. Documented in the release notes. Existing names are unlikely to change, but Verify that, and check integrations that call fields by name.

Automation rules and server actions

Python code in automation rules is outside Odoo’s upgrade SLA, so review each rule by hand.

1. References. Every model and field the code uses must exist in Odoo 20.

2. Conditions. A domain that uses a selection value or a status label can silently stop matching.

3. Loops. A rule that writes a field it also watches can trigger itself.

4. Timing. Time-based rules do not fire on a test database.

This pattern avoids loops because the rule’s filter excludes records that already have the change:

• Model: Purchase Order
• Trigger: on create and update
• Filter: total is greater than 5,000 and x_studio_requires_review is not set

# Python code of the server action

for order in records:

    order.write({'x_studio_requires_review': True})

A quick static check (self-hosted and Odoo.sh). Run this in the Odoo shell on the upgraded test database. It lists Python server actions that read attributes their model no longer has. It is a screening tool, not proof, because it cannot see dynamic access such as record[field_name]. Adjust the variable names to match your code.

 

import re



pattern = re.compile(r'\b(?:record|records|order|rec)\.([A-Za-z_][A-Za-z0-9_]*)')

for action in env['ir.actions.server'].search([('state', '=', 'code')]):

    model = env[action.model_id.model]

    names = set(pattern.findall(action.code or ''))

    missing = sorted(n for n in names if not hasattr(model, n))

    if missing:

        print(action.id, action.name, action.model_id.model, missing)

Standard actions appear in the result as well. Ignore the ones that are not yours.

Then test each rule with realistic records. Outgoing mail is blocked on the test database, so messages will not reach customers. Check the resulting data, not only the absence of errors.

Access rights

Documented. Odoo 20’s security reference describes an access right as having a group, an operation (any combination of create, read, update, and delete), and an optional domain. A user can perform an operation on a record when one of their groups has a matching access right and the record fits its domain. Rights from different groups add up. A right with no group acts as a restriction on every user and narrows what group rights allow.

Secondary, quoting the release notes. Record rules are removed, and a domain now sits directly on the access right. Sources describe a single model, ir.access, that replaces ir.model.access and ir.rule.

Verify. The sources available when this guide was written do not say how manually created record rules and Studio-created access settings are converted. Do not assume. Measure the result.

The visibility-fingerprint test

1. Pick one real test user per role, not an administrator.

2. On production (read-only), record how many records of key models each user can see.

3. On the upgraded test database, run the same counts and compare.

# Odoo shell on the test database. Logins and models are examples.

for login in ('branch.clerk@example.com', 'branch.manager@example.com'):

    user = env['res.users'].search([('login', '=', login)], limit=1)

    for model in ('sale.order', 'purchase.order', 'x_studio_site_visit'):

        count = env[model].with_user(user).search_count([])

        print(login, model, count)

search_count goes through access rights, so the number reflects what that user is allowed to see. After the counts match, sign in as each user and try to create, edit, and delete records.

A two-company example matrix:

Never validate security as an administrator. Administrator accounts can hide missing restrictions.

If Studio sits on a custom module, that module’s own security files must be ported to the new format. Secondary: modules that still use the old files fail to install in Odoo 20.

Reports

Documented. Studio reports are inherited templates built from elements such as t, div, and table, and an XPath targets those tags. Repairing them uses the same method as repairing views.

Odoo 20 introduces a new report editor interface. Documented in the release notes. Verify that an existing customized report opens and saves correctly in it.

On the PDF engine: wkhtmltopdf is the long-standing engine. Secondary sources report that Odoo 20 also offers Paper Muncher, an Odoo-built engine that is still pre-1.0, as an optional alternative. Verify this, and use the same engine on both sides of any comparison.

Compare PDFs by text

pdftotext -layout before.pdf before.txt

pdftotext -layout after.pdf after.txt

diff -u before.txt after.txt

Print the same real record on production and on the test database. Ignore print dates and sequence numbers. Confirm totals, taxes, currencies, custom blocks, page breaks, headers, footers, and languages. A report that looks right but shows different numbers is worse than one that is visibly broken.

Integrations

Documented. Odoo’s external API reference states that the db service was removed in Odoo 20. The common and object services are deprecated and scheduled for removal in Odoo 22. The JSON-2 API replaces them.

What to check

• Any call that creates, duplicates, drops, or lists databases through the API breaks in Odoo 20.
• XML-RPC and JSON-RPC calls to common and object still work until the later removal, but plan the move.
• API users still have the access they need (see Access rights above).
• Custom fields are still called by the correct technical name.
• Connect test systems to the test database only, and use test credentials. A test database blocks outgoing mail, but it does not stop an external system from posting data to it.

A JSON-2 sample. Adapt it and check it against the 20.0 reference:

import requests



DOMAIN = 'your-odoo-host.example'

API_KEY = '<keep this in a secret store>'



response = requests.post(

    f'https://{DOMAIN}/json/2/sale.order/search_read',

    headers={'Authorization': f'bearer {API_KEY}'},

    json={

        'domain': [['x_studio_po_approval_ref', '!=', False]],

        'fields': ['name', 'x_studio_po_approval_ref'],

        'limit': 5,

    },

)

print(response.json())

Other Odoo 20 changes that can touch Studio logic

7. Test by Object, Role, and Process

Three layers of testing

Most failures show up at the role and process layers. Test those first for critical flows.

A test case template

 

Write one row for each inventory item rated critical. Record pass or fail and the tester’s name.

Testing scheduled and time-based behavior

Scheduled actions are disabled on a test database, so run them on purpose. Open the scheduled action and use Run Manually, or change a record’s date so that the rule’s condition becomes true and then run the action. Do not switch scheduled actions on broadly in a database that is connected to live external systems.

Multi-company checks

Test with a user who can access only one company, a user who can access several, and a user with several companies selected in the company switcher. Check records meant to be shared and records that must stay private. Check reports and exports as well as screens.

Read the logs

Run a full day of test cases, then search the Odoo log:

grep -E 'Traceback|ERROR|cannot be located in parent view' /var/log/odoo/odoo.log

Replace the log path with yours. On Odoo.sh, use the log viewer in the project. Every unexplained error needs an owner and a result before sign-off.

Exit criteria

Recommended. Treat testing as passed when:

• every critical process test passes with evidence
• no unexplained disabled views remain
• visible record counts match the baseline for each role
• report differences are explained
• integration smoke tests pass
• named business owners have signed off

8. Repair a Broken Studio View Without Resetting Everything

Resetting every Studio view throws away good work along with the problem. Repair one item at a time instead.

1. Identify the exact view from the upgrade report.

2. Classify it: is it still needed, or is it obsolete?

3. Copy the current XML to a safe place.

4. Fix the smallest piece: place the field again in Studio, or remove the obsolete change.

5. Reactivate the view only after the cause is fixed. Reactivating alone brings the same failure back.

6. Retest the process that uses the screen.

7. Record the fix in your runbook (Section 9).

 

Verify. Studio offers a restore-to-default action for a view. It discards all Studio changes to that view, not only the failing one. Check the label and behavior in your build, and use it only after saving a copy.

9. Plan the Production Cutover

Freeze, then replay your fixes

Documented. A test database stays separate from production, so fixes made there do not carry over. Keep a runbook: a dated list of every fix with exact steps, so that someone can repeat each one in production after the upgrade. Freeze data entry for the cutover window. The production database is unavailable while the upgrade runs.

Rollback

Documented. Odoo warns that data lost during the standard upgrade cannot be recovered once the production upgrade is complete. So the realistic rollback is restoring the pre-upgrade backup. Recommended:

• Take and verify a full backup (database and filestore) right before the upgrade.
• Decide in advance who may call a rollback and by what time.
• Remember that a restore loses anything entered after the backup, which is why the freeze matters.
• Practice one restore on a separate system.

After go-live

Recommended. For the first week:

• Review error logs every day.
• Print the key reports and compare them with the baseline.
• Confirm that automation rules ran and produced the expected data.
• Keep one channel for user reports and sort them by cause.
• Export Studio customizations again and store them as the new baseline.

Documented. Report production upgrade issues through Odoo’s Support page and select the option for an issue related to your upgrade in production.

10. Final Sign-Off Table

Official documentation referenced

• Odoo 20.0, Upgrade: https://www.odoo.com/documentation/20.0/administration/upgrade.html
• Odoo 20.0, Security in Odoo: https://www.odoo.com/documentation/20.0/de/developer/reference/backend/security.html
• Odoo, External RPC API: https://www.odoo.com/documentation/saas-19.2/pt_BR/developer/reference/external_rpc_api.html
• Odoo, Studio models, modules, and apps (export and import): https://www.odoo.com/documentation/18.0/ja/applications/studio/models_modules_apps.html
• Odoo, Upgrade a customized database: https://www.odoo.com/documentation/saas-16.4/es/developer/howtos/upgrade_custom_db.html
• Odoo 20 release notes:
  
  https://www.odoo.com/odoo-20-release-notes

Frequently Asked Questions

1. Who is responsible if a Python automation rule breaks after the upgrade? 

You or your developer are. Odoo’s upgrade terms list automated actions that use Python code as outside the upgrade SLA. Treat each one as custom code: check its field references and conditions, then test it with real records. Report problems in standard Odoo behavior to Odoo through its Support page.

2. Can I import a Studio export from my old version into Odoo 20? 

Odoo’s Studio documentation for versions 18 and 19 says the destination database should run the same Odoo version and contain the same apps as the source. That makes cross-version import an undocumented path. Use the upgrade service for the move, and keep the export as a reference. Verify the warning on the 20.0 page.

3. Why is a Studio field empty or missing after the upgrade? 

There are two common causes. The field may sit on a model that Odoo removed or merged, in which case its data can be dropped. Or the field exists, but the view that displays it was disabled. Compare your field-population counts and run the disabled-view query. If data is gone, tell Odoo’s Upgrade Team before the production upgrade, because it cannot be recovered afterward.

4. Why did Odoo disable one of my views? 

When a view fails validation, Odoo disables it so the upgrade can finish. The usual cause is an XPath anchor or a field that no longer exists in the parent view. The upgrade report lists the disabled views. Fix the cause, then reactivate.

5. Why do my time-based automations not run on the test database? 

Test databases switch off scheduled actions on purpose. Run the scheduled action manually and check the data it produces.

6. Do I need to rewrite my access settings for ir.access? 

In a Studio-only database you do not edit security files. Whether your existing manual rules and Studio access settings convert cleanly is not described in the sources reviewed, so measure the outcome with a per-user visibility count. Custom modules do need their security files ported.

7. Will my Studio reports look identical in Odoo 20? 

Not necessarily. Report changes are inherited templates whose anchors can move, Odoo 20 has a new report editor, and the PDF engine can differ. Compare the printed text and totals of the same record before and after.

8. Will my XML-RPC integration stop working in Odoo 20? 

Odoo’s API reference says the db service was removed in Odoo 20, while the common and object services are deprecated and scheduled for removal in Odoo 22. Calls that manage databases will break now. Others should keep working for now, but plan the move to JSON-2.

9. How many test upgrades should I run? 

Odoo recommends requesting fresh test databases as work progresses. A practical rule is to repeat until two consecutive runs show no new blockers, then rehearse once more close to the go-live date.

10. What happens if Studio is uninstalled or the subscription lapses before I upgrade? 

Odoo ties its coverage of Studio customizations to Studio being installed and the subscription being active. The sources reviewed do not say what happens otherwise. Ask Odoo before you change either.

11. Should I move Studio customizations into a custom module before upgrading?

Only for complex or Python-heavy logic that you want under version control. Custom modules fall outside Odoo’s upgrade service, so you will port them for every version. Simple fields and views are usually lighter to keep in Studio.