Actualizar Odoo no consiste simplemente en instalar una versión más reciente y conectar la misma base de datos.
Especialmente cuando queremos pasar de Odoo Community 16 a Odoo 19.
Entre ambas versiones encontramos tres saltos de versión mayor:
Odoo 16 → Odoo 17 → Odoo 18 → Odoo 19
Durante ese recorrido cambian modelos de datos, campos, vistas, APIs, dependencias y módulos.
Por eso es normal que antes de plantearse una actualización aparezca una preocupación:
¿Puedo migrar Odoo 16 a Odoo 19 sin perder clientes, facturas, inventario, compras, ventas o contabilidad?
La respuesta es sí: una migración correctamente planteada debe conservar los datos que necesita la empresa.
Pero para conseguirlo no basta con actualizar el código.
Hay que migrar la base de datos, revisar los módulos instalados, adaptar desarrollos propios, comprobar módulos OCA y, sobre todo, validar el resultado antes de sustituir el Odoo que utilizamos en producción.
Veamos cómo debería plantearse.
¿Por qué migrar ahora de Odoo 16 a Odoo 19?
Odoo publica una nueva versión principal aproximadamente cada año.
Según el ciclo de soporte publicado por Odoo, la versión 16 fue lanzada en octubre de 2022 y terminó su periodo de soporte estándar en septiembre de 2025.
Odoo 19 fue publicada en septiembre de 2025 y tiene soporte estándar planificado hasta septiembre de 2028.
Por tanto, en 2026 es lógico que muchas empresas que siguen trabajando con Odoo 16 se estén planteando actualizar.
Pero no recomendamos migrar únicamente porque exista una versión nueva.
Una actualización debe aportar beneficios y reducir riesgos.
Entre los motivos para actualizar podemos encontrar:
- utilizar una versión más reciente del framework;
- acceder a mejoras funcionales;
- disponer de módulos actualizados;
- mantener compatibilidad con integraciones externas;
- facilitar el mantenimiento futuro;
- incorporar mejoras de seguridad;
- evitar acumular demasiadas versiones pendientes de migración.
Cuanto mayor es la distancia entre nuestra versión y la actual, mayor suele ser también el trabajo necesario para actualizar.
¿Se pierden los datos al actualizar Odoo?
No deberían.
Una migración no consiste en empezar con una base de datos vacía.
El objetivo es transformar la base de datos existente para que pueda funcionar correctamente con la nueva versión.
Eso significa conservar información como:
- clientes;
- proveedores;
- productos;
- tarifas;
- pedidos de venta;
- pedidos de compra;
- facturas;
- pagos;
- asientos contables;
- inventario;
- movimientos de stock;
- contactos;
- empleados;
- histórico;
- configuraciones necesarias para el negocio.
Pero hay una diferencia importante entre decir:
“Los datos están en la nueva base de datos.”
y poder afirmar:
“Los datos están correctamente migrados y los procesos funcionan igual o mejor que antes.”
Lo segundo requiere pruebas.
El problema no suele ser únicamente la base de datos
Cuando analizamos una migración de Odoo Community encontramos normalmente tres tipos de componentes.
1. Módulos estándar de Odoo
Son los módulos que forman parte del propio proyecto Odoo.
Por ejemplo:
- Ventas.
- Compras.
- Inventario.
- Facturación.
- Contabilidad.
- CRM.
- Punto de venta.
Sus estructuras pueden cambiar entre versiones y los procesos de migración deben transformar los datos correspondientes.
2. Módulos OCA
Muchas instalaciones de Odoo Community utilizan módulos desarrollados y mantenidos por la Odoo Community Association (OCA).
Estos módulos son una de las grandes fortalezas del ecosistema Community.
Pero existe una cuestión fundamental:
un módulo disponible en Odoo 16 no tiene por qué estar todavía migrado a Odoo 19.
Por eso, antes de actualizar, tenemos que revisar uno por uno los módulos OCA utilizados por nuestra empresa.
3. Módulos desarrollados a medida
Este suele ser el punto más delicado.
Puede que nuestra instalación tenga módulos desarrollados específicamente para:
- integraciones;
- informes;
- automatizaciones;
- procesos internos;
- comercio electrónico;
- logística;
- facturación;
- conexiones con terceros.
Ese código fue desarrollado contra la API y estructura de Odoo 16.
No podemos asumir que funcionará directamente en Odoo 19.
Hay que revisarlo y, cuando sea necesario, migrarlo.
Primer paso: inventariar qué tenemos realmente instalado
Antes de tocar la base de datos debemos conocer exactamente qué estamos migrando.
Una buena auditoría debería separar los módulos en tres grupos:
Módulos estándar
Por ejemplo:
Ventas
Compras
Inventario
Contabilidad
CRM
Punto de venta
Módulos OCA
Debemos identificar:
- repositorio;
- módulo;
- versión;
- dependencias;
- disponibilidad para Odoo 19.
Desarrollos propios
Para cada desarrollo conviene responder:
- ¿Qué hace?
- ¿Quién lo desarrolló?
- ¿Sigue siendo necesario?
- ¿Qué módulos modifica?
- ¿Almacena datos propios?
- ¿Tiene integraciones externas?
- ¿Existe ya esa funcionalidad en Odoo 19?
Esta última pregunta es especialmente interesante.
A veces estamos pagando por migrar un desarrollo antiguo cuya funcionalidad ya existe actualmente en Odoo estándar o en un módulo OCA más moderno.
Una migración también es una oportunidad para eliminar deuda técnica.
No migres módulos simplemente porque existen
Imaginemos que en Odoo 16 tenemos 60 módulos adicionales instalados.
La reacción habitual es:
Hay que migrar los 60.
No necesariamente.
Quizás:
- 10 ya no se utilizan;
- 8 resolvían funciones que ahora cubre Odoo;
- 5 fueron sustituidos por otros módulos OCA;
- 3 corresponden a procesos que la empresa abandonó hace años.
Migrarlos todos aumenta:
- coste;
- complejidad;
- tiempo;
- dependencias;
- riesgo.
Antes de migrar código debemos preguntarnos si sigue aportando valor al negocio.
OpenUpgrade y Odoo Community
En el ecosistema Community una de las herramientas de referencia para las migraciones entre versiones es OpenUpgrade, mantenida dentro de OCA.
Su objetivo es proporcionar un camino Open Source para migrar bases de datos entre versiones mayores de Odoo.
Actualmente el proyecto dispone de rama para Odoo 19 y contiene tanto el framework como scripts específicos de migración.
Pero esto no debe interpretarse como:
“Instalo OpenUpgrade y automáticamente cualquier Odoo 16 pasa a Odoo 19.”
Cada migración depende de los módulos instalados y del estado de los scripts necesarios.
Por eso debemos comprobar la cobertura de nuestra instalación concreta.
¿Se migra directamente de Odoo 16 a 19?
Conceptualmente estamos recorriendo:
16 → 17 → 18 → 19
Las transformaciones de datos están vinculadas a los cambios producidos entre cada versión.
Por tanto, aunque podamos automatizar buena parte del proceso, debemos considerar los diferentes saltos de versión.
Esto tiene una consecuencia importante:
Un problema de compatibilidad en el salto 16 → 17 puede impedir llegar correctamente a 18 y 19.
Por eso las migraciones deben ser reproducibles y sus errores deben corregirse en el punto donde aparecen.
Cómo plantear una migración segura
Un proceso profesional podría dividirse en varias fases.
Fase 1. Auditoría
Antes de migrar revisamos:
- versión exacta de Odoo;
- versión de PostgreSQL;
- módulos instalados;
- módulos OCA;
- desarrollos propios;
- volumen de base de datos;
- filestore;
- integraciones;
- tareas programadas;
- informes personalizados;
- localización española;
- procesos fiscales;
- usuarios y permisos;
- infraestructura.
El objetivo es descubrir los problemas antes de iniciar la migración.
Fase 2. Copia completa
Nunca deberíamos realizar la primera migración sobre el sistema de producción.
Necesitamos como mínimo una copia completa de:
Base de datos PostgreSQL
Contiene la información estructurada de Odoo.
Filestore
Contiene archivos y adjuntos asociados a los registros.
Por ejemplo:
- PDFs;
- imágenes;
- documentos;
- adjuntos;
- archivos generados.
Tener únicamente una copia de PostgreSQL puede no ser suficiente si olvidamos el filestore.
Fase 3. Preparar Odoo 19
Antes de introducir los datos debemos disponer de un entorno compatible con Odoo 19.
Aquí revisaremos:
- versión de Python;
- PostgreSQL;
- librerías del sistema;
- dependencias Python;
- configuración del servidor;
- proxy;
- workers;
- almacenamiento;
- módulos necesarios.
No recomendamos aprovechar la migración para cambiar absolutamente todo al mismo tiempo sin planificación.
Cambiar simultáneamente versión de Odoo, infraestructura, módulos, integraciones y procesos multiplica los puntos de fallo.
Fase 4. Migrar o sustituir módulos
Para cada módulo adicional tenemos tres posibilidades.
Migrarlo
Cuando sigue siendo necesario y existe una versión compatible.
Sustituirlo
Cuando Odoo 19 u otro módulo mantenido proporciona ya la misma funcionalidad.
Eliminarlo
Cuando ya no se utiliza.
Los módulos propios requieren una revisión técnica específica.
Entre Odoo 16 y 19 pueden haber cambiado:
- vistas XML;
- modelos;
- métodos;
- campos;
- Javascript;
- OWL;
- QWeb;
- seguridad;
- assets;
- APIs internas.
Que un módulo “se instale” no significa necesariamente que funcione correctamente.
Tenemos que probar el proceso empresarial que resuelve.
Fase 5. Primera migración de pruebas
Con los componentes preparados ejecutamos una primera migración sobre una copia de producción.
Esta primera ejecución sirve precisamente para encontrar problemas.
No esperamos que sea necesariamente la definitiva.
Podemos encontrar:
- campos que necesitan transformación;
- referencias rotas;
- módulos no disponibles;
- vistas incompatibles;
- datos inconsistentes;
- cambios funcionales;
- dependencias inesperadas.
Cada incidencia detectada debe convertirse en una corrección reproducible.
El objetivo es poder repetir posteriormente la migración desde una copia limpia y obtener siempre el mismo resultado.
¿Cómo comprobamos que no hemos perdido datos?
No sirve únicamente con abrir Odoo 19 y comprobar que podemos iniciar sesión.
Hay que comparar.
Por ejemplo:
Contactos
Número de clientes y proveedores antes y después.
Ventas
Pedidos históricos y pedidos pendientes.
Compras
Pedidos abiertos, recepciones y facturas asociadas.
Facturación
Número de facturas, estados, importes, impuestos y vencimientos.
Contabilidad
Saldos, diarios, cuentas y balances.
Inventario
Existencias por producto y ubicación.
Punto de venta
Sesiones, pedidos y pagos históricos.
Adjuntos
Documentos, PDFs e imágenes asociados.
Una migración debe disponer de criterios de aceptación medibles.
Por ejemplo:
El saldo contable a 31/08/2026 debe coincidir antes y después de la migración.
Las existencias de todos los almacenes deben coincidir.
El número de facturas contabilizadas debe ser idéntico.
Todos los pedidos pendientes deben continuar disponibles.
Esto es mucho más fiable que revisar pantallas aleatoriamente.
Contabilidad: una de las áreas que más debemos validar
En una empresa española no basta con comprobar que podemos abrir una factura.
Tenemos que verificar:
- diarios;
- cuentas;
- impuestos;
- posiciones fiscales;
- conciliaciones;
- pagos;
- facturas rectificativas;
- fechas de bloqueo;
- secuencias;
- informes contables;
- localización española.
Y también cualquier módulo OCA utilizado para obligaciones fiscales o informes.
Una migración técnicamente correcta puede no serlo desde el punto de vista funcional si contabilidad obtiene resultados diferentes.
Inventario también necesita pruebas específicas
Supongamos que después de migrar podemos ver todos nuestros productos.
Eso no significa todavía que el inventario sea correcto.
Debemos comprobar:
- stock por producto;
- stock por ubicación;
- movimientos pendientes;
- recepciones;
- entregas;
- lotes;
- números de serie;
- rutas;
- reglas logísticas.
Una diferencia pequeña en inventario puede terminar convirtiéndose en un problema importante días después de la puesta en producción.
¿Y las integraciones externas?
Son otro punto crítico.
Odoo puede estar conectado con:
- tiendas online;
- bancos;
- transportistas;
- marketplaces;
- APIs;
- aplicaciones móviles;
- software de terceros;
- servicios de facturación;
- hardware;
- sistemas de producción.
Una migración puede conservar perfectamente todos los datos y, sin embargo, romper una integración porque el código dependía del comportamiento de Odoo 16.
Por eso las integraciones forman parte de las pruebas.
Fase 6. Pruebas de usuarios
Los técnicos pueden comprobar que el sistema no genera errores.
Pero eso no significa que el proceso empresarial funcione correctamente.
Las personas que utilizan Odoo diariamente deberían probar escenarios reales.
Por ejemplo:
Comercial
Crear presupuesto → confirmar → entregar → facturar.
Compras
Crear pedido → recibir mercancía → registrar factura.
Almacén
Recepción → movimiento interno → entrega.
Contabilidad
Factura → pago → conciliación.
Punto de venta
Abrir sesión → vender → cobrar → cerrar sesión.
Es lo que habitualmente denominamos pruebas de aceptación de usuario o UAT.
Aprovechar la migración para revisar procesos
Migrar no debería significar copiar todos los problemas existentes a la nueva versión.
Es un buen momento para preguntarnos:
- ¿Seguimos necesitando esta personalización?
- ¿Podemos volver al estándar?
- ¿Existe ahora un módulo OCA?
- ¿Hay automatizaciones que ya no tienen sentido?
- ¿Tenemos datos duplicados?
- ¿Existen módulos instalados que nadie utiliza?
- ¿Podemos simplificar permisos?
Una migración puede ser también una oportunidad para limpiar el ERP.
Fase 7. Ensayo de la migración definitiva
Antes del cambio real recomendamos repetir todo el proceso.
Partimos nuevamente de una copia reciente de producción y ejecutamos:
backup → migración → validaciones → arranque → pruebas
Esto permite medir y comprobar:
- duración del proceso;
- orden exacto de ejecución;
- errores esperables;
- pasos manuales;
- comprobaciones posteriores.
La puesta en producción deja así de ser un experimento.
Ya hemos realizado el mismo procedimiento anteriormente.
Fase 8. Puesta en producción
Cuando todo está validado llega el cambio definitivo.
El procedimiento dependerá de cada infraestructura, pero normalmente necesitaremos:
- Detener temporalmente la actividad en Odoo 16.
- Realizar una copia final.
- Migrar esa copia con el procedimiento validado.
- Ejecutar comprobaciones.
- Poner Odoo 19 a disposición de los usuarios.
- Validar procesos críticos.
- Mantener Odoo 16 disponible como respaldo durante el periodo definido.
Es importante evitar que los usuarios sigan introduciendo información en Odoo 16 mientras estamos migrando la copia definitiva.
De lo contrario aparecerán datos nuevos en la versión antigua que no existirán en Odoo 19.
Siempre debe existir un plan de vuelta atrás
Antes de empezar la puesta en producción debemos responder una pregunta:
¿Qué hacemos si descubrimos un problema crítico después de migrar?
La respuesta no puede improvisarse ese día.
Tenemos que saber:
- dónde está la copia de Odoo 16;
- cuánto tardamos en recuperarla;
- qué datos podrían haberse introducido después del cambio;
- quién toma la decisión de volver atrás;
- durante cuánto tiempo mantenemos el entorno anterior.
El plan de rollback es parte de la migración.
No significa que esperemos que algo falle.
Significa que estamos preparados si ocurre.
Errores frecuentes al migrar Odoo
1. Probar directamente en producción
Es probablemente el error más peligroso.
La primera migración debe hacerse siempre sobre una copia.
2. Revisar solo los módulos estándar
Los módulos OCA y personalizados suelen concentrar buena parte de la complejidad.
3. Olvidar el filestore
Base de datos y archivos deben tratarse conjuntamente.
4. Pensar que si Odoo arranca, la migración ha terminado
Arrancar es solo el principio.
Tenemos que validar procesos y datos.
5. No involucrar a los usuarios
Un técnico puede comprobar que Ventas funciona.
El comercial que utiliza el proceso ocho horas al día puede detectar en cinco minutos algo que técnicamente parecía correcto.
6. Migrar personalizaciones obsoletas
No todo el código antiguo merece ser llevado a la nueva versión.
7. No comprobar cifras antes y después
Una migración sin comparación de datos dificulta demostrar que todo está correcto.
¿Cuánto cuesta migrar de Odoo 16 a 19?
No existe una respuesta única.
Dos empresas pueden utilizar Odoo 16 y necesitar esfuerzos completamente diferentes.
Una instalación con:
- Ventas;
- Compras;
- Inventario;
- pocos módulos adicionales;
puede ser relativamente sencilla.
Otra con:
- decenas de módulos OCA;
- módulos personalizados;
- ecommerce;
- integraciones;
- múltiples compañías;
- POS;
- localización española avanzada;
- gran volumen histórico;
requiere un proyecto mucho mayor.
Por eso resulta difícil valorar correctamente una migración sin realizar primero una auditoría.
El coste depende mucho más de lo que hemos construido alrededor de Odoo que del número de versión que aparece en pantalla.
¿Tengo que cambiar de servidor para migrar Odoo?
No necesariamente.
Migrar Odoo y cambiar de proveedor de alojamiento son dos decisiones diferentes.
Puede que técnicamente resulte conveniente renovar infraestructura, pero una migración de versión no debería obligarnos por sí sola a alojar Odoo con un proveedor concreto.
Una de las ventajas de Odoo Community es precisamente la libertad para decidir dónde desplegarlo:
- infraestructura propia;
- VPS;
- proveedor cloud;
- infraestructura gestionada.
La arquitectura debe elegirse por necesidades técnicas y empresariales, no simplemente porque estemos actualizando de versión.
¿Es mejor migrar o empezar con un Odoo 19 nuevo?
En determinados casos merece la pena estudiar ambas posibilidades.
Migración
Tiene sentido cuando queremos conservar:
- histórico;
- trazabilidad;
- relaciones entre documentos;
- contabilidad;
- movimientos;
- información operativa.
Nueva implantación
Puede estudiarse cuando la base anterior presenta:
- muchísimas personalizaciones obsoletas;
- datos de muy baja calidad;
- procesos completamente distintos a los actuales;
- una implantación que la empresa quiere rediseñar desde cero.
Pero una nueva implantación tampoco elimina el problema de los datos.
Hay que decidir qué información importar y cómo conservar el histórico que pueda ser necesario consultar.
Por eso la decisión debe tomarse después de analizar la instalación existente.
Checklist antes de migrar de Odoo 16 a Odoo 19
Antes de iniciar el proyecto deberíamos poder marcar todas estas casillas:
☐ Tenemos una lista de módulos instalados.
☐ Sabemos cuáles son estándar, OCA y propios.
☐ Hemos comprobado la disponibilidad de los módulos para Odoo 19.
☐ Hemos identificado las personalizaciones.
☐ Sabemos qué integraciones externas existen.
☐ Disponemos de copia de PostgreSQL y filestore.
☐ Tenemos un entorno independiente de pruebas.
☐ Hemos definido qué datos debemos comparar antes y después.
☐ Contabilidad participará en la validación.
☐ Los usuarios clave probarán sus procesos.
☐ Tenemos un procedimiento de migración reproducible.
☐ Hemos realizado al menos un ensayo completo.
☐ Existe un plan de rollback.
Si varias respuestas son “no”, probablemente todavía no sea el momento de ejecutar la migración definitiva.
Migrar Odoo no es copiar una base de datos: es migrar un sistema de gestión
La información de una empresa no está formada únicamente por tablas PostgreSQL.
Está formada por relaciones entre:
- clientes;
- pedidos;
- facturas;
- pagos;
- productos;
- movimientos;
- configuraciones;
- documentos;
- procesos;
- módulos.
Por eso una buena migración debe conservar tanto los datos como el comportamiento que necesita el negocio.
Pasar de Odoo Community 16 a Odoo 19 es perfectamente abordable, pero debemos tratarlo como un proyecto técnico y funcional.
No como una actualización de escritorio.
¿Necesitas migrar Odoo Community 16 a Odoo 19?
En SOLUCIONEX trabajamos con Odoo Community, módulos OCA y desarrollos personalizados.
Antes de plantear una migración analizamos la instalación existente para identificar:
- módulos utilizados;
- personalizaciones;
- dependencias OCA;
- integraciones;
- datos críticos;
- infraestructura.
A partir de ahí podemos determinar qué debe migrarse, qué puede sustituirse por funcionalidad estándar y qué desarrollos necesitan adaptación.
El objetivo no es simplemente conseguir que Odoo 19 arranque.
El objetivo es que la empresa pueda continuar trabajando con sus datos, su histórico y sus procesos correctamente validados.
Preguntas frecuentes
¿Puedo pasar directamente de Odoo 16 a Odoo 19?
Es posible llegar desde Odoo 16 a Odoo 19, pero una migración Community debe contemplar las transformaciones existentes entre las sucesivas versiones mayores. Con herramientas como OpenUpgrade, los scripts de migración están asociados a los diferentes saltos entre versiones.
¿Perderé mis facturas al migrar?
Una migración correctamente realizada está diseñada para conservar el histórico necesario. No obstante, después del proceso deben verificarse facturas, asientos, pagos, impuestos y saldos para confirmar la integridad de la información.
¿Se conserva el inventario?
Debe conservarse, pero conviene validar específicamente existencias por producto y ubicación, movimientos abiertos, lotes y números de serie cuando se utilicen.
¿Qué ocurre con mis módulos OCA?
Hay que comprobar individualmente si están disponibles para la versión de destino, si han cambiado de nombre o funcionalidad y si todas sus dependencias están migradas.
¿Y los módulos desarrollados a medida?
Deben auditarse y adaptarse cuando los cambios entre Odoo 16 y 19 afecten al código que utilizan. No podemos asumir que un módulo de Odoo 16 funcionará directamente en Odoo 19.
¿OpenUpgrade migra automáticamente cualquier Odoo?
No. OpenUpgrade proporciona herramientas y scripts para facilitar las migraciones entre versiones de Odoo, pero debemos verificar la cobertura de los módulos utilizados y resolver las particularidades de cada instalación.
¿Necesito cambiar de servidor?
No necesariamente. El cambio de versión y el alojamiento son decisiones independientes. Una migración puede incluir un cambio de infraestructura si resulta conveniente, pero no debería ser una obligación por el simple hecho de actualizar Odoo.
¿Cómo puedo saber si mi Odoo está preparado para migrar?
El primer paso es realizar una auditoría de módulos, personalizaciones, integraciones, infraestructura y datos. Con esa información puede estimarse la complejidad real del proyecto.
