Migrar de Odoo 17 o 18 a Odoo 20 sigue un proceso de cinco pasos: pedir una base de prueba actualizada en upgrade.odoo.com, portear los módulos personalizados en paralelo, validar datos y flujos críticos en esa base de prueba, definir una ventana de cutover y tener un plan de rollback por si algo falla. El servicio de upgrade salta directo a la versión de destino: no hace falta pasar por 18 o 19 como pasos intermedios.
Por qué conviene migrar con un partner: los cinco pasos de esta guía son el camino oficial, pero ejecutarlos bien depende de la experiencia con el código y los datos concretos de tu empresa: portear módulos personalizados sin introducir regresiones, diseñar casos de prueba que cubran tus flujos críticos, y definir una ventana de corte con downtime acotado y un plan de rollback claro son las partes donde más ayuda un partner que ya pasó por este proceso. En Syloper somos partners oficiales de Odoo y acompañamos migraciones evaluando módulos personalizados, integraciones y localización argentina (AFIP/ARCA) antes de tocar producción.
Paso 1: pedir la base de prueba en upgrade.odoo.com
El primer movimiento es siempre solicitar una base de datos de prueba actualizada a través del portal oficial upgrade.odoo.com, nunca migrar directo la base productiva. Esa base de prueba es una copia con la estructura y los datos ya llevados a Odoo 20, que sirve para validar todo antes de tocar producción. Según la documentación oficial, cada vez que se sube un commit a la rama de módulos personalizados, la plataforma restaura la base actualizada y aplica esos módulos de nuevo, para poder probar sobre una copia limpia en cada iteración.
Paso 2: portar los módulos personalizados
En paralelo a la solicitud de la base de prueba, el código de cada módulo a medida tiene que actualizarse a la versión de destino. La secuencia que recomienda Odoo:
- Congelar el desarrollo sobre la versión vieja (dejar de sumar features nuevas mientras se migra).
- Hacer que cada módulo instale limpio en una base vacía de la versión de destino (sin datos, solo para validar que el código compila y se instala).
- Hacer que instale también sobre la base de prueba ya actualizada (con los datos reales migrados).
- Probar exhaustivamente con un ensayo general (rehearsal) antes de definir fecha de corte.
Esta parte es la que define el timeline real: la migración de datos estándar la resuelve la plataforma de Odoo, pero el porting de módulos propios depende de cuánto código a medida tengas y de qué tan alejado esté de las APIs actuales del framework. Portear un módulo sin documentación ni tests, apoyándose solo en quien lo escribió originalmente, es la parte del proceso donde más conviene sumar a alguien que ya pasó por esto antes: evita romper funcionalidad que nadie del equipo recuerda cómo probar.
Paso 3: validar datos y flujos críticos
Con la base de prueba funcionando y los módulos instalados, el trabajo pasa a validación funcional. Como mínimo:
- Cerrar un ciclo contable completo de prueba (facturación, conciliación, reportes de IVA) para confirmar que la localización argentina sigue funcionando como espera el equipo contable.
- Emitir facturas electrónicas de prueba contra los servicios de ARCA/AFIP desde
l10n_ar_edi, si tu operación factura electrónicamente. - Correr los procesos de stock/ventas de punta a punta (pedido → entrega → facturación) con usuarios reales, no solo con el equipo técnico.
- Confirmar que las integraciones externas (pagos, e-commerce, BI) responden igual contra la base actualizada.
Si algo falla acá, se corrige en la base de prueba y se repite el ciclo — para eso existe el ensayo general antes de fijar fecha de cutover. La emisión de comprobantes contra ARCA/AFIP conviene validarla con alguien que conozca la localización argentina en detalle: un error ahí no se nota en la base de prueba, se nota en producción con un cliente esperando la factura.
Paso 4: cutover a producción
Una vez validado todo, se define una ventana de corte: normalmente fuera de horario pico y lejos de cierres contables o temporada alta de ventas. El cutover implica solicitar la actualización final de la base productiva, aplicar ahí los mismos módulos ya probados en la base de prueba, y frenar el acceso de usuarios a la base vieja apenas arranca el proceso, para que no se generen datos nuevos que después falten en la base migrada.
Comunicar la ventana de corte al equipo con anticipación (y tener a alguien de soporte disponible las primeras horas post-migración) evita que el primer problema real del día se resuelva «en el momento» sin plan. Acotar el downtime real (no solo estimarlo) es más preciso cuando ya se migraron bases con un volumen de datos y personalizaciones similar al tuyo.
Paso 5: plan de rollback
Antes del cutover, hay que tener claro qué pasa si algo sale mal: en la práctica, eso significa conservar la base vieja intacta y sin uso durante la ventana de corte, para poder volver a apuntar la operación ahí si se detecta un problema bloqueante en las primeras horas. Cuanto más se haya validado en el Paso 3, menos probable es necesitar este plan — pero tenerlo escrito de antemano (quién decide el rollback, con qué criterio, en qué plazo) es lo que separa un incidente controlado de un apagón de varios días. Esa conversación conviene tenerla antes del cutover con el equipo (interno o externo) que va a estar de guardia esa noche, no improvisarla después del incidente.
Community vs Enterprise: dos caminos distintos
El proceso de los cinco pasos anteriores describe el camino oficial de Odoo (Enterprise/Odoo Online/Odoo.sh) a través de upgrade.odoo.com. En Odoo Community, ese servicio de actualización oficial no está disponible de la misma forma: la migración corre por cuenta del equipo interno o de un partner, apoyándose en herramientas de la comunidad como OpenUpgrade, mantenida por la Odoo Community Association (OCA), no por Odoo S.A. OpenUpgrade da scripts de migración entre versiones mayores, pero el trabajo de portear módulos propios y validar datos sigue siendo responsabilidad de quien migra.
En Enterprise con soporte estándar vigente, la actualización de la base de datos estándar está incluida sin costo en los planes pagos; lo que se cobra aparte (generalmente vía un partner) es la adaptación de módulos personalizados y la limpieza de datos.
Un factor más a tener en cuenta según cómo esté alojado Odoo: Odoo Online recibe versiones intermedias («rolling releases») cada dos o tres meses y fuerza la actualización de major version pasado un plazo tras cada release; Odoo.sh y on-premise se quedan en una versión mayor estable y la actualización se dispara manualmente cuando la empresa decide migrar, sin versiones intermedias forzadas.
Si todavía estás evaluando si conviene dar el salto (más allá de cómo hacerlo técnicamente), repasá ¿Conviene migrar a Odoo 20? Ventajas, riesgos y cuándo hacerlo. Y para ver qué cambia funcionalmente entre las versiones antes de definir el alcance del porting, la comparación completa está en Odoo 20 vs 19 vs 18 vs 17: qué cambia en cada versión.
Preguntas frecuentes
¿Puedo migrar directo de Odoo 17 a Odoo 20 sin pasar por 18 y 19?
Sí. El servicio de upgrade de Odoo lleva la base directo a la versión de destino que elijas. Lo que hay que planificar es que los módulos personalizados sean compatibles con la versión final, no con cada versión intermedia.
¿Qué pasa con mis módulos a medida durante la migración?
Tienen que actualizarse aparte, en paralelo a la solicitud de la base de prueba: primero instalando limpio en una base vacía de la versión destino, después sobre la base de prueba con datos reales, y validando todo con un ensayo general antes del cutover.
¿Cómo se prueba la facturación electrónica AFIP/ARCA antes de migrar en serio?
Emitiendo comprobantes de prueba contra el módulo l10n_ar_edi en la base de prueba actualizada, antes del cutover a producción, y comparando el resultado contra lo que emitía la base vieja para el mismo caso.
¿Existe un plazo típico para migrar de Odoo 17/18 a Odoo 20?
Odoo no publica un plazo estándar porque depende directamente del volumen de módulos personalizados e integraciones de cada empresa. El proceso en sí (los cinco pasos de esta guía) es el mismo para una base chica que para una compleja; lo que cambia es cuánto tiempo insume el porting y la validación.
¿Qué pasa si algo falla el día del cutover?
Por eso el Paso 5 es tener un plan de rollback definido de antemano: la base vieja se mantiene intacta durante la ventana de corte para poder volver a operar ahí si aparece un problema bloqueante en las primeras horas.
Fuentes
- Odoo — Upgrade (documentación oficial)
- Odoo — Upgrade a customized database
- OpenUpgrade (OCA) — herramienta de migración para Community
- Odoo — Pricing (actualizaciones incluidas en planes pagos)
- Odoo — Localización fiscal Argentina (l10n_ar, ARCA)
¿Vas a migrar y querés acompañamiento en el proceso?
En Syloper somos partners oficiales de Odoo. Implementamos y migramos con localización argentina (AFIP/ARCA) — conocé nuestra implementación de Odoo ERP o SyloStart, el paquete cerrado para pymes. Si todavía querés repasar el roadmap completo de la versión antes de migrar, está en Odoo 20: novedades, roadmap y qué cambia para tu empresa.