Odoo publica una versión mayor al año. Las funcionalidades estándar se migran solas; lo que se rompe es lo que se añadió por encima. La documentación oficial no deja lugar a dudas: si un cambio de la nueva versión rompe una personalización, corresponde al responsable de ese módulo hacerlo compatible.
Lo que sí cubre Odoo
Las personalizaciones creadas con Studio entran en el proceso de actualización, siempre que Studio siga instalado y la suscripción correspondiente siga activa. Es una de las razones de peso para hacer con Studio todo lo que Studio pueda hacer.
La letra pequeña de Studio
Hay un detalle que conviene conocer antes de confiarse: el módulo que guarda las personalizaciones de Studio queda fuera de las cascadas de actualización de módulos. Los registros persisten, pero no se vuelven a aplicar automáticamente. En la práctica significa que después de un salto de versión mayor hay que revisar y revalidar a mano las vistas y los flujos creados con Studio. Es un trabajo corto, pero alguien tiene que hacerlo, y si nadie lo hace aparecen vistas que dejan de mostrar campos sin que nadie sepa por qué.
Lo que rompe el código a medida
Cada versión retira o renombra parte de la API. En Odoo 19, por ejemplo, hay cambios que fallan en silencio, que son los peores:
- Las restricciones SQL declaradas al modo antiguo (
_sql_constraints) se ignoran con un simple aviso en el log. La restricción nunca llega a la base de datos, así que los datos duplicados que impedía empiezan a entrar sin que nadie se entere. - Un fichero Python dentro de un módulo importado se omite con una línea informativa en el log, sin error.
Y otros que fallan de forma visible: las vistas de lista cambiaron de etiqueta, la ruta de los controladores JSON
cambió de nombre, read_group() quedó obsoleto y auto_join pasó a llamarse de otra manera.
Ninguno es dramático por separado; todos juntos, en un módulo que nadie mantiene desde hace tres versiones, sí.
Cómo se evita
- Herencia, siempre. Añadir sobre los modelos y vistas existentes en lugar de reemplazarlos mantiene tu lógica separada de las actualizaciones de Odoo.
- No sobrescribir los identificadores XML del núcleo.
- Instalar los módulos propios en una base vacía con la versión de destino y resolver todos los errores y avisos antes de tocar producción.
- Ensayar la migración completa sobre una copia y probarla con usuarios reales. La documentación de Odoo lo plantea como un paso obligatorio, no opcional.
- Presupuestar el upgrade como parte del coste de tener código a medida, no como un imprevisto. Lo desarrollamos en Personalizar de más: la factura llega en el próximo upgrade.