Cómo migrar Odoo sin parar la empresa: proceso, plazos y errores

La migración de Odoo sin parar la empresa se basa en dos ideas: todo se ensaya sobre copias clonadas de tu base de datos real, nunca sobre producción, y la versión se sube un escalón cada vez (de 16 a 17, de 17 a 18 y de 18 a 19) hasta llegar a la versión objetivo. Cada ensayo se repite hasta que la contabilidad cuadra al céntimo y no queda ninguna pantalla retocada a mano sin revisar, y solo entonces se pasa a producción en una fecha acordada, con un plan de vuelta atrás decidido de antemano. Este artículo forma parte de la guía Odoo para empresas.

Lo que cuesta una migración mal planificada

Una migración improvisada no suele fallar el primer día: falla cuando alguien descubre que los saldos no cuadran con el último cierre, que una declaración de IVA no se puede reproducir o que faltan conciliaciones bancarias. Entonces toca corregir datos a mano con la empresa ya trabajando en la nueva versión, que es lo más caro y lo más arriesgado.

Y hay riesgos menos visibles: una copia de pruebas que envía facturas a clientes reales o presenta el SII, pedidos de la tienda online que entran durante el cambio y se pierden, o un equipo que no puede facturar mientras se busca el problema.

El método: copias clonadas y una versión cada vez

Subida progresiva sobre una copia de pruebas

Tu empresa sigue trabajando mientras se ensaya. Todo el trabajo se hace sobre una copia clonada de tu base de datos de producción, en un entorno de pruebas aislado que no envía correos, ni facturas, ni declaraciones. Producción no se toca hasta el día del corte.

Se sube un escalón cada vez. Odoo no se migra de golpe de una versión a otra lejana: las herramientas de migración avanzan una versión por salto. De Odoo 16 a Odoo 19 hay tres saltos (16 → 17 → 18 → 19), y en cada uno todos los módulos instalados tienen que existir en la versión siguiente. Tras cada salto se valida que los datos cuadran y se guarda una copia de ese escalón, para que, si el siguiente falla, se retome desde ahí y no desde el principio.

Las versiones intermedias nunca llegan a producción. Odoo 17 y 18 solo existen en el entorno de pruebas como escalones. Tu equipo pasa directamente de la versión actual a la final.

El ensayo completo se repite. Cuando algo no cuadra, se corrige el origen del problema y se vuelve a empezar desde una copia nueva y reciente de producción. Hacen falta al menos dos ensayos completos limpios, con el mismo procedimiento que se usará el día del cambio, antes de fijar la fecha del corte. Cada iteración hace el corte más predecible: se sabe qué falla, cómo se resuelve y cuánto dura cada salto.

Hoy, el objetivo es Odoo 19. A octubre de 2026, Odoo 20 acaba de salir y conviene planificar ese salto cuando las herramientas de migración y los módulos de la comunidad que uses estén disponibles para esa versión.

Si sigues en Odoo 16 o 17, el motivo para no esperar está en qué implica que Odoo 16 y 17 ya no tengan soporte estándar. Y si tienes que llegar a tiempo a la factura electrónica, las adaptaciones fiscales solo llegan a las versiones con soporte: lo detallo en el calendario de VeriFactu en Odoo y qué preparar.

Las fases de una migración

1. Preparación y saneamiento, semanas antes

Lo que esté mal en la versión actual se corrige en la versión actual, nunca durante la migración.

• Inventario de módulos. Cada módulo instalado, estándar, de terceros o propio, se revisa contra su disponibilidad en cada versión del camino. Para cada uno se decide: migrarlo, sustituirlo por funcionalidad estándar o desinstalarlo.
• Contabilidad en orden. Publicar o eliminar los borradores antiguos, conciliar lo que se pueda conciliar y bloquear los periodos ya declarados.
• Pantallas retocadas a mano. Las vistas modificadas directamente en la base de datos se localizan antes de empezar (lo explico más abajo).
• Revisión de integridad. Asientos descuadrados, apuntes huérfanos o conciliaciones incompletas se buscan y se corrigen hasta que no quede ninguno.

2. La contabilidad tiene que cuadrar al céntimo

Es la comprobación que decide si una migración está bien hecha. Antes de empezar se toma una foto de los datos que no pueden cambiar:

• Sumas y saldos por cuenta y año.
• Importes por casilla de impuestos, los que van a las declaraciones.
• Número de facturas y asientos por tipo y estado, y conciliaciones.
• Saldos pendientes de cada cliente y proveedor.

Esa misma foto se repite después de cada salto de versión y en la base de datos final, y se compara con la original. La migración solo es correcta cuando las dos coinciden exactamente. Cualquier diferencia en un asiento ya contabilizado bloquea el corte: se busca el origen, se corrige y se repite el ensayo desde una copia nueva. No basta con que «parezca que todo funciona».

3. Las vistas retocadas a mano en la base de datos

Es uno de los riesgos más olvidados. En muchas instalaciones alguien cambió en su día una pantalla, un formulario o un informe directamente en la base de datos, desde el modo desarrollador, sin pasar por un módulo. Funciona, pero ningún módulo sabe que existe ese cambio.

Al cambiar de versión, esas vistas retocadas a mano no se migran como el resto: se pierden o rompen la pantalla, y el equipo descubre el primer día que le falta un campo o que un informe ya no sale. Por eso se localizan todas antes de empezar y, para cada una, se decide si se convierte en un módulo propio, que sí se migra y queda documentado, o si se elimina porque la nueva versión ya lo resuelve.

4. Ensayos sobre copias clonadas, salto a salto

Es el corazón del método descrito arriba:

• Copias recientes de producción, clonadas para cada iteración, nunca la base de datos real.
• Copias de prueba neutralizadas, sin tareas programadas, sin correo saliente y sin conexión con pasarelas de pago ni con el SII, para que ningún ensayo envíe una factura o presente una declaración.
• Un salto de versión cada vez, con validación y copia guardada en cada escalón.
• Cada salto se cronometra, así se sabe de antemano cuánto durará la parada real.
• Al menos dos ensayos completos limpios. Un ensayo solo se da por bueno cuando termina sin errores, la contabilidad cuadra al céntimo y las pantallas retocadas se ven como deben; si no, se corrige y se repite desde una copia nueva.

Si quieres que lo hagamos juntos, así trabajo la migración de versiones de Odoo.

5. Validación con tu equipo

Además de comparar la foto contable, cada área prueba lo suyo en la versión migrada:

• Se reproduce el último modelo 303 presentado y las sumas y saldos del último cierre.
• Se reimprime una muestra de facturas.
• Facturación, cobros y pagos, conciliación bancaria, impuestos e informes dan su conformidad por escrito.

6. Congelación y corte

• Fecha de corte comunicada a todo el equipo, con los periodos bloqueados hasta ese día.
• Entradas cortadas: se paran las tareas automáticas y las integraciones que meten datos, como la tienda online, el EDI o el SII, y los usuarios dejan de trabajar en el sistema durante la ventana.
• Copia completa y probada: se hace una copia de la base de datos y de los archivos adjuntos, y se restaura en otro servidor antes de seguir. Una copia que no se ha probado no es una copia.

7. Plan de vuelta atrás

El criterio para volver a la versión anterior se decide antes del corte, no durante: por ejemplo, cualquier diferencia en la foto contable o una facturación bloqueada sin solución en unas horas. La versión antigua queda en solo lectura durante un tiempo acordado para consultas y auditoría, y lo que ocurra después del corte se registra ya en la versión nueva.

Plazos orientativos

El plazo lo marcan tres factores: cuántos módulos propios hay que adaptar, cuántos saltos de versión hay por delante y el estado de la contabilidad de partida. Como referencia, estas son duraciones orientativas para una pyme que pasa de Odoo 16 a Odoo 19:

Tu instalación	Duración del proyecto	Parada el día del corte
Pocos módulos propios y sin integraciones	4–8 semanas	Un fin de semana
Varios módulos propios e integraciones (tienda online, bancos)	2–4 meses	Un fin de semana
Muchas personalizaciones, varias empresas o mucho volumen de datos	4–6 meses	1–2 días, planificados

La mayor parte del tiempo se va en preparar y ensayar, no en el cambio en sí: tu equipo sigue trabajando con normalidad hasta la fecha del corte. La parada real se conoce con precisión gracias a los ensayos cronometrados, y tu plazo concreto se calcula en el diagnóstico.

Los errores que más encarecen

• Migrar sin inventario. Descubrir a mitad del proyecto que un módulo no existe en la versión de destino.
• Corregir datos durante la migración en lugar de hacerlo antes, en la versión actual.
• Ensayar una sola vez, o con datos de ejemplo, en lugar de iterar sobre copias recientes de producción.
• Intentar saltar varias versiones de golpe en lugar de subir un escalón cada vez.
• Copias de prueba sin neutralizar, que envían correos a clientes o presentan declaraciones.
• No congelar las entradas: pedidos o facturas que llegan durante el cambio y se quedan fuera.
• Desinstalar módulos con datos que se iban a necesitar: al desinstalar, esos datos se borran.
• Olvidar las vistas retocadas a mano en la base de datos, que desaparecen o rompen pantallas en la versión nueva.
• Dar por buena la migración sin comparar la contabilidad antes y después, al céntimo.
• No tener un criterio de vuelta atrás y decidir bajo presión el día del corte.

Si además te preocupa el coste, mira el precio de Odoo para una pyme.

Un caso real

Así se aplica este proceso en la práctica: migración de Odoo 16 y 17 sin parar la operación, un caso que resume el patrón de varias migraciones reales.