Errores comunes al migrar a Odoo 19
Migrar de Odoo 17 o 18 a la 19 no es pulsar un botón. Aquí tienes los fallos que de verdad aparecen — APIs eliminadas, módulos a medida rotos, integridad de datos y cambios de vistas — con el mensaje de error y cómo resolverlo.
Antes de empezar: la regla que rompe casi todas las migraciones
Odoo no soporta saltos de versión. La migración es secuencial:
de la 17 a la 18, y de la 18 a la 19. Tanto el servicio oficial de
upgrade.odoo.com como
OpenUpgrade (la herramienta libre de la OCA) trabajan paso a paso.
Si cargas un dump de la 17 sobre un servidor 19 y lanzas -u all,
los módulos quedan en estado to upgrade sin migrar y los datos se corrompen.
La segunda regla: siempre sobre una copia. Restaura el backup en una base de pruebas, migra ahí, valida, y solo entonces planifica la real. Una migración de prueba es además la única forma honesta de estimar el esfuerzo de tu código a medida.
1. APIs y atributos eliminados
Es el error número uno. Los atributos attrs="{...}" y
states="..." se eliminaron en Odoo 17 y la 19 ya no tolera
ningún resto. Cualquier vista heredada que aún los use revienta al cargar el módulo.
ParseError: Since 17.0, the "attrs" and "states" attributes are no longer used.
Solución: reemplaza por atributos directos
invisible, readonly y required con expresiones
Python: invisible="state != 'draft'" en lugar de
attrs="{'invisible': [('state','!=','draft')]}".
Métodos que llevaban años deprecados se eliminan en cada versión mayor. Lo típico:
name_get() (sustituido por _compute_display_name),
fields_view_get() (ahora get_view()), y firmas de
_default_get o de los onchange que cambian.
AttributeError: 'res.partner' object has no attribute 'name_get'
Solución: revisa los release notes y el commit de deprecaciones de cada versión. OpenUpgrade documenta los cambios de modelo en su carpeta de scripts, pero el código propio que llama a esos métodos lo tienes que adaptar a mano: no hay automatismo que lo haga.
Desde Odoo 17 el frontend es OWL puro y el sistema de assets usa importación
de módulos JS (/** @odoo-module **/) en lugar de
odoo.define. Un widget viejo que aún use el patrón antiguo o llame a
require('web.core') deja de cargar y la vista se queda en blanco.
UncaughtPromiseError: Failed to load resource / Cannot read properties of undefined
Solución: reescribir el componente con la API de OWL,
declarar los assets en web.assets_backend del manifest y eliminar
cualquier odoo.define. Es de lo más costoso de migrar si tienes
mucha UI a medida.
2. Módulos a medida y de terceros que no instalan
Si tu módulo declara en el manifest un depends sobre un addon de la OCA
(por ejemplo queue_job, web_responsive o algún
account_*) que todavía no tiene rama 19.0 publicada, la instalación se
para en seco. La 19 es reciente y muchos repos OCA tardan meses en portarse.
odoo.exceptions.ValidationError: Unable to install module "X" because an external dependency is not met
Solución: antes de migrar, haz inventario de todos tus
depends y comprueba en GitHub si existe la rama 19.0. Si no existe,
tienes tres opciones: esperar al port, portarlo tú (y contribuirlo), o quitar la
dependencia. Esto es lo que más sorprende a quien viene de Enterprise estándar.
Olvidar subir la clave version del manifest a 19.0.x.y.z hace
que Odoo crea que el módulo no ha cambiado y no ejecute los scripts de migración.
El módulo "instala" pero los datos quedan a medio actualizar, lo que es más peligroso
que un error visible.
Solución: empieza el número de versión del módulo por la versión de
Odoo (19.0.1.0.0), incrementa el sufijo en cada cambio que lleve script
de migración, y verifica en los logs que aparece Loading migration script.
3. Integridad de datos
Los problemas de datos son los más silenciosos y los que más dolor causan en producción. Aparecen cuando la base "vieja" tiene registros que la 19 ya no permite, o cuando un campo cambia de tipo o de obligatoriedad entre versiones.
- Restricciones NOT NULL nuevas: un campo que en la 17 era opcional
y en la 19 es obligatorio rompe la migración si hay filas con ese valor a NULL.
El log muestra
psycopg2.errors.NotNullViolation: null value in column "...". Hay que rellenar esos registros antes de migrar. - Foreign keys huérfanas: referencias a registros borrados que la
nueva versión valida con
ON DELETEmás estricto. DanForeignKeyViolational recalcular almacenados. - Campos almacenados que se recalculan: los
computeconstore=Truese recalculan en masa al migrar; si la fórmula cambió, los importes de facturas o el stock pueden moverse. Compara totales antes y después. - Datos duplicados que ahora violan un unique: nuevos índices únicos (por ejemplo en referencias de producto) fallan si arrastras duplicados.
Cómo evitarlo: limpia los datos en la versión origen (no en la migrada), y tras cada salto valida con consultas de control: número de asientos contables, suma de haber y debe, total de pedidos abiertos, valoración de stock. Si un número no cuadra, no sigas hasta entender por qué.
4. Cambios de vistas e interfaz
Aunque el módulo instale, la interfaz puede quedar rota porque la estructura de las vistas estándar cambió y tus herencias ya no encuentran el nodo que buscan con XPath.
Element '<xpath expr="//field[@name='...']">' cannot be located in parent view
Solución: el campo se movió, se renombró o el formulario se reorganizó. Abre la vista estándar de la 19, localiza el nuevo nodo y ajusta el XPath. Usar selectores frágiles (posición exacta) es lo que provoca estos fallos; conviene anclar a nombres de campo estables.
- La etiqueta
<tree>pasó a llamarse<list>en la 17/18; las vistas de lista heredadas con el nombre antiguo pueden dar avisos o no aplicar. - Cambios en la barra de estado (statusbar) y en los botones de cabecera que rompen herencias que insertaban botones por posición.
- El nuevo diseño visual de Odoo 19 puede descolocar widgets a medida que asumían anchos o clases CSS antiguas.
¿OpenUpgrade o el servicio oficial de Odoo?
No hay una respuesta única. Esto es lo honesto sobre cada camino, incluida la opción gratuita de la OCA:
| Criterio | upgrade.odoo.com (oficial) | OpenUpgrade (OCA, libre) |
|---|---|---|
| Coste | Incluido con Enterprise / Odoo.sh; de pago para Community sin contrato. | Gratis y de código abierto (AGPL/LGPL según repo). |
| Datos estándar | Muy fiable, automatizado, soportado por Odoo. | Fiable, pero corres tú el servidor y el proceso. |
| Módulos a medida | No los migra: te avisa que los adaptes tú. | Tampoco: hay que escribir scripts de migración propios. |
| Control y trazabilidad | Caja parcialmente cerrada; recibes el resultado. | Control total: ves cada script que se ejecuta. |
| Disponibilidad para 19.0 | Disponible para versiones soportadas. | Depende de que la rama 19.0 esté madura; revísala antes. |
En ambos casos el grueso del trabajo (y del coste real) está en adaptar tu código propio y validar los datos, no en correr la herramienta. Cualquiera que prometa una migración "automática" de una instalación con módulos a medida no está siendo honesto.
Checklist mínimo antes de migrar a Odoo 19
- Inventario de todos los módulos (estándar, OCA, a medida) y de sus
depends. - Comprobar qué dependencias OCA ya tienen rama 19.0 y cuáles no.
- Migración de prueba sobre una copia, salto a salto (17→18→19), nunca directa.
- Búsqueda y reemplazo de
attrs,states,name_getyodoo.defineen el código propio. - Limpieza de datos en origen: NULLs en futuros campos obligatorios, duplicados, FKs huérfanas.
- Consultas de control de totales (contabilidad, stock, pedidos) antes y después.
- Plan de marcha atrás: backup verificado y restaurable antes de tocar producción.
Migración a Odoo 19 hecha por ingenieros
En FlexigoTech (Barcelona) hacemos la migración salto a salto, adaptamos tus módulos a medida y validamos la integridad de los datos. Sin intermediarios y con un presupuesto basado en una migración de prueba real, no en una promesa.
Ver servicio de migración y desarrollo a medidaFAQ
¿Se puede saltar de Odoo 17 a 19 directamente?
No de forma soportada. La migración es secuencial: 17 → 18 → 19. Cargar un dump de la 17 sobre la 19 deja módulos en estado "to upgrade" que nunca se actualizan y rompe la integridad de datos. Hay que encadenar cada salto y validar entre uno y otro.
¿Por qué mi módulo a medida ya no instala?
Lo habitual: atributos de vista eliminados (attrs/states), métodos del ORM retirados (name_get), assets JS antiguos (odoo.define en vez de OWL) y dependencias OCA sin rama 19.0. Suele fallar con ParseError, KeyError o un ValidationError de dependencia externa.
¿OpenUpgrade o el servicio oficial de Odoo?
Si estás en Online/Odoo.sh con módulos estándar, el upgrade oficial es lo más cómodo y soportado. Si tienes Community self-hosted o código a medida, OpenUpgrade de la OCA es libre y gratuito pero exige escribir tus scripts. Ninguno migra tu lógica custom automáticamente.
¿Cuánto tarda y cuánto cuesta?
Depende del número de módulos a medida y de lo limpios que estén los datos. Una base estándar se migra en días; una con muchos addons custom puede llevar semanas. El coste está en revisar y reescribir tu código propio. Lo honesto es hacer primero una migración de prueba para estimar.