Why Odoo 18 is the safe migration target in Brazil today

In the previous post I showed that 17 is out of standard support and that 20 is still out of reach for anyone who wants to migrate. The next question comes naturally: so where do I go?

Outside Brazil, the answer is usually the newest version the migration scripts already cover. Here it depends on something else. Companies that issue NF-e (Brazil’s electronic invoice), calculate taxes and file SPED (the federal digital bookkeeping) through Odoo depend on the Brazilian fiscal localization, and that is what decides the target version.

Odoo alone does not issue invoices in Brazil

Standard Odoo doesn’t know what an NF-e, a CFOP or a Brazilian tax regime is. All of that comes from the localization. There are a few on the market. The one I advocate, and which KMEE has been one of the main maintainers of for more than a decade, is the OCA community localization, l10n-brazil: open source, maintained by several companies, kept in the client’s own repository. If you ever want to switch implementation partners, any other one that works with the OCA picks up where the previous one stopped.

This localization is a large set of modules: fiscal, accounting, NF-e and dozens of others. Each one has to be ported to every new Odoo version, one by one, with tests and with its own migration script.

Why the localization comes later

OpenUpgrade, the community project that converts the database between versions, covers the Odoo SA modules. The Brazilian localization modules are outside its scope: they have to be ported to the target version and bring their own migration.

The lag is unavoidable. Odoo releases the version, the standard modules get scripts within a few weeks, and the localization follows, because it depends on them and because Brazilian tax rules are large and change all the time. Just count how many NF-e technical notes came out this year alone, with the tax reform coming into force.

Where the localization stands today

In the OCA repository, the most recent version with the complete fiscal core, with the fiscal, accounting and NF-e modules published, is 18. On 19, fiscal and accounting are published, but NF-e is not yet.

Porting to 20 started in the week of the release. On October 6, every module already on 19 had an open migration pull request for 20, along with the NF-e, CT-e, MDF-e and NFS-e data models, most of them opened by KMEE. None has been merged yet: each one goes through community review first. And the module that issues the NF-e has no pull request yet, on 19 or on 20.

For anyone who issues invoices through the community localization, then, the safe target today is 18. It has standard support from Odoo until September 2027 and Brazilian fiscal running in production.

That is why we work with even versions

At KMEE, we move clients from even version to even version: 16, 18, 20. The choice comes from this lag. An even version ships, matures for about a year while the localization catches up, and only then becomes a target. On 20, we started porting in the week of the release precisely to shorten that wait. Nobody migrates to a version whose fiscal modules are still being ported. And skipping the odd version in between saves a whole migration every cycle.

18 now or 20 later?

If your database needs to leave its current version right away, the target is 18. That is the case for Odoo Online customers, for those at the end of the Odoo.sh window, for anyone running a version that has gone years without fixes, and for Enterprise customers on a version that has entered, or is about to enter, the 25% fee.

If you can wait a few months, it is worth planning straight for 20. Skipping 18 saves a whole migration, and 20 has standard support expected until 2029, two years longer than 18. For companies that issue NF-e through Odoo, there is a single condition: 20 becomes a target when invoice issuing is ported and tested on it. It is not there yet, and I won’t commit to a date.

Either way, the first step is the same: an inventory of the four layers of your database. It serves both 18 and 20, and it is what tells you whether you can wait.

”But doesn’t 19 already have fiscal?”

A good part of it: fiscal and accounting are already ported. For a company that doesn’t issue invoices through Odoo, or handles issuing outside it, 19 may work. For those who do, the math is different, and it starts with what your fiscal operation needs to run inside Odoo.

Next post

So far I have talked about companies with access to the official upgrade service. But a large part of the Brazilian market runs Odoo Community, which doesn’t have that service. How does that company migrate? That is the next post.

Not sure about the right target for your database? KMEE’s migration assessment looks at version, localization and everything else running in your Odoo. It is free.