Migraciones de datos seguras en Odoo

Las migraciones de datos en Odoo son donde los proyectos ERP tienen éxito o fracasan en producción. La mayoría de los fallos no se deben a código defectuoso. Se deben a preparación insuficiente y a suposiciones no verificadas sobre lo que realmente contiene la base de datos.

Qué hace arriesgadas las migraciones en Odoo

El ORM de Odoo gestiona esquema y datos de forma implícita. Cuando se actualiza un módulo, Odoo ejecuta sus propias adiciones de columnas, cambios de tipo y recreaciones de tablas many-to-many de forma automática. El código personalizado se asienta sobre esa maquinaria, y la interacción entre la lógica propia y el proceso de actualización rara vez está documentada.

Las fuentes de fallo más habituales incluyen:

• Campos personalizados cuyos valores deben preservarse o transformarse durante un cambio de tipo.
• Campos calculados que se recalculan con lógica distinta tras la actualización.
• Datos que eran válidos bajo las reglas de negocio antiguas pero violan restricciones en la nueva versión.
• Integraciones externas que dependen de IDs de registro o campos de referencia que cambian durante la migración.

Scripts de migración vs. funciones hook

Odoo ofrece dos puntos de entrada para lógica de migración personalizada: scripts en la carpeta migrations/ de un módulo, y funciones hook registradas en el manifiesto bajo pre_init_hook, post_init_hook, pre_migrate y post_migrate. No son intercambiables.

Los scripts de migración son la herramienta adecuada para transformaciones que deben ejecutarse en un límite de versión concreto. Se ejecutan cuando Odoo detecta que un módulo está siendo actualizado y reciben la versión instalada, ligando la transformación a un estado preciso del esquema.

Las funciones hook se ejecutan durante la instalación o actualización sin la misma precisión de versión. Usar un hook post-instalación para una transformación que solo debería ejecutarse una vez es un error habitual que provoca que se repita en cada reinstalación. Para actualizaciones en producción, los scripts en migrations/ son más precisos y más fáciles de auditar.

Probar con datos de producción

Ninguna migración debería llegar a una ventana de producción sin haberse probado sobre una copia de la base de datos productiva. Los datos de demo no pueden detectar fallos causados por el volumen real, por casos extremos acumulados durante años de uso, o por configuraciones distintas entre clientes.

Una lista de verificación realista antes de la migración incluye:

• Restaurar un volcado reciente de producción en un entorno de staging con la misma versión de Odoo.
• Ejecutar la actualización completa en el mismo orden que en producción.
• Verificar que los registros críticos, informes e integraciones funcionan correctamente tras la actualización.
• Medir cuánto tiempo tarda la migración con volumen real de datos.

Si la migración tarda significativamente más con datos reales que con datos de demo, es información esencial que conviene tener antes de que empiece la ventana de mantenimiento.

Gestionar tablas grandes

Una sentencia UPDATE que reescribe millones de filas mantendrá bloqueos, generará retraso en la replicación y bloqueará operaciones sobre la misma tabla. El enfoque más seguro es el procesamiento por lotes: transformar registros en grupos controlados con un commit entre cada lote. Esto mantiene los bloqueos cortos y permite interrumpir y reanudar el proceso.

Consideraciones adicionales:

• Reconstruir índices tras la transformación en lugar de mantenerlos durante la escritura.
• Registrar el progreso para que el equipo pueda saber si el proceso avanza o se ha detenido.
• Preferir añadir una columna nueva y rellenarla sobre modificar una columna existente cuando la transformación es compleja.

Preservar la integridad de las reglas de negocio

La corrección del esquema es la parte fácil. Tras una actualización, los datos deben ser semánticamente coherentes con la forma en que la empresa opera. Esto implica verificar cosas que los tests automatizados rara vez cubren: si los pedidos de venta abiertos se trasladaron correctamente, si las valoraciones de stock coinciden con el libro mayor, y si los permisos de usuario siguen asignados a los roles correctos.

Define antes de la migración una lista corta de invariantes de negocio. Son consultas concretas que deberían devolver los mismos resultados antes y después de la actualización. Ejecutarlas en staging antes de la aprobación convierte suposiciones implícitas en confirmaciones explícitas.

Comunicar antes de la ventana de migración

Antes de una ventana de migración, los stakeholders y el equipo técnico deben acordar:

• La hora de inicio, la duración esperada y el tiempo máximo de la ventana.
• Qué ocurre si la migración no puede completarse, incluyendo el plan de rollback.
• Qué funciones de negocio no estarán disponibles y durante cuánto tiempo.
• Quién toma la decisión de continuar o abortar si aparecen problemas durante la ejecución.

Las migraciones que ocurren sin este alineamiento ponen al equipo técnico en una posición imposible. Deben tomar decisiones de gran impacto bajo presión, sin la autoridad para tomarlas. Tratar una migración de datos como un evento de negocio coordinado, y no solo como una tarea técnica, es lo que diferencia a los equipos que actualizan con éxito de los que no lo consiguen.