Guía · Migración

Migrar a Odoo 20: qué cambia, qué exige y cómo se prueba antes de producción

Autor: Eduin Garnica, CTO
Publicada: 17 de octubre de 2026
Actualizada: 17 de octubre de 2026
Versión: Odoo 20

En corto

Migrar a Odoo 20 es pedirle a la plataforma oficial de upgrade de Odoo una copia convertida de la base, probarla a fondo y sólo entonces convertir la de producción. Con la suscripción Enterprise, Odoo convierte sin costo las aplicaciones estándar, lo hecho con Studio y los módulos que cubre un contrato de mantenimiento; los módulos a medida y de terceros sin ese contrato los adapta quien los mantiene, y la base no se migra hasta que exista su versión para la 20.0. En servidor propio, la 20 exige Python 3.12 a 3.14 y PostgreSQL 16 o posterior. Una base en la 19.0 tiene soporte estándar hasta septiembre de 2028, así que hay tiempo para planear el cambio.

Qué es migrar de versión en Odoo

Odoo publica una versión mayor al año —la 18.0 salió en octubre de 2024, la 19.0 en septiembre de 2025 y la 20.0 en septiembre de 2026— y cada una recibe tres años de soporte estándar. Migrar es mover la base de datos de una versión a otra más reciente, con sus datos, sus aplicaciones y el código propio que las extiende. Odoo llama a ese proceso upgrade y lo ofrece como servicio dentro de la suscripción Enterprise.

Quien llega a esta guía buscando otro cambio conviene que lo sepa desde aquí: la documentación oficial excluye de la migración de versión el regreso a una versión anterior, el cambio de edición —de Community a Enterprise, por ejemplo—, el cambio de alojamiento y la migración desde otro ERP. Cada una de esas cosas es un proyecto aparte, con su propio proceso.

Upgrade (migración de versión): El proceso con que Odoo convierte una base de una versión a otra más reciente, con sus datos y sus aplicaciones.
Plataforma de upgrade: El servicio de Odoo en upgrade.odoo.com que recibe la base, la convierte y devuelve una copia de prueba o la base de producción ya convertida.
Base de prueba: Una copia convertida de la base de producción, con las funciones que tocan el exterior desactivadas, hecha para probar sin afectar la operación.
Módulo a medida: Código propio que extiende el comportamiento estándar de Odoo y que no se construyó con la aplicación Studio.
Módulo de terceros: Un módulo que no escribieron ni Odoo ni tu empresa, como los de la tienda de aplicaciones de Odoo o los de otro proveedor.

Qué cambia en Odoo 20

Las notas de lanzamiento de Odoo 20, publicadas en septiembre de 2026, recorren decenas de aplicaciones y localizaciones. Para una migración no pesan igual: unas novedades se usan si se quiere, y otras cambian cómo está construido el sistema y obligan a revisar el código propio. La tabla reúne las que más pesan en una empresa mediana —con la localización mexicana para la que opera en México—, con las palabras de las propias notas, y deja fuera las que esas notas marcan como disponibles también en la 19.0.

Cambios de Odoo 20 que pesan en una migración
Cambio	Lo que dicen las notas de lanzamiento	Qué implica al migrar
Inteligencia artificial con créditos	«Ahora todas las funciones de IA requieren créditos que puedes adquirir mediante compras dentro de la aplicación.»	El consumo de IA se compra aparte: la página de precios de Odoo lo lista entre lo que sus planes no incluyen.
Servidor MCP	«Conéctate a tu base de datos mediante MCP (protocolo de contexto del modelo).»	Un agente de IA externo puede leer o modificar la base con los permisos del usuario que lo conecta.
Permisos de acceso	«Simplificamos los permisos de acceso al eliminar las reglas de registro y agregar un dominio directamente en el nivel de permisos de acceso para determinar a qué registros aplica cada permiso.»	Los módulos a medida que declaran permisos o reglas con el formato de la 19 se adaptan al modelo nuevo.
Valores de seguimiento del chatter	«Eliminamos los valores de seguimiento y ahora el mensaje de seguimiento se genera al momento. […] Los administradores que todavía necesiten los valores de seguimiento pueden instalar un módulo específico.»	Si un reporte o una auditoría dependía de esos valores, se instala ese módulo antes de dar la migración por buena.
Localización mexicana	Constancia de cancelación de CFDI, factura global bimestral, balance general con la NIF B-6 y pérdidas y ganancias con la NIF B-3, XML complementarios de la balanza de comprobación, descarga de facturas de proveedor faltantes con la FIEL desde el SAT, conductor de la Carta Porte elegido en la orden de entrega, y salario mínimo, tablas del ISR y UMA actualizados.	Se prueban en la base de prueba contra la configuración fiscal real de la empresa.

El cambio de permisos es el que más trabajo da cuando hay código propio, y en la rama 20.0 del código de Odoo se ve sin necesidad de interpretar: el módulo base dejó de traer el modelo de reglas de registro, ir.rule, y trae uno nuevo, ir.access, que guarda junto a cada permiso el dominio de registros al que aplica. El módulo de Ventas sirve de ejemplo: en la 19.0 declaraba sus permisos en ir.model.access.csv y sus reglas en ir_rules.xml, y en la 20.0 declara un solo archivo, ir.access.csv. La documentación de Odoo pone, entre los errores que aparecen al instalar un módulo en la versión nueva, las referencias a campos, modelos o vistas estándar que ya no existen o cambiaron de nombre. Un módulo escrito para la 19 que declara sus permisos con el formato anterior cae justo en ese caso, y por eso se adapta antes de migrar.

Cuándo hay que migrar

La urgencia la pone el soporte. Durante el soporte estándar, Odoo da actualizaciones de seguridad, corrección de errores y atención de su mesa de ayuda. Cuando termina empieza el soporte extendido, que tiene un cargo adicional, sólo existe en Odoo.sh —para algunas versiones— y en servidor propio, y ya no trae actualizaciones de seguridad. La tabla muestra dónde queda cada versión mayor vigente, según la tabla de soporte que publica Odoo.

Soporte de las versiones mayores de Odoo al 17 de octubre de 2026
Versión	Lanzamiento	Fin del soporte estándar	Situación
Odoo 20.0	Septiembre de 2026	Septiembre de 2029 (planeado)	Soporte estándar en Odoo Online, Odoo.sh y servidor propio
Odoo 19.0	Septiembre de 2025	Septiembre de 2028 (planeado)	Soporte estándar en los tres alojamientos
Odoo 18.0	Octubre de 2024	Septiembre de 2027 (planeado)	Soporte estándar en los tres alojamientos
Odoo 17.0	Noviembre de 2023	Septiembre de 2026	Sólo soporte extendido, con cargo, en Odoo.sh y servidor propio

Una base en la 19.0 tiene, entonces, casi dos años de soporte estándar por delante: de octubre de 2026 a septiembre de 2028 van 23 meses, y ninguna fecha obliga a migrar este año. Lo que sí cambia con el tiempo es el costo de quedarse atrás. El contrato de suscripción de Odoo llama «versiones cubiertas» a las tres versiones mayores más recientes —hoy la 20.0, la 19.0 y la 18.0— y, una vez al año y no antes de seis meses después del lanzamiento de una versión mayor, cobra un 25 % adicional sobre el precio anual a la base que esté en una versión anterior a ésas. Con la 20.0 lanzada en septiembre de 2026, ese cargo puede alcanzar a una base en la 17.0 o anterior a partir de marzo de 2027.

Para elegir la versión destino, la regla es amplia: se puede migrar desde cualquier versión a cualquier versión mayor que siga en soporte estándar, o que lo haya perdido hace menos de seis meses. Una base en la 17.0 o en la 18.0 puede ir directo a la 20.0, sin pasar por la 19.0. Cada alojamiento pone además su propio límite. En Odoo Online, una versión mayor obliga a migrar cada dos años; en Odoo.sh, al terminar los tres años de soporte quedan dos más para completar la migración, así que una base en la 19.0 tendría hasta 2030; en servidor propio, la base puede quedarse en su versión indefinidamente, aunque la documentación no lo recomienda y advierte que entre menor es el salto, más fácil es la migración.

Requisitos técnicos en servidor propio

En Odoo Online y en Odoo.sh la infraestructura la opera Odoo, así que esta sección sólo le toca a quien aloja Odoo en un servidor propio. Ahí la 20 sube dos mínimos: según su documentación, Python pasa de 3.10 a 3.12 y PostgreSQL de 13 a 16. El código de la rama 20.0 fija además un techo para Python, porque el archivo odoo/release.py declara la 3.12 como mínima y la 3.14 como máxima. La tabla reúne lo que pide la versión y lo que hace Odoo cuando el servidor no lo cumple, leído en el propio código.

Lo que exige Odoo 20 en un servidor propio
Componente	Lo que exige la 20.0	Qué pasa fuera de ese rango
Python	De la 3.12 a la 3.14	Con una anterior a la 3.12, Odoo no arranca; con una posterior a la 3.14, arranca y avisa que esa versión no tiene soporte oficial.
PostgreSQL	La 16 o posterior	Con una anterior, Odoo emite una advertencia de que está por debajo del mínimo.
Extensión pg-vector de PostgreSQL	La pide la documentación para usar las funciones de IA	La extensión sólo existe para PostgreSQL 15 en adelante.

La cuenta se hace sobre el servidor actual. Uno que hoy corre la 19.0 sobre PostgreSQL 14 cumple el mínimo de la 19, que es la 13, y no el de la 20, que es la 16: la base de datos del servidor se actualiza como parte del proyecto, antes de restaurar ahí la base convertida. Lo mismo vale para el sistema operativo, porque los instaladores empaquetados de Odoo 20 se publican para Ubuntu Noble (24.04 LTS), en paquete .deb, y para Fedora 42, en .rpm. Y hay un requisito de red que suele aparecer tarde: el script de upgrade necesita alcanzar los servidores de la plataforma por el puerto TCP 443 y por cualquier puerto TCP entre el 32768 y el 60999, lo que en un firewall restrictivo pide una excepción.

Cómo funciona el proceso oficial

La migración que documenta Odoo tiene siete pasos, y su orden protege a la operación: la base de producción no se toca hasta el sexto, y todo lo anterior ocurre sobre copias.

Se pide una base de prueba convertida a la versión destino.
Si hay módulos a medida, se adapta su código a la versión nueva.
Se prueba a fondo la base de prueba.
Cada problema encontrado se reporta a Odoo desde su página de soporte, con la opción de la migración en prueba.
Cuando los problemas están resueltos y la base de prueba ya podría usarse como principal, se planea la migración de producción.
Se pide la migración de la base de producción, que queda fuera de servicio mientras dura.
Cualquier problema de esa migración se reporta a Odoo con la opción de producción de su página de soporte.

Lo que cambia entre alojamientos es dónde se pide cada copia y qué pasa con el código propio. Odoo.sh está integrado con la plataforma de upgrade y trabaja sobre ramas de staging; el servidor propio usa un comando y devuelve un respaldo que hay que restaurar; Odoo Online lo resuelve desde su administrador de bases de datos. La tabla resume esas diferencias tal como las describe la documentación.

Cómo se hace la migración en cada alojamiento
Momento	Odoo Online	Odoo.sh	Servidor propio
Pedir la base de prueba	Desde el administrador de bases de datos, con el propósito «Test»	Desde el proyecto: Odoo envía a la plataforma el respaldo diario más reciente de producción y devuelve la base convertida en una rama de staging	Con el comando `python <(curl -s https://upgrade.odoo.com/upgrade) test -d <base> -t <versión>` o desde upgrade.odoo.com
Probar el código propio	No aplica: Odoo Online no admite módulos con código Python, y por eso tampoco scripts de migración	Cada commit en la rama restaura la base convertida y actualiza todos los módulos a medida	Se restaura el respaldo convertido y se actualizan los módulos con `odoo-bin -u`
Migrar producción	El mismo flujo con el propósito «Production»; al terminar no hay forma de regresar a la versión anterior	Se dispara con un commit en la rama de producción; si algo falla, la plataforma revierte la migración, y si sale bien, guarda un respaldo previo	El comando cambia `test` por `production`; la copia viaja sin su filestore, la carpeta de archivos adjuntos, que se fusiona con el de producción antes de arrancar

Cada migración que termina trae un reporte de upgrade, que llega en el correo de la base convertida y queda en Conversaciones para los administradores, con los cambios que introdujo la versión nueva. Y con la suscripción Enterprise, la conversión no se cobra aparte. La documentación lo dice así:

«With Odoo Enterprise, upgrading a database to the most recent version of Odoo is free, including any support required to rectify potential discrepancies in the upgraded database.»

Odoo, «Upgrade», documentación oficial de Odoo 20.0, consultada el 17 de octubre de 2026.

Ese servicio se limita a la conversión técnica: adaptar los módulos estándar y sus datos a la versión destino. La limpieza de datos y configuraciones previas, la formación en la versión nueva y la conversión de los módulos que no tienen contrato de mantenimiento quedan fuera, y de eso trata la siguiente sección.

Módulos a medida y de terceros

De todo lo que hay en una base, el código propio es lo único que Odoo no convierte por sí solo, y por eso es lo que fija el calendario. La regla está en la misma página de upgrade:

«If your database contains custom modules, it cannot be upgraded until a version of your custom modules is available for the target version of Odoo.»

Odoo, «Upgrade», documentación oficial de Odoo 20.0, consultada el 17 de octubre de 2026.

Quién hace esa versión lo decide el contrato. El Enterprise Subscription Agreement llama módulo adicional (Extra Module) a todo código que agrega funciones o cambia el comportamiento estándar, lo haya escrito el cliente, Odoo, un partner o un tercero, incluidas las personalizaciones en Python hechas dentro de la base con Studio. Y llama módulo adicional cubierto al que vive en Odoo Online o al que tiene pagada una cuota de mantenimiento. De ahí sale el reparto de la tabla, que combina el contrato con la sección de cobertura de la documentación de upgrade.

Quién convierte cada parte de la base al migrar
Parte de la base	Quién la convierte	Condición
Aplicaciones estándar	Odoo, dentro de la suscripción	Ninguna adicional
Personalizaciones hechas con Studio	Odoo	Que Studio siga instalado y la suscripción activa
Módulos con contrato de mantenimiento	Odoo, o el partner al que Odoo le subcontrata esos servicios	Que se pague la cuota de mantenimiento, que el contrato calcula por cada 100 líneas de código
Módulos a medida o de terceros sin ese contrato	Quien los mantiene: el equipo de la empresa, su partner o el autor del módulo	Que exista su versión para la 20.0 antes de migrar

Para los módulos que le tocan a quien los mantiene, la documentación propone seis pasos, y cada uno ataca un riesgo distinto. El primero es congelar el desarrollo, porque cada función que cambie a media migración habrá que migrarla y probarla otra vez; las correcciones de errores quedan exentas. En ese mismo paso se compara lo desarrollado contra lo que la versión nueva ya trae: una función que Odoo 20 resuelve de forma estándar es código que conviene retirar, porque aligera esta migración y las siguientes. El segundo es pedir una base convertida sólo para confirmar que la conversión estándar funciona. El tercero es instalar cada módulo, uno por uno, en una base vacía de la 20.0, que es donde aparecen las dependencias inválidas, los cambios de sintaxis y las referencias a campos, modelos o vistas que ya no existen; el cambio de permisos de la sección de novedades se detecta aquí. Con los módulos instalables se prueban vistas, plantillas de correo, reportes, acciones de servidor y automatizadas, cambios a flujos estándar y campos calculados, y se escriben pruebas automáticas para repetir la revisión en cada vuelta.

El cuarto paso pasa los módulos a la base convertida. Ahí entran los scripts de migración, apoyados en la biblioteca de utilidades de upgrade de Odoo, para renombrar campos, modelos o identificadores sin perder datos, y ahí se revisa el reporte de upgrade, que lista las vistas que se desactivaron por causar errores. El quinto es otra ronda de pruebas y un ensayo completo el día anterior a producción, y el sexto es la migración de producción.

Un módulo de la tienda de aplicaciones de Odoo sigue la misma regla que uno propio, porque para Odoo también es un módulo a medida: su versión para la 20.0 la publica quien lo mantiene, y mientras no exista, la base no se migra. Por eso el inventario de los módulos de terceros instalados, con el autor de cada uno y si ya publicó su versión 20.0, va al principio del proyecto y no al final.

La IA de Odoo 20 y el servidor MCP

La inteligencia artificial es la novedad más visible de la 20, y al migrar conviene separarla en dos piezas. La primera es la aplicación de IA dentro de Odoo, con agentes que entienden peticiones en lenguaje natural y ejecutan tareas con las herramientas que se les dan. Su uso consume créditos de compra dentro de la aplicación, y la documentación advierte que instalarla en una base con el plan Estándar dispara el cambio al plan Personalizado. En servidor propio, además, pide la extensión pg-vector de PostgreSQL.

La segunda es el servidor MCP. El Model Context Protocol es un estándar abierto que permite a un modelo de lenguaje interactuar con aplicaciones externas y consultar sus datos, y Odoo 20 lo usa para que un agente de IA externo lea o modifique la base desde las herramientas de quien lo usa. La documentación de la 20.0 le dedica una página propia, que la de la 19.0 no tiene, y de ella salen cuatro decisiones que se toman antes de abrirlo:

La autenticación — OAuth es el método recomendado, porque el usuario aprueba el acceso desde su cliente sin copiar ni exponer claves; sólo lo pueden usar los usuarios internos, y los de portal se conectan con una clave de API.
Los permisos — cada petición del cliente se autentica con la identidad y los permisos del usuario en Odoo, así que el agente ve y cambia lo mismo que ese usuario puede ver y cambiar.
Las herramientas expuestas — de fábrica, la base le ofrece al cliente cinco herramientas de consulta: AI Tool: Get Fields, AI Tool: Get Models, AI Tool: MCP Retrieve initial context, AI Tool: Search y AI Tool: Read group. Cualquier otra se expone a mano, una por una, desde las acciones de servidor.
La revocación — cada conexión aparece como una clave de API en las preferencias del usuario, y se revoca borrándola, así que cerrar un acceso no exige tocar el servidor.

Cómo se prueba antes de pasar a producción

La base de prueba existe para equivocarse sin consecuencias, y Odoo la entrega neutralizada para que nada de lo que se haga en ella salga de ella:

Acciones programadas desactivadas — ningún proceso automático corre por su cuenta mientras se prueba, así que un cálculo o un envío programado no se dispara dos veces.
Correo saliente desactivado — Odoo archiva los servidores de correo y agrega uno falso, de modo que ningún cliente ni proveedor recibe correos de la prueba.
Pagos y envíos en ambiente de prueba — los proveedores de pago y los transportistas pasan a su ambiente de prueba, y un cobro o una guía generados en la copia no son reales.
Sincronización bancaria desactivada — para probarla hay que pedirle credenciales de prueba al proveedor de la sincronización.

Sobre esa copia, la documentación propone una lista básica: que las vistas habituales se vean bien y que no haya vistas desactivadas que en producción estén activas; que los reportes, como facturas y órdenes de venta, se generen; que las páginas del sitio web funcionen; que se puedan crear y modificar registros; que las plantillas de correo, las traducciones guardadas y los filtros de búsqueda sigan ahí, y que los datos se puedan exportar. A esa lista le suma cinco frentes que suelen olvidarse: las integraciones con otros sistemas, los flujos que cruzan aplicaciones —de la oportunidad a la orden de venta y a la entrega—, las exportaciones de datos, las acciones automatizadas y las acciones de servidor. En una empresa que opera en México, la localización entra en la misma revisión: las novedades fiscales de la tabla de arriba se prueban contra la configuración real.

La prueba de extremo a extremo que sugiere Odoo sigue un producto por todo su ciclo: se compra, se recibe, se vende, se envía, se factura, se emite su nota de crédito y se revisan los reportes contables, comparando cada paso contra producción. Si algo falla, se reporta desde la página de soporte de Odoo con la opción de la migración en prueba. Conviene hacerlo durante la prueba y no después, porque los cambios de la versión nueva a vistas, campos y modelos estándar no se revierten caso por caso: si rompen una personalización, adaptarla le toca a quien mantiene el módulo.

Para el día de producción, la documentación pide tres cosas. La primera es pedir bases de prueba nuevas con frecuencia mientras dura el proyecto, porque los scripts de Odoo y la propia base siguen cambiando. La segunda, ensayar la migración completa el día anterior. La tercera, agendarla cuando el uso sea mínimo, porque la base queda fuera de servicio mientras se convierte; en servidor propio, además, lo que se registre en producción después de enviar la copia no llega a la base convertida, así que la base no se usa durante el proceso. Si el ensayo del día anterior sale limpio y la base de prueba ya sostiene la operación completa, la migración de producción es la repetición de algo que ya funcionó.

Preguntas frecuentes

¿Cuándo salió Odoo 20 y hasta cuándo tiene soporte?

Odoo 20.0 salió en septiembre de 2026, y la tabla de soporte de Odoo le planea soporte estándar hasta septiembre de 2029: los tres años que recibe cada versión mayor.

¿Puedo migrar de Odoo 17 o 18 directo a la 20, sin pasar por la 19?

Sí. Odoo permite migrar desde cualquier versión a cualquier versión mayor que siga en soporte estándar, y la 20.0 lo está. La documentación advierte que entre menor es el salto, más fácil es la migración.

¿Cuánto cuesta migrar a Odoo 20?

Con Odoo Enterprise, la conversión de la base a la versión más reciente no tiene costo, incluido el soporte para corregir diferencias en la base convertida. Quedan fuera la limpieza de datos, la formación y la adaptación de los módulos a medida o de terceros que no tengan contrato de mantenimiento.

¿La migración a la 20 también me pasa de Community a Enterprise, o de Odoo Online a Odoo.sh?

No. La documentación de Odoo excluye de la migración de versión el cambio de edición y el cambio de alojamiento: cada uno es un proceso propio. Pasar a Enterprise se planea aparte, y con Enterprise la conversión a cada versión nueva viene incluida.

¿Odoo 20 tiene servidor MCP?

Sí. La documentación de la 20.0 dedica una página al servidor MCP de Odoo, que permite a un agente de IA externo leer o modificar la base con los permisos del usuario que lo conecta. La documentación de la 19.0 no tiene esa página.

¿Qué implica llevar tu Odoo a la 20?

La versión, el alojamiento y los módulos a medida deciden qué convierte Odoo por su cuenta y qué hay que adaptar antes de migrar. Compártenos esos tres datos y revisamos qué implica en tu caso.

¿Estás planeando tu migración a Odoo 20? Conoce el servicio de migración a Odoo 20 o escríbenos.

Fuentes

Odoo S.A., «Upgrade», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/administration/upgrade.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «Standard and extended support», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/administration/standard_extended_support.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «Upgrade a customized database», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/developer/howtos/upgrade_custom_db.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «Notas de lanzamiento de Odoo 20», odoo.com, odoo.com/es/odoo-20-release-notes. Consultada el 17 de octubre de 2026.
Odoo S.A., «Source install», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/administration/on_premise/source.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «Packaged installers», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/administration/on_premise/packages.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «odoo/release.py», repositorio público odoo/odoo, rama 20.0, github.com/odoo/odoo/blob/20.0/odoo/release.py. Consultada el 17 de octubre de 2026.
Odoo S.A., «odoo/addons/base/models/ir_access.py», repositorio público odoo/odoo, rama 20.0, github.com/odoo/odoo/blob/20.0/odoo/addons/base/models/ir_access.py. Consultada el 17 de octubre de 2026.
Odoo S.A., «AI», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/applications/productivity/ai.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «AI MCP server», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/applications/productivity/ai/mcp_server.html. Consultada el 17 de octubre de 2026.
Odoo S.A., «Odoo Enterprise Subscription Agreement, versión 13 (24 de septiembre de 2026)», documentación oficial de Odoo 20.0, odoo.com/documentation/20.0/es_419/legal/terms/enterprise.html. Consultada el 17 de octubre de 2026.