Migración del código por saltos de versión
El código se llevó primero de la versión 15 a la 16 y después de la 16 a la 17.
Saltar directamente entre versiones no distantes no es viable en Odoo: cada salto arrastra sus propios cambios de estructura, y encadenarlos es lo que permite aislar en qué versión aparece cada conflicto.
Migración de la base de datos con OpenUpgrade
La migración de datos se ejecutó con OpenUpgrade, que cubre tanto los módulos del núcleo como los desarrollos a medida.
Es la vía que evita escribir migraciones propias para cambios que el proyecto ya tiene resueltos y verificados por la comunidad.
Depuración de conflictos
Corrección de los conflictos generados por los cambios entre versiones: campos y tablas obsoletos en la base de datos, y cambios de estructura en las vistas XML.
Fue la fase más larga del proyecto y la que concentró el esfuerzo real.
Validación de los módulos a medida
Cada desarrollo propio se verificó funcionando en la versión 16 y después en la 17, no solo compilando. Una migración que arranca pero rompe un proceso de negocio no está terminada.
Infraestructura en alta disponibilidad
Rediseño del clúster con nodos de control y de trabajo separados, y dos balanceadores con dirección virtual compartida en lugar de uno solo.
Con ello desaparece el punto único de fallo del diseño anterior y el conjunto admite crecer añadiendo nodos.
Pruebas de carga y traspaso
Pruebas de estrés y rendimiento sobre el conjunto ya montado, y entrega de la documentación y los ficheros de configuración de la infraestructura al equipo del cliente.