How to Upgrade to Odoo 20 Without Losing Studio Customizations

Odoo Studio allows you to tailor business applications without having to create a whole new module.

Functional consultants and Odoo administrators can easily add fields, modify views, implement workflows and other automation, change approval workflows, and customize reports with virtually no coding.

Nonetheless, during the update from the Odoo database to Odoo 20, all these customizations should be checked carefully since the customization that performs flawlessly in the current version might rely on a certain structure of view, field, security settings, or report that has been modified in the new version.

While Odoo Enterprise's upgrade service supports the update of Studio customizations provided that Studio is still installed and its subscription is active, it does not take place of the necessity to test the business process.

This document describes the potential pitfalls of Odoo Studio customizations and suggests a checklist for Odoo 20 upgrade preparation.

1. Why Studio Customizations Need Special Attention

Various aspects of the Odoo application can be impacted by Studio customizations:

• Views - custom fields, buttons, groups, and view modifications.
• Automations - automated actions, approvals, and scheduling of actions.
• Server Actions - custom Python scripts run against Odoo records.
• Security - user permissions and limitations on access to Odoo records.
• Reporting - custom PDF reports and printing.
• Custom models/fields - additional business objects and their relationships.
• Business processes - those that are built using custom fields, views and automations.

The danger is not in losing a customization; it is in its possible malfunction due to a change in standard Odoo behavior.Thus, the goal of a review should be to verify that all critical customizations work correctly in Odoo 20.

2. Risk One: Inherited Views and Broken XPath Expressions

Technical risk one relates to inherited views.

If Studio updates an existing form, list, or any other type of view, Odoo will treat this update as an inherited view that will modify the view structure.

In some cases, such modifications may depend on particular view elements.

For instance, this modification may relate to adding a field after another field using an XPath expression.

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

This customization relies on the assumption that there is a field partner_id in the parent view where the XPath expression points to.

In case the parent view is updated in Odoo 20, this expression may no longer point to the required element. The consequence will be a view validation error, an unactivated inherited view, or a customization that does not show up anymore.

What do you need to check?

• Make sure that the parent view is still present.
• Ensure that the XPath is still targeting an element from the new view structure.
• Check whether the field being referenced is still there.
• Examine the order of custom view inheritance.
• Look into those views that got disabled during the upgrade process.
• Make sure that custom fields are present in the right places.
• Test form, list, Kanban, search, etc., custom views if necessary.

How to fix broken views

First, locate the problematic view in the upgrade report/server log. Then, compare the inherited view structure against the standard Odoo 20 view.

Revise your XPath or change the view customization logic so that it refers to a stable element from the new view structure. Remove customization if it is not needed anymore. Do not keep obsolete XML files.

Important: There is no point in resetting all views created in Studio just because one of them broke. Fix the problematic customization only.

3. Risk Two: Server Actions Referencing Renamed or Removed Fields

Studio can generate automated actions and server actions that rely on Python expressions, field values, and business logic.

This is because, for instance, the server action can have:

if record.x_studio_approval_status == 'pending':
    record.write({
        'x_studio_approval_status': 'approved'
    })

The action will fail if the field name changes, the field is deleted, or the field is not present in the model used by the action.

Additional issues include:

• Fields from standard modules are being referenced but renamed.
• Modules containing the referenced fields have been deleted.
• Changes in the model used by the action.
• Incorrect assumptions about the record data.
• Execution context changes.
• Actions that are performed repeatedly or at unexpected times.

Validating Server Actions

• List all automated actions and server actions.
• Inspect their Python code, domains, and conditions of execution.
• Check for references to fields that have been modified.
• Make sure that the referenced models and fields exist in Odoo 20.
• Perform tests of the actions with appropriate records.
• Check that the action runs only when intended to do so.
• Scheduled actions and multiple record actions must be checked as well.

Pay special attention to actions affecting account moves, stock transfers, sales orders, purchase orders, and approval status. An action may be run without any technical error but still produce an incorrect result.

4. Risk Three: Access Rights and Record Rules in Odoo 20

Why security should be mentioned: In Odoo 20, there is a major modification in terms of the access control model.

The previous version had different solutions:

• ir.model.access - model-level control of create, read, update, and delete operations;
• ir.rule - restrictions on record level.

Now, all this functionality is combined in one ir.access model. Access control rules can contain a combination of operations, groups, and domain restrictions.

This update might influence customized security settings, such as models created via Studio and workflows depending on certain users having access to certain records.

What should you verify?

• The models that users require can be accessed by them.
• Users will not be able to access records beyond the scope allowed for them.
• All four CRUD (create, read, update, and delete) functions work properly.
• Custom groups and group assignments are intact.
• Restrictions on multi-company are intact.
• Permissions for custom models are accurate.
• Automated actions continue to work with proper permissions.
• All sensitive fields and business records are secure.

Example

Assume that the sales manager can see all the quotations, but the salesperson can see only their own quotations.

After the upgrade, you need to test both user accounts. Ensure that the salesperson is not able to see another salesperson’s quotations using any of the above mentioned methods.

Do not validate the security from the administrator perspective. An administrator always has more rights than a regular user.

5. Risk Four: Customized Reports and Printing Options

With Studio, organizations can create custom report layouts, including printed reports like quotes, invoices, and orders.

Such customization could be based on existing templates, fields, layout schemes, and reports.

Among the possible problems after an upgrade to Odoo 20 are:

• Missing custom fields.
• Lack of changes in the layout scheme or location of changes.
• Problems with inherited templates.
• Unexpected effects from the custom conditions.
• Modified paper formats or layouts for printing.
• Incorrect sums and/or lack of data.
• Wrong behavior of custom reports.

Report testing checklist

Test all significant reports by using realistic business data.

Test the following for each report:

• Company name, address, and logo.
• Details about customers and vendors.
• Custom fields and conditional sections.
• Descriptions of products and quantities.
• Taxes, totals, and currency formats.
• Page breaks and multiple pages.
• Headers and footers, paper sizes.
• PDF creation and printing.

In case of financial reports, compare the improved report to the desired output of the original system. Similarity in appearance is not sufficient if totals or numbers have been altered.

6. Risk Five: Custom Fields, Models, and Business Logic

The Studio can create fields on default models and even create new models. The customizations can then be used in views, automation rules, domains, filters, reporting, and integration.

A field can be visible in a form, but a dependent function on it may not work.

For instance, a custom field that is used to determine an approval status can be used in a list filter, server action, and a print report.

What to check

• Check that all necessary x_studio_ fields are still present.
• Check types of fields and their relationships.
• Check computed fields and dependencies.
• Check select fields and default value.
• Check domains, filters, and groups.
• Check that relational fields show the right data.
• Check custom modules and their access permissions.
• Check integrations reading/writing from/to custom fields.

Have a list of dependencies for critical custom fields to know how a modification will affect views, automation, reporting, and integrations.

7. Risk Six: Changes to Standard Features Make Old Customizations Unnecessary

Not all of the Studio customizations have to be migrated.

Perhaps the new version of Odoo (version 20) has the same functionality as the old customizations but built-in.

Customizations can be:

Approval workflow logic, Notifications, Additional fields for reports, Workflows.

For each customization, you have to choose one of the options below:

• Keep: the requirement is still valid, and it is necessary to keep the customization.
• Fix: the customization is needed, but some adjustments have to be made.
• Replace: there is already a function in Odoo 20 that performs the same task.
• Delete: the requirement is not actual anymore.
• Reimplement: the requirement stays, but there is another way to implement it.

It will help to decrease the number of things to fix and test after the upgrade.

8. Export and Back Up Studio Customizations

Prior to starting the upgrade process, make sure to back up the database and export the Studio customizations.

According to the Odoo Studio documentation, the customizations done using Studio can be exported to a ZIP file, which includes the studio_customization module. The export serves the purpose of making a backup of the definitions and also for migration purposes in a compatible database environment.

How to export Studio customizations

1. Open your Odoo database.
2. Activate the Studio module via the interface.
3. Click the Export menu item.
4. Export your Studio modifications.
5. Save the exported ZIP file on your computer.
6. Note the version of Odoo from which you are exporting.

Important distinction

The archive generated from the Studio customization process is a means of restoring and transferring the file, and it is not a substitute for performing a proper database backup or a way of automatically resolving compatibility issues.

It should be noted that simply importing the archive into Odoo 20 does not guarantee solving problems with XPath expressions, changed fields, and incompatible actions. The target database needs to have all required applications, and these applications need to be compatible with their underlying models.

Perform the exportation of the customizations prior to the upgrade process, and then do it again after the upgrading and verifying the modifications made during it.

9. Test on an Upgraded Staging Database

Testing in the new staging database is a critical step in the entire migration process.

According to Odoo guidelines, it is recommended that you get a new staging database, validate it, fix the problems, and plan the production upgrade.

It is crucial to use a staging environment that mirrors your production environment in terms of applications installed, customizations made, and business data in place.

Recommended Testing Process

Step 1: Build a Baseline

List out the existing Studio customizations, workflows, roles, reports, and issues.

Step 2: Export and Backup

Export Studio Customizations and make a full backup of your database according to the backup strategy for your hosting environment.

Step 3: Request the Upgrade

Get a test database upgraded to Odoo 20 through the Odoo upgrade process.

Step 4: Review Upgrade Logs & Reports

Locate any inactive views, missing data fields, and other upgrade-related warnings and errors.

Step 5: Test Studio Customizations

Validate views, server actions, automated actions, security settings, custom models, and reports.

Step 6: Test Business Scenarios

Perform a full testing scenario rather than individual screens; for instance, test a quote from quoting to confirmation, delivery, billing, and payment.

Step 7: Rectify and Retest

Resolve the found problems and repeat testing for all problematic scenarios.

Step 8: Authorize Production Readiness

Do so only after business owners or authorized personnel have verified workflow and security rules functionality.

10. When Should You Reset or Restore Studio Views?

A view reset could be used in situations where a customization is no longer necessary or has become incompatible. Nevertheless, a view reset should not be the automatic reaction to any issue during upgrades.

Before resetting a view:

• Find out the problematic inherited view.
• Verify whether it was customized or edited in Studio.
• Analyze its parent view and inheritance definition.
• Decide whether a customization is necessary anymore.
• Backup the existing customization.
• Repair, disable, reset, or delete just the problematic customization.
• Re-test the entire process flow.

If an inherited view is automatically deactivated during an upgrade process, review the upgrade log first. Re-activation of a view without fixing the actual incompatibility will make the problem appear again.

If the customization is still needed, update it according to the Odoo 20 view structure. If the customization is no longer necessary, it is better to delete it.

Resetting all views in Studio in the production environment is never acceptable. Test changes on the staging database and have a way to recover if something goes wrong.

11. Odoo 20 Studio Upgrade Checklist

Use the following checklist before approving the upgrade for production.

Before the upgrade

• Note the source Odoo version and target version.
• Back up the complete database.
• Export the Studio customizations.
• Note the custom fields and models.
• Inventory the automated actions and server actions.
• Identify critical inherited views.
• Note customized reports.
• Document the user groups and security needs.
• Document critical business workflows.
• Identify obsolete customizations to remove.

During the staging validation phase

• Evaluate the upgrade reports and logs.
• Evaluate deactivated and failing views.
• Test XPath expressions and parent view references.
• Test custom fields, domains, and filters.
• Test server action’s python code and field references.
• Test automated actions and scheduled processes.
• Test CRUD permissions and record level permissions.
• Test multi company access if needed.
• Compare customized reports.
• Test business workflows using normal user accounts.
• Test any integrations and exports.
• Resolve issues and re-test the failed test.

Before deploying into production

• Ensure all critical tests are passed.
• Get business user’s approval.
• Export the validated Studio customizations.
• Ensure the final backup and rollback plan.
• Schedule production maintenance window.

Moving to Odoo 20 with Studio customizations involves much more than ensuring that the database upgrade process is successful.

Inherited views may stop working because of structural changes. Actions performed by the server might use renamed fields. Access control configuration should be paid particular attention to, as Odoo 20 brings together model access and record rules to ir.access. Reports and workflows will also have to be verified.

The safest strategy involves exporting Studio customizations, creating the upgraded staging database, checking upgrade reports, fixing affected customizations, and testing business workflows.

It is important to remember that an exported studio_customization module is a good way to recover customizations, yet it is not a substitute for backup or compatibility checks.

The task is not to preserve Studio customizations while upgrading but rather to make sure all needed customizations work correctly and safely in Odoo 20.

To read more about How to Set Up Workflows and Reporting (Hub) in Odoo 20 Accounting, refer to our blog How to Set Up Workflows and Reporting (Hub) in Odoo 20 Accounting.