Migração de Odoo: módulos customizados, da OCA e de terceiros

Quando alguém me pergunta quanto tempo leva para migrar um Odoo, a primeira coisa que eu pergunto de volta é o que tem instalado além do padrão. A versão quase não importa nessa conta.

Numa implantação real, o Odoo raramente é só o Odoo. Por baixo dele tem quatro camadas, e cada uma migra de um jeito.

As quatro camadas

O core da Odoo. São os aplicativos padrão: vendas, estoque, contabilidade, compras. É a camada mais bem servida. No Enterprise, o upgrade oficial cuida dela junto com o que foi feito no Studio. Na Community, o OpenUpgrade cobre a maior parte, como contei no post anterior.

Os módulos da OCA. Os módulos da comunidade, inclusive a localização fiscal brasileira. Cada um é mantido por quem o desenvolve e precisa ser portado e migrado por conta própria. O upgrade oficial da Odoo não cobre essa camada.

Os módulos de terceiros. Os que a empresa comprou na loja de apps da Odoo ou de outro fornecedor. É onde aparece a surpresa: o fornecedor pode ainda não ter lançado o módulo na versão nova, ou cobrar de novo por ela.

Os customizados. O que foi desenvolvido só para a sua empresa. É a camada mais imprevisível, porque tudo depende de como o código foi escrito.

O que a própria Odoo diz

A documentação de upgrade é direta. O serviço migra os aplicativos padrão e deixa de fora os módulos criados internamente ou por terceiros, inclusive por parceiros da Odoo, a menos que tenham contrato de manutenção. E traz um aviso que resume o problema: uma base com módulo customizado não pode ser migrada até que exista uma versão desse módulo para a versão de destino.

Traduzindo: o upgrade oficial converte o banco, e o código continua por sua conta. Sem versão nova do customizado, a migração para ali.

O Studio parece seguro, e dá trabalho

Customização feita no Studio entra no upgrade oficial, desde que a assinatura esteja ativa. Na prática, ela costuma dar mais trabalho do que parece. Campos, telas e relatórios montados no Studio se apoiam na estrutura da versão em que nasceram, e quando essa estrutura muda, parte do ajuste precisa ser refeita. Há relato de usuário que perdeu boa parte das alterações do Studio ao subir para a 17.

E é um dos motivos de base com muita coisa no Studio ter migração mais cara.

O que separa o código que migra do que trava

No customizado, a linha de corte é a qualidade do código. Um módulo escrito do jeito certo, que herda o comportamento padrão em vez de alterar o código nativo, tem teste e não faz SQL direto no banco, migra com esforço previsível. Um módulo que mexe em arquivo nativo, faz SQL direto ou não tem teste vira risco a cada versão nova.

Antes de migrar, a gente olha a saúde dos módulos. Às vezes compensa sanear o código primeiro e migrar depois, e esse saneamento ainda deixa a próxima migração mais barata.

Próximo post

Sabendo o que migra, falta garantir que nada se perdeu no caminho: anexos, relatórios, notas fiscais. O próximo post é sobre como testar uma migração antes da virada.

Mapear as quatro camadas da sua base é o trabalho do diagnóstico de migração da KMEE, que não tem custo.