Migración de Odoo v17 a v18
Migrar entre versiones mayores de Odoo es una tarea crítica que requiere planificación, pruebas exhaustivas y una estrategia clara. Odoo 18 introduce cambios significativos en la API, el sistema de vistas, la arquitectura de base de datos y las dependencias. Este artículo te guía paso a paso para realizar una migración exitosa sin perder datos ni causar interrupciones en el negocio.
1. Pre-Migración: Inventario Completo
Antes de tocar cualquier código, realiza un inventario completo de tu instalación. Necesitas documentar todos los módulos instalados (estándar y personalizados), la versión de Python (Odoo 18 requiere Python 3.10 o superior), la versión de PostgreSQL (mínimo 14), las dependencias del sistema como wkhtmltopdf, y todas las integraciones externas incluyendo APIs, webhooks y conectores de terceros.
Genera un reporte del estado actual listando todos los módulos activos, verificando la versión de Odoo con el comando odoo-bin --version, y exportando la lista de módulos personalizados desde la base de datos para tener un punto de referencia antes del cambio.
2. Cambios en la API de Python
Odoo 18 modifica varios métodos del ORM. El método create() ahora acepta listas de diccionarios de forma nativa. Los dominios de búsqueda tienen mejoras de rendimiento significativas. El método search_read es más eficiente y se recomienda para lecturas de múltiples campos. El sistema de logging se mantiene igual pero se recomienda usar logging estructurado para facilitar el filtrado y análisis de eventos.
3. Cambios en las Vistas XML
Los cambios más impactantes en las vistas son la eliminación progresiva del sistema attrs. El atributo invisible ahora usa expresiones Python directamente en lugar de diccionarios eval. Los atributes states y attrs están deprecados. Los campos required y readonly también soportan expresiones Python. Usa herramientas de búsqueda grep para localizar todas las ocurrencias de attrs en tus módulos y reemplazarlas por la nueva sintaxis.
4. Cambios en el Sistema de Herencia
Odoo 18 ajusta el comportamiento de la herencia de modelos con mejoras en cascada y mejor manejo de la herencia por delegación. Si tienes módulos que heredan de modelos de Odoo estándar, verifica que los campos agregados sigan siendo válidos y que los métodos override de compute sigan funcionando correctamente con la implementación base.
5. Estrategia de Migración de Base de Datos
La migración de la base de datos es la parte más delicada. Crea un backup completo de la base de datos con pg_dump en formato custom (-Fc), crea una base de datos de prueba, restaura los datos, y ejecuta la migración con Odoo 18 usando el parámetro --stop-after-init. El proceso ejecuta automáticamente los scripts de migración incluidos en cada módulo oficial.
6. Scripts de Migración Personalizados
Crea scripts de migración en la carpeta migrations/18.0.1.0.0/ con archivos pre-migration.py y post-migration.py. Los scripts pre-migration modifican la estructura de tablas y agregan columnas antes de la migración de Odoo. Los scripts post-migration recalculan campos computados y limpian datos obsoletos después de la migración.
7. Cambios en Dependencias del Sistema
Odoo 18 cambia las versiones mínimas de las dependencias del sistema. Python debe ser 3.10 o superior, wkhtmltopdf debe ser 0.12.6 o posterior, Node.js debe ser 18 o superior para asset compilation, y PostgreSQL debe ser 14 o superior. Actualiza todos los paquetes del sistema antes de instalar Odoo 18.
8. Pruebas de Migración
Nunca migres directamente a producción. Clonar la base de datos de producción a un entorno de pruebas, ejecutar la migración completa, verificar resultados revisando logs de errores, y ejecutar todas las pruebas unitarias de módulos personalizados. Repite el proceso varias veces hasta que la migración sea completamente limpia.
9. Verificación Post-Migración
Después de la migración, verifica la integridad de las tablas, busca registros huérfanos, verifica que las secuencias de auto-incremento estén correctamente ajustadas, y comprueba el tamaño de las tablas para detectar anomalías. Crea un script de verificación automatizada que revise estos puntos críticos.
10. Rollback: Plan de Contingencia
Siempre ten un plan de reversión. Antes de migrar producción, crea un backup completo, detén Odoo v17, renombra la base de datos original como backup, y si hay problemas durante la migración, restaura la base de datos original y reinicia el servicio anterior. Documenta cada paso del plan de contingencia.
11. Calendario de Migración Recomendado
Un cronograma típico incluye inventario y análisis de módulos personalizados (semanas 1-2), actualización de módulos para v18 (semanas 3-4), pruebas en desarrollo (semana 5), pruebas en staging con datos reales (semana 6), capacitación de usuarios (semana 7), migración de producción en fin de semana (semana 8), y monitoreo post-migración (semana 9).
12. Herramientas de Migración
Existen herramientas que facilitan el proceso como openupgrade de OCA para migraciones asistidas, módulos de análisis de compatibilidad, y scripts automatizados que buscan patrones de código deprecados en tus módulos personalizados.
Conclusión
La migración de Odoo v17 a v18 es un proceso que requiere planificación y paciencia. Los cambios en la API y el sistema de vistas son significativos pero bien documentados. La clave del éxito está en las pruebas exhaustivas y en tener un plan de contingencia robusto. No subestimes el tiempo necesario para migrar módulos personalizados ya que generalmente representan el 80 por ciento del esfuerzo total.
13. Estrategia de Testing Post-Migracion
El testing post-migracion debe ser exhaustivo y cubrir todas las funcionalidades criticas del negocio. Crea suites de prueba que incluyan: creacion y edicion de registros en cada modelo personalizado, flujo completo de pedidos desde creacion hasta facturacion, procesos de inventario incluyendo entradas, salidas y ajustes, y operaciones contables como asientos, conciliaciones y cierres.
Los tests automatizados deben ejecutarse despues de cada migracion para detectar regresiones. Odoo ejecuta las pruebas con --test-enable que verifica que los modelos, vistas y reglas de seguridad funcionan correctamente. Los tests que fallan indican problemas de compatibilidad que deben resolverse antes de la migracion de produccion.
Ademas de los tests automatizados, realiza pruebas manuales con usuarios clave de cada departamento. Estos usuarios conocen los flujos de trabajo diarios y pueden detectar problemas sutiles que los tests automatizados no cubren, como cambios en el comportamiento de botones, campos que no se calculan correctamente, o vistas que no se renderizan bien.
Documenta todos los problemas encontrados durante las pruebas con pasos para reproducirlos, comportamiento esperado, comportamiento actual, y prioridad de resolucion. Esta documentacion es esencial para el equipo de desarrollo y para justificar la ventana de mantenimiento adicional si es necesario.
14. Migracion de Datos Personalizados
Los datos personalizados almacenados en campos de modelos estandar de Odoo pueden necesitar migracion si los campos han cambiado de tipo o nombre. Revisa todos los campos personalizados en tus modulos y verifica que los tipos de datos siguen siendo compatibles con Odoo 18.
Los campos One2many y Many2many pueden tener problemas durante la migracion si la estructura de las tablas intermedias ha cambiado. Verifica que las relaciones entre modelos se mantienen intactas despues de la migracion.
Los archivos de configuracion almacenados en ir.config_parameter pueden necesitar actualizaciones si los nombres de los parametros han cambiado o si se han agregado nuevos parametros obligatorios. Revisa la documentacion de cada modulo para identificar cambios en la configuracion.
Para datos criticos como contratos, facturas y pedidos abiertos, realiza una verificacion manual despues de la migracion para asegurarte de que los datos se migraron correctamente y que los campos calculados muestran los valores esperados.
15. Plan de Comunicacion Post-Migracion
Despues de la migracion, comunicar los cambios a los usuarios es tan importante como la migracion en si. Prepara guias de usuario que documenten los cambios visibles: nuevas funcionalidades, campos modificados, y flujos de trabajo actualizados.
Ofrece sesiones de capacitacion breves (30 minutos) para usuarios clave que puedan a su vez capacitar a sus equipos. Estas sesiones deben enfocarse en los cambios mas impactantes en el dia a dia de los usuarios, no en tecnicismos de la migracion.
Establece un canal de soporte dedicado (Slack, Teams o email) para recibir preguntas y reportar problemas durante las primeras dos semanas post-migracion. Asigna al menos un miembro del equipo de desarrollo para responder consultas en tiempo real.
Crea un FAQ con las preguntas mas frecuentes de los usuarios y sus respuestas. Publica este FAQ en un lugar accesible para todos los usuarios y actualizalo conforme se reciben nuevas preguntas.
16. Estrategia de Rollback Segmentado
En lugar de un rollback completo del sistema, implementa un rollback segmentado que permita revertir componentes individuales. Si la migracion de un modulo especifico falla, puedes revertir solo ese modulo sin afectar los demas que se migraron correctamente.
Para implementar rollback segmentado, mantene backups de cada modulo por separado y scripts de migracion inversa que puedan deshacer los cambios especificos de cada modulo. Esto es mas complejo pero ofrece mayor flexibilidad en caso de problemas.
Los scripts de rollback inversa deben ser tan robustos como los de migracion. Verifica que pueden ejecutarse multiples veces sin causar errores, que manejan correctamente los casos donde los datos ya estan en el formato original, y que preservan los datos creados durante la migracion.
Para datos criticos, implementa un sistema de auditeria que registre todos los cambios realizados durante la migracion. Este registro te permite revertir cambios especificos sin afectar otros datos que se migraron correctamente.
17. Migracion de Datos de Reportes
Los reportes personalizados de Odoo (ir.actions.report) pueden contener configuraciones especificas que necesitan ajustes durante la migracion. Revisa todos los reportes personalizados y verifica que las plantillas QWeb son compatibles con la version de Odoo objetivo.
Las plantillas de reportes que usan campos computed o related pueden fallar si los campos han cambiado de nombre o comportamiento. Actualiza las plantillas para usar los nuevos nombres de campos y verifica que los reportes se generan correctamente.
Los reportes que usan archivos de configuracion externos (como plantillas de Word o Excel) deben verificarse para asegurarse de que las rutas de archivos siguen siendo validas. Los cambios en la estructura de directorios durante la migracion pueden romper las referencias a archivos externos.
Prueba todos los reportes personalizados despues de la migracion generando al menos una instancia de cada reporte. Verifica que el formato, los datos y la presentacion son correctos antes de poner el sistema en produccion.
18. Verificacion de Compatibilidad de Modulos
Antes de migrar, verifica la compatibilidad de cada modulo personalizado con Odoo 18. Revisa los campos definidos en los modelos para detectar campos que usan tipos de datos deprecados o parametros que ya no son validos. Los campos Selection con valores vacios o campos Char con largo maximo definido pueden causar problemas en versiones nuevas.
Verifica los metodos heredados de modelos de Odoo para detectar cambios en la firma o comportamiento. Si tu modulo sobrescribe un metodo que ha cambiado en Odoo 18, necesitas actualizar la implementacion para que sea compatible con la nueva version.
Revisa las vistas XML para detectar atributos deprecados como states, attrs, y modifiers. Estos atributos siguen funcionando pero mostraran advertencias en los logs y eventualmente seran eliminados. Migra todas las ocurrencias a la nueva sintaxis de Odoo 18.
Verifica los archivos de seguridad (ir.model.access.csv) para asegurarte de que los IDs de los modelos y grupos son correctos. Los IDs de los grupos de Odoo pueden cambiar entre versiones, lo que causaria errores de acceso al instalar el modulo.
19. Plan de Pruebas de Regresion
Crea un plan de pruebas de regresion que cubra todos los flujos de negocio criticos de tu empresa. El plan debe incluir pasos detallados para cada prueba, resultados esperados, y criterios de aceptacion. Asigna responsables para cada area de prueba y establece plazos para la ejecucion.
Los flujos criticos que deben probarse incluyen: creacion y confirmacion de pedidos de venta, facturacion y cobro, entradas y salidas de inventario, gestion de compras y proveedores, reportes contables y fiscales, y cualquier proceso personalizado especifico de tu empresa.
Para cada flujo, prueba tanto el camino feliz (todo funciona correctamente) como los caminos de error (datos invalidos, permisos insuficientes, condiciones de borde). Los errores en los caminos de error son los que mas afectan a los usuarios en la practica.
Despues de ejecutar el plan de pruebas, genera un reporte de resultados que incluya las pruebas que pasaron, las que fallaron, y las que no pudieron ejecutarse. Prioriza la resolucion de las fallas criticas antes de la migracion de produccion.
20. Estrategia de Versionado de Migraciones
Implementa un sistema de versionado para las migraciones que permita rastrear que version de cada modulo esta instalada en cada entorno. Odoo almacena la version de cada modulo en la tabla ir_module_module, pero para un control mas granular, crea tu propio sistema de versionado.
El versionado de migraciones debe incluir: la version origen, la version destino, la fecha de ejecucion, el responsable, el resultado (exito/fallo), y las notas de la migracion. Esta informacion es invaluable para diagnosticar problemas y planificar futuras migraciones.
Para migraciones complejas que involucran multiples pasos, implementa un sistema de checkpoint que registre el estado de la migracion en cada paso. Si la migracion falla en un paso intermedio, puedes reanudar desde el ultimo checkpoint exitoso en lugar de empezar desde cero.
Los scripts de migracion deben ser idempotentes para poder ejecutarse multiples veces sin causar problemas. Usa transacciones de base de datos para garantizar que cada paso de la migracion se ejecuta completamente o no se ejecuta en absoluto.
21. Estrategia de Testing de Rendimiento
El testing de rendimiento es una parte critica de la verificacion post-migracion. Las migraciones pueden introducir regresiones de rendimiento que no se detectan en pruebas funcionales pero afectan la experiencia del usuario en produccion. Implementa benchmarks que midan el tiempo de respuesta de las vistas mas usadas.
Para medir el rendimiento, crea scripts que ejecuten las operaciones criticas del negocio y midan el tiempo que tardan. Compara los tiempos pre-migracion y post-migracion para detectar regresiones. Un aumento del 20% o mas en el tiempo de respuesta de una vista critica requiere investigacion y optimizacion.
Los puntos de medicion deben incluir: tiempo de carga de la vista de lista principal, tiempo de creacion de un pedido completo con multiples lineas, tiempo de generacion de facturas, y tiempo de ejecucion de reportes personalizados. Estas metricas representan las operaciones mas frecuentes de los usuarios.
Si el testing de rendimiento revela problemas, optimiza las consultas de base de datos, ajusta los indices, y verifica que los campos compute no ejecutan consultas innecesarias. Los problemas de rendimiento post-migracion suelen estar causados por consultas que antes usaban indices que ya no existen.
22. Verificacion de Integridad de Datos Post-Migracion
La verificacion de integridad de datos es un paso critico que a menudo se omite por prisa. Despues de cada migracion, ejecuta verificaciones que confirmen que los registros se migraron correctamente, que las relaciones entre tablas se mantienen intactas, y que los campos compute muestran los valores esperados. Usa consultas SQL directas para contar registros, verificar foreign keys, y comparar sumas de campos monetarios entre la base de datos original y la migrada.
Para campos compute que dependen de datos de multiples tablas, verifica que los valores calculados son consistentes con los datos subyacentes. Si detectas discrepancias, ejecuta un script de recalculo que actualice los campos compute usando los metodos del ORM de Odoo. Esto garantiza que la interfaz de usuario muestra informacion correcta despues de la migracion.
