# OpenUpgrade API: UI for openupgrade analysis files

> OpenUpgrade's analysis files list every model, field and module that changed between Odoo versions. An API and a web explorer that make them searchable, plus YAML for odoo-module-migrator.

**Date:** 2025-09-10
**Source:** <https://trobz.com/insights/openupgrade-api-ui-for-openupgrade-analysis-files/>

---


{{< img src="/images/insights/openupgrade-api-ui-for-openupgrade-analysis-files/OpenUpgrade_Explorer.png" alt="OpenUpgrade Explorer" >}}

##  Introduction to [OpenUpgrade](https://github.com/oca/openupgrade): The Foundation of Odoo Upgrade

[OpenUpgrade](https://github.com/oca/openupgrade) is an important open-source project by the Odoo Community Association (OCA). Its main purpose is to provide scripts to perform database upgrades across major Odoo versions (e.g., from 17.0 to 18.0)

During this process, [OpenUpgrade](https://github.com/oca/openupgrade) generates two valuable log files:
- **upgrade_analysis.txt**([example](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/scripts/account/18.0.1.3/upgrade_analysis.txt)): This file contains a detailed list of backward-incompatible changes between the two versions, including models , fields , and XML records that have been added, removed, or renamed.
\- **apriori.py** ([example](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/apriori.py)): This file contains a detailed list of module-level changes, covering the following cases:

  * **Renamed Modules** : When a module’s technical name changes between versions (e.g., note was renamed to project_todo)

  * **Merged Modules** : When a module is merged into another module

  * **Not needed anymore** : Some modules have been absorbed into Odoo native features during its evolution

  * **Moved Modules** : Some modules have been relocated to different repositories. For example, the module ed_oca was moved from _OCA/edi_ to _OCA/edi-framework_ between _15.0_ and _16.0.
_

We believe the above information can be useful when working with Odoo. Therefore, We decided to parse these files into many structured databases in order to allow the data to be easily queried through an API and browsed with a user interface.

## An Interface to Browse Analysis Files More Easily

[OpenUpgrade API](https://github.com/trobz/openupgrade-api) standardizes the entire data processing flow (**ETL** : **E** xtract–**T** ransform–**L** oad) for upgrade changes and exposes them through a convenient **REST API**. Here’s how it work

  1. **Extract** : Automatically pulls all upgrade scripts directly from [OpenUpgrade](https://github.com/oca/openupgrade) branches (e.g., _16.0_ , _17.0_ , _18.0_).

  2. **Transform** : Parses and "translates" the raw text from upgrade_analysis.txt files ([example](https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/scripts/account/18.0.1.3/upgrade_analysis.txt)) into a clean, unified data structure (ChangeRecord).

  3. **Load** : Stores the normalized data into an SQLite database, clearly separated by major version (e.g., 16.0, 17.0, 18.0). Each DB file acts as an independent snapshot.

  4. **API** : Provides endpoints so you can easily query change data by **module** , **model** , and **version**

The main goals of [OpenUpgrade Api](https://github.com/trobz/openupgrade-api) are:

  * To centralize and normalize all findings from [OpenUpgrade](https://github.com/oca/openupgrade) into a single, easy-to-query source.

  * To offer a REST API for developers and consultants to quickly look up changes when planning migrations.

  * To automatically generate YAML files compatible with [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator) to automate **rename** and **remove** operations.

  * To serve as a backend for community tools, such as the search portal [openupgrade.trobz.com](http://openupgrade.trobz.com)

## Leveling Up Automation With [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator)

This is the most powerful feature! [OpenUpgrade API](https://github.com/trobz/openupgrade-api) can automatically generate YAML files that [Odoo Module Migrator](https://github.com/OCA/odoo-module-migrator) can understand. You can create these files using the **get** command

  * Get a list of removed models in version 18.0: python manage.py get --object-type removed --object models --versions 18.0 --output-directory output

  * Get a list of removed fields in version 18.0: python manage.py get --object-type removed --object fields --versions 18.0 --output-directory output

  * Similarly for renamed models and fields: python manage.py get --object-type renamed --object models --versions 18.0 --output-directory output and python manage.py get --object-type renamed --object fields --versions 18.0 --output-directory output

The YAML files will be generated in the output directory with a clear structure. All you have to do is:

  1. Generate the **YAML files** for the version you are migrating to (e.g., 17.0 → 18.0).

  2. **Copy** these files into your migration repository.

  3. **Run odoo-module-migrator**, and it will automatically apply the changes based on the data you provided

## The Web UI: [openupgrade.trobz.com.](http://openupgrade.trobz.com/)

To complement the [OpenUpgrade API](https://github.com/trobz/openupgrade-api), we created the [OpenUpgrade Explorer](http://openupgrade.trobz.com), a clean and user-friendly web interface that makes structured migration data easy to access. It helps developers and consultants quickly navigate backward-incompatible and module-level changes without the hassle of working directly with APIs or raw logs.

With it, you can:

  * Quickly inspect changes by **module** /**model** /**field** across Odoo versions.

  * Validate critical **rename** /**remove** /**merged** /**obsolete** /**move** operations before planning your migration.

  * Share lookup links with your team or customers

Check it out at: [openupgrade.trobz.com
](https://openupgrade.trobz.com/)

  1.   2.   3.