Migrating an Odoo database from one version to another is never just a matter of copying data and updating modules. One of the biggest challenges developers face during migration is handling changes in field data types across Odoo versions. As Odoo grows with new features, better multi-company support, and improved performance, the internal structure of models and fields often changes. These changes may seem small at first, but they can have a huge impact on how your existing data behaves after the upgrade.
A good example of this is what happened during the migration from Odoo 15 to Odoo 17. In Odoo 15, the account.account model used a simple char field called code to store the account code. It was fine for basic use cases. But as businesses required more advanced multi-company setups, Odoo redesigned this system in version 17. Instead of storing a single code, Odoo now uses a JSONB field called code_store, which can store different account codes for different companies in a single place.
This change improves flexibility and avoids duplication, but it also introduces problems during migration. The old char value "1000" cannot simply be placed into the new JSONB field. If you try to assign it directly, Odoo will see the wrong data type and throw errors such as:
TypeError: the JSON object must be str, bytes, or bytearray, not dict
This happens because the new field expects a proper JSON structure, not plain text. If this conversion is not done carefully, it can lead to corrupted data, broken accounting records, or even a complete migration failure.
Another similar example is the change in the mail tracking system (mail.tracking.value). In recent versions, several fields that used to be stored as plain text or char fields have been converted to JSON fields. This affects how changes are logged in the chatter, how diffs are displayed, and how the data is stored internally. If old data isn’t converted correctly, the chatter may stop showing updates, or Odoo may crash when trying to read old log values.
These are not always obvious changes. They are often silent and hidden deep inside the ORM. That is why developers performing migrations must not only understand what changed, but also why it changed, and what the new format expects. Good migration work is not just about writing scripts—it’s about understanding the logic behind the redesign and ensuring all old data fits the new structure.
Let’s look at a real-world scenario. Suppose you are migrating from Odoo 15 to Odoo 17, and you need to convert the legacy code field into the new code_store field. You must take the old string value and wrap it inside a valid JSON structure, keyed by the correct company ID. This can be done either in Python using an upgrade script or using raw SQL during your post-migration stage.
For example, using SQL, you could convert:
code = '1000' and its company_id =1
This will become code_store = '{"1": "1000"}'
By creating a new field and storing the data from the old field with the company details in JSONB format.
In summary, a smooth Odoo migration depends on paying close attention to how data types have changed between versions. When you understand exactly what fields were updated and why they were changed, you can prepare the data correctly before moving it into the new system. This prevents problems like broken records, missing information, or unexpected errors after the upgrade.
By handling these changes carefully, you ensure that the entire system continues to work as expected—from accounting to messaging—without any disruptions. In the end, understanding and adjusting to these data type changes is what makes the migration safe, stable, and successful.
To read more about Overview of Database Migration in Odoo, refer to our blog Overview of Database Migration in Odoo.