Migración de Odoo: módulos a medida, de la OCA y de terceros

Cuando alguien me pregunta cuánto tiempo lleva migrar un Odoo, lo primero que pregunto de vuelta es qué tiene instalado además del estándar. La versión casi no importa en esa cuenta.

En una implementación real, Odoo rara vez es solo Odoo. Debajo hay cuatro capas, y cada una migra de una manera.

Las cuatro capas

El núcleo de Odoo. Las aplicaciones estándar: ventas, inventario, contabilidad, compras. Es la capa mejor atendida. En Enterprise, la actualización oficial se ocupa de ella junto con lo que se hizo en Studio. En Community, OpenUpgrade cubre la mayor parte, como conté en el post anterior.

Los módulos de la OCA. Los módulos de la comunidad, incluida la localización fiscal brasileña. Cada uno lo mantiene quien lo desarrolla y tiene que portarse y migrarse por su cuenta. La actualización oficial de Odoo no cubre esta capa.

Los módulos de terceros. Los que la empresa compró en la tienda de apps de Odoo o a otro proveedor. Aquí aparece la sorpresa: puede que el proveedor todavía no haya lanzado el módulo en la versión nueva, o que lo cobre de nuevo.

Los desarrollos a medida. Lo que se desarrolló solo para su empresa. Es la capa más impredecible, porque todo depende de cómo se escribió el código.

Lo que dice la propia Odoo

La documentación de actualización es directa. El servicio migra las aplicaciones estándar y deja fuera los módulos creados internamente o por terceros, incluso por partners de Odoo, salvo que tengan contrato de mantenimiento. Y trae un aviso que resume el problema: una base con un módulo a medida no puede migrarse hasta que exista una versión de ese módulo para la versión de destino.

Traducido: la actualización oficial convierte la base, y el código sigue siendo asunto suyo. Sin una versión nueva del módulo a medida, la migración se detiene ahí.

Studio parece seguro, y da trabajo

La personalización hecha en Studio entra en la actualización oficial, siempre que la suscripción esté activa. En la práctica, suele dar más trabajo de lo que parece. Campos, vistas e informes armados en Studio se apoyan en la estructura de la versión en la que nacieron, y cuando esa estructura cambia, parte del ajuste hay que rehacerlo. Hay un relato de un usuario que perdió buena parte de sus cambios de Studio al pasar a la 17.

Es también uno de los motivos por los que una base con mucho Studio tiene una migración más cara.

Lo que separa el código que migra del que se traba

En los desarrollos a medida, la línea de corte es la calidad del código. Un módulo bien escrito, que hereda el comportamiento estándar en lugar de alterar el código nativo, tiene pruebas y no hace SQL directo contra la base, migra con un esfuerzo previsible. Un módulo que modifica archivos nativos, hace SQL directo o no tiene pruebas se vuelve un riesgo en cada versión nueva.

Antes de migrar, revisamos la salud de los módulos. A veces conviene sanear el código primero y migrar después, y ese saneamiento además abarata la próxima migración.

Próximo post

Sabiendo qué migra, falta garantizar que nada se perdió en el camino: adjuntos, informes, facturas. El próximo post trata de cómo probar una migración antes del corte.

Mapear las cuatro capas de su base es justamente el trabajo del diagnóstico de migración de KMEE, que no tiene costo.