En los últimos doce meses hicimos cinco migraciones a Odoo 18 sin caídas significativas. Estas son las decisiones que importaron — y las que pensábamos que iban a importar, pero no.
Cuando salió Odoo 18 LTS a finales de 2024, varios clientes nos preguntaron lo mismo: ¿podemos migrar sin parar la operación? La respuesta corta es sí. La respuesta larga es lo que cuenta este artículo. Hay cosas que cambiaron desde la versión 17 — algunas obvias, otras que solo aparecen cuando ya está corriendo en producción y toca explicar por qué un reporte ya no compila.
El objetivo aquí no es venderle Odoo. Es contarle qué encontramos en campo, qué decisiones tomamos cuando había que tomarlas en 30 minutos y qué haríamos distinto si volviéramos a empezar.
Por qué Odoo 18 no es como las anteriores
Las migraciones entre versiones de Odoo son una constante. Cada año o año y medio sale una nueva, y cada año vemos los mismos errores con nombres distintos. La 18 trae cambios de fondo — particularmente en el ORM y en cómo se manejan las restricciones en fields.Many2one con ondelete — que rompen módulos comunitarios que llevaban tres versiones funcionando.
Lo que cambia respecto a la 17 (lo importante, no todo):
- Nuevo motor de vistas. Las vistas list y kanban se redibujan con OWL 2 — si tiene widgets viejos, prepárese.
- Cambios en accounting. La localización colombiana se reorganizó. Auditorías DIAN funcionan, pero los reportes a la medida hay que revisarlos.
- Performance. PostgreSQL 14+ obligatorio. Si está en 12, primero migra Postgres, después Odoo.
- API REST nativa. Una de las novedades buenas — antes había que envolver el XML-RPC.
El error más común — y cómo evitarlo
El error que vimos repetido en clientes que migraron solos: migrar primero, validar después. Se levanta una instancia 18, se importa la base de la 17, se prueba que “funciona” — abriendo dos pantallas — y se programa go-live para el lunes.
El problema es que el 80% de los datos que importan en un ERP son datos derivados. Saldos, asientos automáticos, agrupaciones, reportes. Si lo único que validó es que se puede abrir una factura, no validó nada.
Una migración no se valida abriendo pantallas — se valida cuadrando saldos, re-emitiendo reportes y comparando contra el sistema anterior.
Lo que hacemos nosotros, desde hace dos años:
- Migración en paralelo. La 17 sigue siendo el sistema de verdad hasta que la 18 demuestre que cuadra.
- Reportes espejo. Generamos los mismos 6–10 reportes clave en ambas versiones y los comparamos línea por línea.
- Una semana de “paralelo silencioso”. La 18 corre con datos reales, sin usuarios, durante una semana — solo para detectar lo que pasa al día 3, día 5, día 7.
- Go-live por módulos. Cuando es posible, no se enciende todo el mismo día.
El go-live de viernes (todavía mala idea)
En 2026 esto todavía es polémico — increíblemente. Hay equipos que arrancan en producción el viernes a las 6 p.m. para “tener el fin de semana de margen”. Lo que tienen es un fin de semana sin equipo, sin proveedores disponibles, y con un problema que aparece a las 11 de la noche del sábado.
Nuestra recomendación, sin matices: go-live un martes a las 7 a.m. Equipo completo presente. Soporte de Odoo disponible. Si algo se rompe, hay 4 días hábiles para resolver antes del fin de semana — no después.
Checklist final
Si está pensando migrar a la 18 en los próximos seis meses, esta es la versión corta de todo lo anterior.
- Auditoría de módulos comunitarios — saber cuáles sobreviven.
- Limpieza de datos maestros antes, no después.
- PostgreSQL 14+ antes de tocar Odoo.
- Migración en paralelo, no en cascada.
- Reportes espejo para 6–10 indicadores clave.
- Semana de paralelo silencioso con datos reales.
- Capacitación específica a los cambios de UI.
- Go-live entre martes y jueves. Nunca viernes.
Si tiene una migración planeada y quiere conversarla — o ya está en una y algo no está saliendo — escríbanos. Lo peor que puede pasar es que ahorre un sábado.