Estás en una versión de Odoo de hace años, funciona a medias y tienes miedo de tocarla. Te suena. El miedo no es infundado: una actualización mal hecha te puede romper el custom y dejarte una semana a ciegas. Pero quedarse quieto tampoco es gratis. La buena noticia es que la base estándar de Odoo migra bien. El riesgo real está en otro sitio, y en este artículo te contamos dónde, cómo se hace una actualización de verdad por fases y por qué a veces la mejor versión no es la última.
Por qué actualizar Odoo (y por qué no quedarse en una versión vieja)
Empecemos por lo honesto: si tu Odoo funciona y factura, entendemos la tentación de no tocarlo. "Si no está roto, no lo arregles." El problema es que en software esa frase caduca. Una versión vieja no está rota hoy, pero cada mes que pasa acumula deuda que un día se cobra de golpe.
Hay cuatro motivos serios para actualizar, y ninguno es "para tener lo último":
- Soporte de versión: Odoo mantiene oficialmente las tres últimas versiones mayores. Si tu versión se cae de ese ciclo, dejas de recibir parches y correcciones. Estás solo.
- Seguridad: las versiones sin soporte no reciben parches de vulnerabilidades. Un ERP con datos de clientes, facturación y nóminas es un objetivo, y correr sobre una versión abandonada es dejar la puerta abierta.
- Funcionalidades: cada versión trae mejoras reales que resuelven cosas que hoy haces a mano o con un módulo apañado. A veces la personalización que pagaste hace tres años ya viene de serie.
- Cumplimiento normativo: aquí está el que aprieta de verdad. VeriFactu (facturación certificada para la AEAT, obligatoria a partir de 2027 con la Ley Antifraude) o el registro de jornada laboral no se implementan bien sobre versiones antiguas. La normativa cambia y tu ERP tiene que ir con ella.
¿Y el riesgo de quedarse quieto? Que la actualización que hoy es un salto manejable se convierta en un salto imposible. Cuanto más te alejas de la versión soportada, más caro y más arriesgado es volver. La deuda técnica no se paga sola: se acumula con intereses.
El riesgo real no es el dato. Es lo custom
Aquí desmontamos el miedo más extendido: "voy a perder mis datos". La verdad es que la base estándar de Odoo migra bien. El servicio oficial de Odoo Upgrade está pensado precisamente para eso: coge tu base de datos, la transforma a la estructura de la nueva versión y te la devuelve con clientes, facturas, asientos y stock intactos. El dato de serie no es el problema.
El problema es todo lo que no es estándar. Y en un Odoo con años encima, eso suele ser mucho más de lo que crees:
- Módulos a medida: ese desarrollo que os hicieron para vuestro proceso concreto. Está escrito contra una versión de la API de Odoo, y esa API cambia de una versión a otra. Si no se adapta, casca.
- Módulos de terceros: los que instalaste desde el Odoo Apps Store o de otro proveedor. Tienen que existir para la versión nueva y ser compatibles. Si el autor no los ha actualizado, te quedas colgado.
- Personalización acumulada: campos añadidos, vistas modificadas, automatismos, informes a medida, reglas de flujo. Cada capa que alguien tocó a lo largo de los años es una capa que hay que revisar.
Por eso una actualización no es "darle a un botón". El botón migra la base. Lo que cuesta trabajo, y donde está el 80% del esfuerzo real, es adaptar y probar todo lo custom para que siga funcionando en la versión nueva. Quien te venda una actualización sin mirar tu custom, te está vendiendo humo.
| Qué tienes en Odoo | ¿Migra solo? | Nota |
| Datos estándar (clientes, facturas, asientos, stock) | Sí | El servicio oficial de Odoo Upgrade lo transforma a la nueva versión |
| Configuración estándar (plan contable, impuestos, flujos base) | Sí | Se traslada con la base; conviene validar tras la migración |
| Módulos a medida | No | Hay que adaptar el código a la nueva API de Odoo |
| Módulos de terceros | Depende | Solo si el autor publicó versión compatible; si no, se reemplaza o se rehace |
| Campos, vistas e informes personalizados | No siempre | Se revisan uno a uno; algunos ya vienen de serie en la versión nueva |
| Integraciones (web, TPV, API externas) | No | Se prueban aparte porque dependen de conectores propios |
El proceso correcto, fase por fase
Una actualización que sale bien no es la que va rápida, es la que va ordenada. Estas son las cinco fases que seguimos y que separan una actualización tranquila de un desastre en producción.
1 · Auditoría de la instalación actual
Lo primero es saber qué tienes de verdad. Versión exacta de partida, listado completo de módulos custom, módulos de terceros y de dónde salen, integraciones activas (web, TPV, pasarelas, API externas) y qué personalización se ha ido acumulando. Sin este inventario vas a ciegas. Aquí también se decide a qué versión destino tiene sentido saltar, que no siempre es la última.
2 · Backup completo y entorno de staging
Copia de seguridad íntegra: base de datos Y filestore (los adjuntos, imágenes y documentos viven fuera de la base, y si te olvidas del filestore la copia no sirve). Y una regla que no se negocia: la actualización se prueba en un entorno de staging, una réplica separada. Nunca, jamás, se prueba en producción. Producción sigue trabajando mientras tanto.
3 · Migración de la base y adaptación del custom
Se migra la base de datos con el servicio oficial de Odoo Upgrade (o con OpenUpgrade y sus scripts en instalaciones Community). Y en paralelo, la parte que de verdad cuesta: adaptar los módulos a medida a la nueva API, revisar los de terceros y rehacer o sustituir lo que se haya quedado sin soporte. Todo esto sobre el staging.
4 · Pruebas funcionales con usuarios clave
No basta con que Odoo arranque. Hay que probar los procesos críticos con la gente que los usa cada día: facturar, vender, comprar, contabilizar, cerrar el mes. El de finanzas valida lo suyo, el de compras lo suyo. Los fallos aparecen aquí, en pruebas, que es exactamente donde deben aparecer y no en producción.
5 · Ventana de corte y go-live
El salto se hace en el momento de menos actividad: fin de mes, fin de trimestre o un fin de semana tranquilo, nunca en plena campaña. Se congela producción, se hace la migración definitiva, se arranca. Y los primeros días, soporte reforzado encima, porque siempre surgen dudas y detalles cuando todo el equipo entra a la vez.
La secuencia no se salta. Puedes ir más rápido o más lento según el tamaño del custom, pero el orden es sagrado: primero entender, luego probar en aparte, después arrancar. Saltarse una fase es donde nacen los desastres.
No es lo mismo actualizar en Online, en Odoo.sh o en on-premise
El "cómo se actualiza" depende de dónde tengas alojado tu Odoo. Y esto cambia bastante las cosas, así que conviene tenerlo claro antes de nada.
En Odoo Online (el SaaS de Odoo) el alojamiento y las actualizaciones menores las gestiona Odoo. Pero ojo: en Online no puedes instalar módulos a medida ni código propio, así que si tienes custom, Online no es tu sitio. El salto de versión mayor tiene sus reglas y sus ventanas, y lo dispara Odoo con tu visto bueno.
En Odoo.sh (la plataforma cloud pensada para proyectos con desarrollo propio) tienes control real: ramas de staging para probar la actualización, tu código versionado en Git y un flujo pensado justo para esto. Es el entorno más cómodo cuando hay custom de por medio.
En on-premise (Odoo en tu servidor o en tu proveedor) el control es total, pero la responsabilidad también: el backup, el staging, la migración y el mantenimiento los gestionas tú o tu partner. Nadie lo hace por ti. Máxima libertad, máxima responsabilidad.
| Modalidad | Custom / código propio | Quién gestiona la actualización |
| Odoo Online (SaaS) | No permitido | Odoo, dentro de sus ventanas y reglas |
| Odoo.sh (cloud desarrollo) | Sí, con Git y staging | Tú/partner, con herramientas de la plataforma |
| On-premise (servidor propio) | Sí, total | Tú o tu partner, de principio a fin |
Los errores típicos que convierten una actualización en un infierno
No hace falta inventar formas nuevas de fallar. Las de siempre bastan, y se repiten proyecto tras proyecto. Estas son las cuatro que más caro salen:
- Actualizar directo en producción: el error más grave y el más común. Si el salto va mal, y sin pruebas suele ir mal, dejas a toda la empresa sin sistema. Siempre en staging primero.
- No probar el custom: dar por hecho que los módulos a medida y de terceros van a sobrevivir al salto. No. Cada uno se prueba, y el que no funcione se adapta antes del go-live, no después.
- Saltar varias versiones sin plan: pasar de una versión muy antigua a la última de un tirón multiplica el riesgo. A veces hay que hacerlo por etapas, versión a versión, para que las herramientas de migración hagan bien su trabajo.
- No reservar tiempo para formación: entre versiones la interfaz cambia, se mueven menús, aparecen funciones nuevas. Si el equipo no sabe dónde está ahora cada cosa, va a usar Odoo mal y la culpa se la llevará el ERP, cuando el problema es que nadie les enseñó.
Todos estos fallos tienen algo en común: nacen de tratar la actualización como un trámite y no como el proyecto que es. El plan por fases existe precisamente para que estos errores no lleguen a producción.
La verdad incómoda: a veces no toca ir a la última versión
Aquí vamos a decir algo que no dirá quien solo quiere venderte horas: no siempre hay que ir a la versión más nueva. La última versión es la más brillante, sí, pero también la más reciente, con menos rodaje y a veces con módulos de terceros que aún no la soportan.
El objetivo de una actualización no es "tener lo último". Es estar en una versión soportada y estable. Muchas veces la decisión sensata es saltar a la penúltima versión, que ya tiene meses de rodaje, todos los parches y el ecosistema de módulos al día, en lugar de estrenar la recién salida y ser tú quien encuentre los fallos. Estable y con soporte gana a nueva casi siempre.
La actualización es el momento de limpiar deuda técnica
Si arrastras un custom sucio (módulos que ya no usas, parches sobre parches, desarrollos que solucionaban problemas que ya no tienes), no lo copies tal cual a la versión nueva. Aprovecha el salto para tirar lo que sobra y rehacer bien lo que se quedó regular. Migrar la basura solo te lleva la basura, más lenta y más cara, a la siguiente versión.
Cómo encaja QUBIQ en tu actualización
QUBIQ es Odoo Gold Partner desde 2019 y "Mejor Partner de Europa", con más de 15 años en implementaciones, +100 consultores en plantilla (no freelances rotativos) y +600 proyectos a la espalda. Con delegaciones en Barcelona, Madrid, Sevilla, Bilbao y Lisboa.
¿Por qué importa eso en una actualización? Porque actualizar Odoo no es darle a un botón, es un proyecto de datos y de código donde el valor está en adaptar bien el custom y en no dejar el negocio a ciegas mientras se hace. Después de +600 implementaciones, sabemos exactamente dónde saltan las alarmas: el módulo de terceros sin soporte, la fecha de corte mal elegida, el equipo sin formar en la interfaz nueva.
No somos otro partner de Odoo. Somos el que hace la actualización por fases, con staging, con el custom probado y con soporte reforzado el día del arranque. Y el que te dice con honestidad a qué versión conviene saltar, aunque no sea la última. Esa es la diferencia entre actualizar tranquilo y arrepentirte de haberlo intentado.
Preguntas frecuentes
¿Se pierden los datos al actualizar Odoo?
No, si se hace con un plan. La base de datos estándar (clientes, facturas, asientos, stock) migra bien con el servicio oficial de Odoo Upgrade, y todo se prueba antes en un entorno de staging, nunca en producción, con backup completo de la base y del filestore. El riesgo real no está en el dato estándar, sino en los módulos a medida y de terceros, que hay que adaptar y probar aparte.
¿Cuánto se tarda en actualizar Odoo?
Depende sobre todo de cuánto custom tengas. Un Odoo casi estándar se actualiza en poco tiempo; uno con muchos módulos a medida, de terceros e integraciones necesita más, porque el grueso del trabajo es adaptar y probar todo eso en staging. La migración de la base en sí es rápida; lo que lleva tiempo es dejar el custom funcionando y formar al equipo.
¿Puedo saltar varias versiones de golpe?
Técnicamente a veces sí, pero es donde más cosas se rompen. Saltar de una versión muy antigua a la última de un tirón multiplica el riesgo, sobre todo con el custom. En muchos casos conviene hacerlo por etapas, versión a versión, para que las herramientas de migración trabajen bien. La auditoría inicial es la que decide si se salta directo o por escalones.
¿Tengo que actualizar siempre a la última versión de Odoo?
No. El objetivo no es tener lo último, sino estar en una versión soportada y estable. Odoo mantiene las tres últimas versiones mayores, así que a menudo la decisión sensata es saltar a la penúltima, que ya tiene rodaje, todos los parches y el ecosistema de módulos al día, en lugar de estrenar la recién salida y encontrarte tú los fallos.
¿Se puede actualizar Odoo sin parar el negocio?
Sí. Toda la actualización se prepara y se prueba en un entorno de staging mientras producción sigue trabajando con normalidad. El único momento sensible es el corte definitivo (el go-live), que se hace en la ventana de menos actividad (fin de mes, trimestre o un fin de semana) y con soporte reforzado los primeros días. No es un apagón, es un relevo controlado.