Cómo probar una migración de Odoo antes del corte

En un hilo del foro oficial de Odoo, una empresa que migró de la 17 a la 19 en producción recibió una respuesta que resume este post: no es posible volver a la versión anterior. Después del corte, una migración de versión no tiene vuelta atrás.

La prueba, entonces, va primero: la propia Odoo recomienda correr la actualización en una copia antes de producción. Abajo, la hoja de ruta que yo seguiría.

Empiece por una copia, nunca por producción

La primera prueba corre en una copia completa de la base, y completa quiere decir base de datos y archivos. Insisto en los archivos porque Odoo guarda adjuntos, PDF de facturas e imágenes en el filestore, fuera de la base de datos, y es común migrar uno y olvidar el otro. En un relato en el foro de Odoo, una empresa tenía 1,5 GB de archivos en la versión 14 y recuperó 44 MB después de la migración.

Qué revisar en la copia migrada

Ver que el sistema abre no prueba nada. Revise punto por punto:

• Archivos y adjuntos. ¿El tamaño del filestore coincide con el original? ¿Abren los PDF de pedidos y facturas antiguas?
• Informes y plantillas de documentos. ¿El pedido, la factura y su versión impresa salen con los campos que su empresa personalizó?
• Personalizaciones de Studio. ¿Los campos y vistas creados en Studio siguen ahí y funcionando?
• Fiscal. Emita facturas en el ambiente de pruebas del fisco, revise los impuestos de pedidos reales y vea si las declaraciones cierran. En Brasil, con NF-e y SPED, es la parte que no puede fallar.
• Integraciones. Todo lo que conversa con Odoo, de bancos a e-commerce, tiene que probarse contra la versión nueva.
• Volumen. Cuente clientes, productos, facturas y asientos antes y después. Los números tienen que coincidir.

Haga más de un ensayo

El primer ensayo muestra lo que se rompe, y usted lo corrige. El segundo, en una copia nueva de producción, confirma que las correcciones funcionan y mide cuánto tarda la migración de verdad. Ese tiempo medido define la ventana de parada el día del corte.

El corte es un evento planificado

Ese día, la operación se detiene por algunas horas. Defina antes: la ventana, de preferencia fuera del pico; el momento a partir del cual nadie registra nada más en la versión antigua; el respaldo, hecho inmediatamente antes; y el criterio de aceptación, es decir, lo que tiene que estar funcionando para dar la migración por concluida. En KMEE, esa aceptación es explícita y documentada con el cliente en la homologación.

Falta un punto, el que más se olvida: quién decide volver al respaldo si algo crítico falla. Como la migración no se deshace, volver significa restaurar el respaldo de la versión antigua. Esa decisión tiene que estar acordada antes, y no en medio de la madrugada del corte.

Próximo post

Probar bien tiene costo, y es aquí donde mucha gente se asusta con el presupuesto. El último post de la serie trata de cuánto cuesta migrar un Odoo de verdad.

El diagnóstico de migración de KMEE, sin costo, le entrega un plan con estas etapas ya diseñadas para su base.