Migrar de Odoo 18 a 19: plan realista para tu pyme (2026)

Por la redacción de Elige Software · Actualizado el 7 de julio de 2026 · Lectura: 12 min

La semana pasada hablé con Marta, directora financiera de una distribuidora de material eléctrico en Zaragoza. Su partner les había vendido el salto de Odoo 18 a Odoo 19 como un trámite de fin de semana. El lunes siguiente nadie podía confirmar pedidos, el conector con el banco devolvía errores y estuvieron 9 días facturando desde una hoja de cálculo. ¿El origen de todo? Nadie había probado los tres módulos a medida sobre una copia real antes del corte.

El caso de Marta no es raro. Es el patrón que se repite cuando una migración se plantea como un evento técnico de un sábado en vez de como un proyecto con fases. En esta guía te doy justo lo contrario: una checklist previa de 6 semanas, un guion hora a hora para el fin de semana del cambio y un plan de validación para los 30 días posteriores. Y algo que casi ninguna guía incluye: los escenarios en los que lo sensato es no migrar todavía.

Va dirigida a pymes españolas, así que hablaremos de Verifactu, de la AEAT y de tarifas de partner en euros. Guárdatela: la vas a necesitar más de una vez durante el proyecto.

Lo que de verdad cambia al pasar a Odoo 19

Primero, el contexto. Odoo 19 se presentó en el Odoo Experience de octubre de 2025 en Bruselas. Desde entonces conviven tres versiones con soporte oficial: la 17, la 18 y la 19. Cada versión mayor recibe unos 3 años de parches, así que quien sigue en la 18 tiene cobertura hasta finales de 2027. Hay margen. Pero el margen engaña: las agendas de los buenos partners se llenan meses antes de que expire el soporte, y Odoo 20 asoma para octubre de 2026.

¿Qué gana una pyme con la 19? Depende de dónde te duela. Las novedades más citadas van por el lado de la IA integrada en flujos de trabajo, mejoras de rendimiento y retoques profundos en la interfaz. Para una empresa española, lo relevante suele ser más prosaico: la localización l10n_es y los módulos de la AEAT siguen evolucionando con cada versión, y las versiones viejas dejan de recibir esas adaptaciones normativas cuando el fabricante pasa página.

¿Y qué se rompe? La interfaz de Odoo se construye sobre un framework JavaScript propio que cambia entre versiones, así que los widgets y vistas hechos a medida son los primeros sospechosos. Le siguen los campos que el fabricante renombra sin hacer ruido, las plantillas de documento retocadas con XPath y cualquier módulo comunitario que aún no tenga versión 19. Lo estándar migra bien. Lo tuyo, lo que os hicieron a medida hace tres años, es lo que hay que vigilar.

Tres rutas según tu edición: Enterprise, Odoo.sh y Community

Antes de planificar nada, identifica tu caso. La ruta técnica cambia por completo según la edición que tengas contratada.

• Enterprise autoalojado: usas el servicio oficial de upgrade.odoo.com, que va incluido en la suscripción. El flujo tiene dos pasadas: subes un dump de tu base en modo prueba, recibes por email la copia convertida a v19, la restauras en un servidor aparte y la machacas a pruebas; cuando estás conforme, repites la petición en modo producción y haces el cambio real. Ojo: el servicio convierte la base de datos, no tu código. Los módulos propios los adaptas tú o tu partner.
• Odoo Online (SaaS): el propio Odoo programa la actualización y te ofrece antes una base de prueba en la nueva versión. Es la ruta más cómoda, pero también la que menos margen de maniobra te da con personalizaciones — de hecho, si estás en Online es porque apenas tienes.
• Odoo.sh: la plataforma crea una rama de staging, ejecuta la conversión y te enseña los errores en el log de compilación. La base la migra sola; el código de tu repositorio de addons sigue siendo problema tuyo. Ahorra infraestructura, no desarrollo.
• Community: no existe servicio del fabricante. La vía seria es OpenUpgrade, el proyecto de la OCA con scripts de migración libres para cada salto de versión. Para la 19, la planificación de la OCA apuntaba a una versión mínima utilizable unos 3 meses después del lanzamiento, y a estas alturas de 2026 los lotes principales (base, contabilidad, ventas, stock, compras) están rodados. Contrapartida: lo ejecutas tú, lo depuras tú.

¿Un consejo transversal? Sea cual sea tu ruta, el proceso de fondo es idéntico: convertir una copia, romperla a pruebas, arreglar, repetir, y solo entonces tocar producción. Las tres rutas fallan igual de estrepitosamente si te saltas los ensayos.

Cuándo NO migrar todavía

Hablemos claro: hay proyectos de migración que nacen muertos porque se lanzan en el momento equivocado. Antes de comprometer una fecha, repasa esta lista. Si marcas alguna casilla, aplaza.

• Un módulo crítico sin versión 19. Si tu operativa depende de un módulo comunitario y su repositorio en GitHub no tiene rama 19.0 con actividad reciente, tienes dos opciones: pagar su porte (de 1.000 € en adelante según complejidad) o esperar. Migrar 'y ya veremos' no es una opción.
• Cierre fiscal o pico de temporada a la vista. ¿Cerráis el ejercicio en diciembre? Pues nada de cortes en noviembre-enero. ¿Vendéis el 40% del año en campaña de verano? Migrad en otoño. El sistema tiene que cambiar cuando el negocio respira, no cuando jadea.
• Sin entorno de pruebas. Si hoy no tenéis dónde restaurar una copia de producción y trastear sin miedo, ese es el proyecto previo. Montar staging cuesta unas horas y una máquina modesta; migrar sin staging cuesta lo que le costó a Marta.
• El equipo no da más de sí este trimestre. Una migración exige a tus usuarios clave dedicar horas a probar. Si contabilidad está desbordada y almacén va corto de gente, las pruebas se harán mal y los errores aflorarán en producción.
• Acabáis de estabilizar algo gordo. ¿Verifactu recién certificado, un conector nuevo con el banco, una integración de ecommerce de hace un mes? Dejad que asiente. Encadenar dos cambios estructurales multiplica las variables cuando algo falle.

Aplazar con criterio no es procrastinar. Eso sí: aplazar sin fecha nueva, sí lo es. Si decides esperar, deja apuntado el trimestre objetivo y el motivo concreto que tiene que resolverse antes.

La checklist previa: cuenta atrás de 6 semanas

Aquí viene el corazón de la guía. Seis semanas es el mínimo razonable para una pyme con instalación mayormente estándar; con una docena de módulos propios, estira cada fase. La estructura es una cuenta atrás hacia el fin de semana del corte.

1. Semana -6 — Fotografía completa del sistema: sacad la lista de módulos instalados, los desarrollos propios del directorio de addons, las personalizaciones hechas con Studio, los informes y plantillas retocados, las acciones programadas y todas las integraciones externas con su método de autenticación. Todo a una hoja compartida. Lo que no esté en la hoja, no existirá para el proyecto — y os morderá después.
2. Semana -5 — Ruta, dependencias y presupuesto: decidid la vía (upgrade.odoo.com, Odoo.sh u OpenUpgrade), verificad módulo a módulo que existe versión 19 de cada dependencia comunitaria, y cerrad presupuesto con el partner si lo hay. Pedid el desglose en jornadas por tarea, no una cifra global.
3. Semana -4 — Staging y primer ensayo: montad un servidor de pruebas que replique producción (misma versión de PostgreSQL, mismo sistema) y lanzad la primera conversión sobre una copia fresca. Va a fallar cosas. Perfecto: para eso está. Recopilad cada error en la hoja del proyecto.
4. Semana -3 — Adaptar el código propio: es la fase que más se infraestima. Cada widget JavaScript, cada herencia de modelo, cada plantilla XPath del inventario se revisa contra v19. Regla práctica: medio día por personalización sencilla, varios días por las que tocan interfaz.
5. Semana -2 — Segundo ensayo y pruebas de usuario: nueva conversión sobre copia fresca, esta vez buscando la pasada limpia. Encima de esa base, los usuarios clave recorren sus flujos reales: un ciclo de venta completo, uno de compra, movimientos de almacén, una remesa bancaria, envíos de prueba a la AEAT. Cada incidencia, a la hoja, con captura.
6. Semana -1 — Congelar y comunicar: se acabaron los cambios de configuración y los desarrollos nuevos en producción. Avisad a toda la plantilla del horario de parada, a la gestoría de la ventana de migración y a los proveedores de integraciones (pasarela de pago, ecommerce, banca) por si hay que reprogramar sincronizaciones.

La métrica que mejor predice el éxito no es el tamaño de la base de datos ni el número de usuarios. Es cuántos ensayos completos habéis hecho sobre copias reales antes del corte. Cero ensayos: desastre casi seguro. Uno: sufriréis. Dos con la segunda pasada limpia: fin de semana tranquilo.

Presupuesto: jornadas y tarifas reales en España

¿Cuánto duele en euros? Los partners españoles de Odoo facturan entre 60 y 100 € por hora según perfil — un técnico junior en la banda baja, un arquitecto de los que quedan pocos en la alta. Traducido a jornadas: entre 500 y 800 € el día.

Con esa vara de medir, una actualización para una pyme de 10-15 usuarios con dos o tres desarrollos sencillos consume entre 10 y 15 jornadas: análisis inicial, dos conversiones de prueba, adaptación de código, acompañamiento en pruebas, corte y una semana de soporte. Es decir, entre 5.000 y 12.000 € según tarifas. Con una docena de módulos propios e integraciones, hablad de 30-50 jornadas y el rango se va a los 18.000-35.000 €.

¿Dónde se ahorra sin arriesgar? En la parte de infraestructura y ensayos, si tenéis alguien técnico en plantilla que prepare staging y ejecute las conversiones de prueba. ¿Dónde no se ahorra jamás? En las pruebas de usuario y en la adaptación del código que toca facturación. Un descuadre contable descubierto en marzo cuesta más que todas las jornadas que intentaste ahorrarte en enero.

Un matiz que mucha gente desconoce y que cambia el presupuesto: si pagas Enterprise, la conversión de la base de datos en sí no se factura — va dentro de la suscripción vía upgrade.odoo.com. Cuando un presupuesto de partner incluya una partida gorda por 'migración de base de datos' en Enterprise, preguntad exactamente qué cubre. La respuesta legítima es la adaptación de código y las pruebas; la conversión estándar ya la habéis pagado.

El fin de semana del corte, hora a hora

Llegados aquí, con dos ensayos limpios a la espalda, el fin de semana real debería ser aburrido. Este es el guion que uso, pensado para una base de tamaño pyme. Ajustad horas según vuestro volumen.

1. Viernes 17:00 — Última factura del día emitida. A partir de aquí, nadie factura hasta el lunes: el encadenamiento de registros de Verifactu no debe quedar partido entre dos sistemas.
2. Viernes 18:00 — Producción fuera para los usuarios (basta una regla de firewall). Copia de seguridad final: dump de la base, filestore y directorio de addons, guardados en una máquina distinta. Comprobad que la copia restaura de verdad antes de seguir.
3. Viernes 19:00 — Arranca la conversión: petición en modo producción a upgrade.odoo.com, o ejecución de los scripts de OpenUpgrade sobre el servidor nuevo. Para una base de pyme, contad con que la noche del viernes se va en esto.
4. Sábado 09:00 — Pruebas de humo técnicas: arranca el servicio, los usuarios de prueba entran, los registros maestros (clientes, productos, cuentas) están donde deben, el log no escupe excepciones.
5. Sábado 12:00 — Pruebas funcionales con los usuarios clave: presupuesto→pedido→albarán→factura, un ciclo de compra, una conciliación con extracto bancario importado, y los envíos de prueba contra la preproducción de la AEAT. Reimprimid una factura antigua y escanead su QR.
6. Sábado 18:00 — Primera decisión go/no-go. ¿Errores graves en facturación, contabilidad o Verifactu? Rollback: se restaura la copia del viernes, los usuarios vuelven a v18 el lunes y se reprograma. Duele el orgullo, no el negocio.
7. Domingo — Con luz verde: revisar integraciones una a una (pasarela, ecommerce, banca), reactivar las acciones programadas, repasar permisos de usuario y dejar monitorización mirando el log.
8. Lunes 08:00 — Apertura para toda la plantilla, con el técnico de guardia y un canal directo para incidencias. La vieja v18 se queda apagada pero intacta: nadie la borra todavía.

¿La decisión más difícil del fin de semana? Aceptar un rollback el sábado por la tarde. Todo el mundo quiere empujar hasta el lunes 'a ver si lo arreglamos'. Resistid: un rollback a tiempo cuesta un fin de semana; un lunes roto con la plantilla entera parada cuesta credibilidad y dinero de verdad.

Validación post-migración: los primeros 30 días

El lunes del arranque no acaba nada; empieza la fase de vigilancia. En vez de organizarla por días, a mí me funciona organizarla por áreas, con un responsable por cada una. Cada responsable firma su área cuando la da por validada.

• Facturación y Verifactu (responsable: administración): las facturas nuevas se emiten y se remiten sin rechazos, los QR de facturas antiguas siguen resolviendo, la numeración continúa sin saltos. Validar en la primera semana.
• Bancos y conciliación (administración): el primer extracto importado tras el corte concilia contra las facturas nuevas y las anteriores. Si usáis remesas SEPA, generad una y que el banco la acepte. Validar en 10 días.
• Almacén y stock (operaciones): los movimientos del día a día cuadran con los informes de existencias, y un inventario de muestra de 20-30 referencias coincide con lo físico. Validar en 2 semanas.
• Nóminas y RR. HH. (quien las lleve): el primer ciclo de nómina en v19 sale idéntico al del mes anterior en v18, céntimo a céntimo. Cualquier diferencia se investiga antes de pagar. Validar en el primer ciclo.
• Informes y cierre (dirección financiera): la prueba de fuego es el primer cierre mensual completo. Balance y cuenta de resultados se comparan contra el último cierre en v18; los envíos fiscales del periodo salen sin incidencias. Hasta que este punto no se firme, la copia de v18 no se toca.

Mantened además un registro común de incidencias durante todo el mes: fecha, quién, qué pantalla, qué error. Al final del mes, ese registro es la agenda de la reunión de cierre con el partner. Y una regla de oro que repito a todos mis clientes: la copia de seguridad de v18 se conserva hasta que el primer cierre mensual en v19 esté firmado. Ni un día menos.

Los cinco errores que más veo

Para terminar, la lista negra. Cinco patrones que aparecen una y otra vez en migraciones que salieron mal.

1. Ensayar con una base vacía. Probar la v19 con datos de demostración no demuestra nada: los problemas viven en tus datos reales, en ese cliente con 40.000 apuntes y en aquel producto con variantes raras de 2019. Copia de producción o nada.
2. Seguir desarrollando durante el proyecto. Si producción cambia mientras adaptas el código, cada ensayo prueba un sistema distinto. Congelad los cambios desde la semana -1 como mínimo, y avisad al equipo de que las peticiones de mejora esperan al mes siguiente.
3. Desmontar el servidor antiguo la primera semana. La tentación de liberar la máquina es fuerte y el riesgo, absurdo. El coste de mantener v18 apagada un mes es cero comparado con necesitarla y no tenerla.
4. No avisar a la gestoría. Si tu asesoría presenta impuestos con datos que salen de Odoo, tiene que saber cuándo migras y esperar a que valides los envíos fiscales. Un modelo presentado con datos de una base a medio validar es un problema con Hacienda, no con tu ERP.
5. Confundir la conversión con el proyecto. La conversión de la base son horas; el proyecto son semanas. Quien presupuesta y planifica solo la primera acaba facturando en hoja de cálculo, como Marta. El proyecto entero es: inventario, dependencias, ensayos, adaptación, pruebas, corte y un mes de vigilancia.

En resumen

Migrar de Odoo 18 a 19 no es difícil; es laborioso, que es distinto. La receta cabe en cuatro líneas: seis semanas de preparación con dos ensayos sobre copia real, un fin de semana de corte con criterios de rollback pactados de antemano, un mes de validación por áreas con la copia antigua intacta, y la honestidad de aplazar si algún requisito — módulos portados, staging, capacidad del equipo — no está listo.

En 2026 el momento acompaña: la 19 lleva meses rodada, las herramientas comunitarias están maduras y los partners aún tienen hueco antes del ciclo de Odoo 20. Si estás en la 18, planifica el salto para este año con calma en vez de correr en 2027 con el soporte expirando. Y si algo de la lista de 'cuándo no migrar' te ha sonado demasiado familiar, ya sabes cuál es tu verdadero primer paso.