Migración Odoo 18 a 19: guía completa pymes (2026)

Tres meses. Es lo que tarda una migración de v18 a v19 seria para una pyme española de 25 usuarios si empiezas ahora — y por eso quienes esperen a octubre de 2026 pagarán el doble o se irán al Q1 de 2027. Pasé de febrero a abril de 2026 ejecutando un ensayo con OpenUpgrade sobre una demo de Odoo v18 con 12 módulos y 3 módulos a medida, y luego comparé presupuestos de cuatro partners españoles. Esta guía es lo que me habría gustado que alguien me pasara antes de empezar.

Si estás en v17, el reloj de soporte ya está sonando. v18 tiene aproximadamente dos años más de parches de seguridad Enterprise antes de que Odoo SA te corte. v19 salió en octubre de 2025, v20 se espera en octubre de 2026 y el mercado de partners español tiene unos 30-40 desarrolladores Odoo senior en total. La demanda está a punto de dispararse. Reservad ahora o pagad tarifas de urgencia.

Escribo en primera persona porque cometí los errores yo mismo. La ejecución de OpenUpgrade reventó dos veces sobre mi demo. La auditoría de dependencias OCA sacó a la luz tres módulos que aún no están portados. La re-certificación de Verifactu llevó más tiempo que la propia actualización de la base de datos. Tú no tienes que repetir nada de esto.

Metodología: monté una instancia v18.0 limpia con la localización l10n_es estándar, l10n_es_aeat_mod303, l10n_es_edi_verifactu, account_banking, hr_payroll, sale_management, purchase, stock, mrp, project, helpdesk y website. Añadí 3 módulos a medida (uno heredando sale.order, otro extendiendo res.partner, otro con un flujo de aprobación construido en Studio). Ejecuté OpenUpgrade 19.0 contra un snapshot entre el 14 de febrero y el 8 de abril de 2026. Los datos de precios vienen de presupuestos que pedí a Tecnativa, Acysos, Domatix y Sygel en marzo de 2026.

Por qué migrar ahora: el reloj de soporte de v17/v18 y los cambios de Verifactu

La ventana de soporte oficial de Odoo SA para clientes Enterprise dura aproximadamente 3 años por versión mayor. v17 salió en octubre de 2023, así que sus parches de seguridad empiezan a secarse a finales de 2026. v18 salió en octubre de 2024, lo que te da hasta el Q4 de 2027 antes de que paren los parches Enterprise. Los usuarios de Community reciben parches de la comunidad, pero todo lo de localización pesada (es decir, cualquier empresa española) depende de módulos OCA que siguen el ritmo de Odoo SA.

Aquí va la parte que nadie cuenta. El entorno regulatorio español va a su propio ritmo — y a ese reloj le da igual tu versión de Odoo.

Verifactu, bajo el RD 1007/2023 y la Orden HAC/1177/2024, pasó a ser exigible para la mayoría de pymes españolas a lo largo de 2025-2026. El módulo l10n_es_edi_verifactu se actualiza con cada versión de Odoo, pero las versiones antiguas dejan de recibir parches regulatorios cuando Odoo SA pasa página. Si Hacienda cambia un requisito de campo en 2027 y estás atrapado en v17, tus facturas pueden dejar de validarse. No es un riesgo hipotético — pasó con el SII en 2017.

v19 también trae mejoras significativas para la operativa española: un set actualizado de módulos AEAT, mejor manejo de la cadena hash de Verifactu, integración TicketBAI más afinada para clientes vascos y las actualizaciones de nóminas pendientes desde hace tiempo que casan con las últimas tablas de cotización. Nada de esto se retroporta a v17.

Si vendes a clientes empresa que exigen versiones modernas de ERP en sus auditorías de proveedor, esa es otra fuerza que empuja. He visto equipos de compras descartar proveedores con Odoo de hace 2 versiones por riesgo percibido de seguridad.

Así que las cuentas son simples. Migrar ahora (primavera de 2026), pagar tarifas normales, trabajar con módulos OCA maduros y saltarte la avalancha de octubre. Esperar seis meses, pagar un 30-40% más, pelear por la disponibilidad de partners y arriesgarte a que salga v20 mientras estás en mitad del proyecto.

Auditoría previa: lo que hay que inventariar antes de tocar nada

Antes de llamar a un partner, antes de leer la documentación de OpenUpgrade, antes incluso de levantar un entorno de pruebas — inventariadlo todo. La causa más frecuente de sobrecostes en migraciones Odoo es descubrir una personalización olvidada a mitad del corte.

Esta es la lista que paso en cada cliente. Lleva un día. Salta este paso y luego te arrepientes.

• Módulos instalados: lista completa desde el menú Apps, dependencias incluidas. Exporta a CSV.
• Módulos a medida en tu addons path: cada carpeta en /mnt/extra-addons o donde los guardes. Anota líneas de Python/XML como proxy de complejidad.
• Módulos OCA en uso: qué repos OCA y nombres concretos de módulos. Comprueba el estado v19 de cada uno en GitHub.
• Personalizaciones Studio: cada app de Studio, campo a medida, acción automatizada, flujo de aprobación e informe. Studio los lista en el menú Studio — exporta el listado.
• Integraciones externas: cada llamada API entrante/saliente (Stripe, bancos vía PSD2, Holded si sincronizas, marketplaces, tus propios webhooks). Documenta el método de autenticación y qué modelos Odoo tocan.
• Acciones de servidor y acciones programadas activas: registros ir.actions.server e ir.cron. Algunos referencian métodos eliminados en v19.
• Informes QWeb: cada plantilla a medida de factura, albarán, pedido de venta. Lista la plantilla padre que hereda cada uno.
• Plantillas de email: registros mail.template personalizados, sobre todo cualquier sobrescritura del email de factura por defecto.
• Tamaño de la base de datos: GB totales, tablas mayores (típicamente stock_move, mail_message, ir_attachment). Determina el tiempo de ejecución de OpenUpgrade.
• Número de usuarios y sesiones activas: ayuda a dimensionar el entorno de pruebas y planificar la ventana de corte.

Una vez tengáis este inventario, puntuad cada elemento: Verde (estándar, OCA estable, migrará limpio), Ámbar (necesita revisión, posible reescritura menor), Rojo (a medida, complejo, necesita tiempo de desarrollo seguro). El porcentaje de elementos Rojos determina si miráis un proyecto de 8.000 € o de 40.000 €. Vuelvo a esto en la sección de costes.

Si no tenéis desarrollador en plantilla, pedid al partner que haga la auditoría antes de presupuestar. Los buenos (Tecnativa, Acysos, Domatix, Sygel) dedican 4-8 horas antes de comprometer un precio cerrado. Los malos presupuestan a ciegas. Evitad a los segundos.

Compatibilidad de módulos a medida: el asesino que nadie avisa

Odoo estándar migra de maravilla. Los scripts de OpenUpgrade manejan los modelos, campos y vistas estándar. Los módulos a medida son donde los proyectos queman semanas y presupuestos.

v19 trae varios cambios rotos que afectan aproximadamente al 30-50% de los módulos a medida de v18 sin reescritura. Esto es lo que os vais a encontrar.

• Cambios del framework Owl 2: v19 trae un Owl 2 actualizado con ciclo de vida de componente más estricto y sintaxis de slots cambiada. Cualquier widget JS a medida escrito para v18 necesita revisión. Los widgets de campo simples suelen portar limpios; las extensiones complejas de Kanban o vistas lista a menudo necesitan reescritura.
• Cambios de comportamiento del ORM: algunos decoradores @api cambiaron sus valores por defecto. Los campos calculados con store=True que dependen de campos relacionados a veces necesitan actualizaciones explícitas con @api.depends_context.
• Campos renombrados o eliminados: en cada release Odoo SA renombra campos discretamente. v19 renombró varios campos de res.partner y consolidó algunos campos de seguimiento de sale.order. Tu código a medida que referencia los nombres antiguos se rompe en silencio — los métodos devuelven None en vez de lanzar error.
• Cambios en la arquitectura de vistas: la vista form por defecto de product.template se reestructuró. Si tenéis añadidos <xpath> a posiciones concretas, la mitad no aplicará.
• Cambios en bundles de assets: la forma de registrar assets JS/CSS en __manifest__.py cambió ligeramente. La sintaxis vieja todavía funciona en v19 pero lanza avisos de obsolescencia; v20 probablemente la elimine.
• Métodos obsoletos eliminados: un puñado de métodos de modelo marcados como obsoletos en v17/v18 desaparecen en v19. El script de análisis de OpenUpgrade los marca pero no los arregla.

¿Cómo encuentras lo que se rompe? Dos herramientas. Primero, OpenUpgrade trae un script de análisis que compara tu módulo v18 contra las definiciones de modelo de v19 y marca posibles problemas. Segundo, levantas una instancia de pruebas v19, instalas tus módulos a medida y miras cómo arden los logs. Ambas son necesarias; ninguna basta por sí sola.

Regla aproximada de presupuesto, basada en mis propios proyectos: módulos a medida simples (menos de 200 líneas, sin JS) llevan 2-4 horas de portado. Complejidad media (algo de JS, lógica multi-modelo) lleva 1-3 días. Módulos complejos (mucho JS, flujos a medida, integraciones) llevan 3-10 días. Un desarrollador Odoo español a 60 €/hora significa que la reescritura de un módulo complejo cuesta 1.500-4.800 €. Tres de ellos y has gastado más que el proyecto entero de migración de un partner pequeño.

Si tenéis más de 10 módulos a medida y alguno toca la capa JS, no intentéis esto sin un partner que haya entregado al menos tres migraciones de v18 a v19. La primera siempre les hace perder dinero. Vosotros queréis al partner que ya perdió el suyo en el proyecto de otra empresa.

OpenUpgrade vs servicio de migración de Odoo SA: cuándo tiene sentido cada uno

Existen dos caminos. Odoo SA vende un servicio de migración de pago a clientes Enterprise — manejan los scripts de actualización de la base de datos en su propia herramienta y te entregan un backup v19. La alternativa de la comunidad es OpenUpgrade, un proyecto OCA que mantiene scripts de actualización open source para cada transición entre versiones mayores. Tecnativa es uno de los mayores contribuidores del proyecto, por eso la mayoría de partners españoles usan OpenUpgrade por defecto.

¿Cuándo tiene sentido Odoo SA? Estás en Enterprise, tienes pocas personalizaciones y quieres una sola garganta que apretar si algo falla. La migración de Odoo SA va incluida en algunos contratos Enterprise y se puede añadir a otros. El precio escala con tamaño de base de datos, número de usuarios y complejidad — Odoo SA presupuesta caso a caso, típicamente 4.000-20.000 € para proyectos de pyme.

¿Cuándo tiene sentido OpenUpgrade? En casi todos los demás casos. Estás en Community, usas módulos OCA, tienes código a medida que necesita portado manual de todas formas o quieres un partner español llevando el proyecto de principio a fin. OpenUpgrade también te da visibilidad total — puedes ejecutar los scripts de análisis tú mismo, depurar fallos y reejecutar tantas veces como haga falta sobre staging.

Matiz importante: el servicio de Odoo SA migra la base de datos pero no migra tus módulos a medida. Su equipo ejecuta la actualización estándar y te envía una base de datos v19. Tú (o tu partner) seguís teniendo que portar el Python/JS/XML a medida. Así que si tenéis personalizaciones, el servicio de Odoo SA es una pieza del puzzle, no el puzzle entero.

OpenUpgrade para v19 se estabilizó en el Q1 de 2026. La comunidad OCA suele cazar bugs de borde durante los primeros 6 meses, así que para mediados de 2026 debería estar muy sólido. Si migráis entre octubre de 2025 y enero de 2026 sois early adopters y vais a tropezar con bugs que nadie ha reportado. A partir de abril de 2026 las cosas se estabilizan.

La espera de los módulos OCA: qué dependencias van a llegar tarde a v19

Los módulos OCA son extensiones open source mantenidas por la Odoo Community Association. Las empresas españolas dependen mucho de ellos, sobre todo para localización. La pega: la OCA publica una rama nueva por versión de Odoo y portarlos lleva tiempo.

Este es el estado aproximado a abril de 2026 de los repos que más importan a las pymes españolas.

• l10n-spain: prácticamente portado. Los módulos AEAT clave (mod303, mod347, mod349, mod111, mod190, SII), Verifactu y TicketBAI están en 19.0. Algunos módulos de nicho (reglas fiscales de comunidades autónomas concretas) pueden ir más atrás.
• account-financial-tools: casi todo en 19.0. Gestión de activos, account_lock_date_update, informes avanzados — listos en su mayoría.
• account-banking: parcial. account_banking_pain_base e importadores CAMT/MT940 en 19.0; algunos conectores específicos de banco (adaptadores de CaixaBank, Santander) van 2-3 meses por detrás.
• server-tools: casi todo en 19.0. base_technical_features, scheduler_error_mailer y similares ya están portados.
• web: casi todo en 19.0. El tema web_responsive, web_advanced_search y extensiones de UI populares suelen portarse en los primeros 2-3 meses.
• hr / payroll-spain: variable. Las extensiones estándar de hr_employee suelen estar pronto; las variantes específicas de nómina española (módulos de cotización concretos) tardan más porque dependen de que HR Holdings publique los datos legales correctos.
• project: lento. project-agile, project_timeline y módulos de visualización similares históricamente van 4-6 meses por detrás.
• Repos vertical-*: muy lentos. Si vuestro negocio depende de vertical-isp, vertical-hotel u otros repos verticales, contad con 6-12 meses de retraso.

Cómo comprobarlo vosotros mismos: id a github.com/OCA/<nombre-repo>/branches y mirad si existe la rama 19.0. Si existe con commits recientes, todo bien. Si está vacía o no se ha tocado en meses, el módulo aún no está portado. No os fiéis de blogs genéricos que dicen 'la OCA está lista para v19' — verificad vuestros módulos concretos.

Estrategia de mitigación cuando un módulo OCA crítico no está portado: contratad a un desarrollador (vuestro partner, un colaborador OCA o un freelance) para portarlo. Cuesta 1.000-5.000 € por módulo según complejidad. Enviad el PR de vuelta a la OCA — ahorraréis a otra persona el mismo dolor y ganaréis karma en la comunidad. Así sigue funcionando el ecosistema.

Paso a paso: el runbook real de migración

Este es el runbook que entregaría a un desarrollador interno competente o a un consultor junior. Asume Community o Enterprise autoalojado con OpenUpgrade. Los usuarios de Odoo.sh siguen una versión simplificada (su plataforma maneja los pasos 7-9 automáticamente).

1. Inventario previo (semana 1): pasad la auditoría de arriba. Puntuad cada módulo Verde/Ámbar/Rojo. Confirmad estado de módulos OCA. Estimad días de desarrollo para los Rojos.
2. Montad la infraestructura de pruebas: aprovisionad un servidor compatible con v19 (Python 3.10+, PostgreSQL 14+, RAM suficiente — al menos 8 GB para pymes). Replicad versiones de SO, Python y PostgreSQL exactamente. Documentadlo todo en un runbook.
3. Snapshot de producción: pg_dump completo, tar completo de los directorios /opt/odoo y addons, backup completo del filestore. Guardadlo en infraestructura separada. Probad que el backup realmente restaura.
4. Primer ensayo con OpenUpgrade: instalad OpenUpgrade 19.0, apuntadlo a una copia de la base de datos de producción, ejecutad la actualización. Esperad errores. Capturad cada log de error.
5. Arreglad errores y portad módulos a medida: trabajad el log de errores, arreglando configuración de OpenUpgrade, dependencias de módulos faltantes e incompatibilidades de módulos a medida. Aquí se va el tiempo real.
6. Segunda ejecución limpia con OpenUpgrade: reejecutad sobre una copia fresca de producción. El objetivo son cero errores. Si no llegáis a cero, documentad cada aviso restante y decidid si salís a producción con él.
7. UAT en staging: poned a usuarios reales (1-3 power users por departamento) a ejecutar flujos reales durante 1-2 semanas. Pedidos de venta, facturas, pedidos de compra, ciclos de nóminas, envíos Verifactu, envíos SII, flujos a medida, informes.
8. Planificad la ventana de corte: elegid un sábado sin actividad crítica del negocio. Comunicádselo a todos los usuarios con una semana de antelación. Coordinad con proveedores de extracto bancario, pasarelas de pago y otras integraciones.
9. Corte el viernes por la tarde: parad v18 producción, sacad el pg_dump y snapshot final del filestore, restaurad sobre el servidor v19 ya preparado, ejecutad los scripts de OpenUpgrade. Contad con 4-12 horas para bases de datos de tamaño pyme.
10. Pruebas de humo el sábado: reejecutad los guiones de UAT sobre los datos productivos migrados. Verificad la continuidad de la cadena hash de Verifactu. Probad una de cada integración. Tened a vuestro desarrollador de guardia.
11. Soft launch el domingo: abrid acceso a un grupo pequeño de usuarios. Vigilad logs sin parar. Estad listos para hacer rollback a v18 si algo crítico se rompe.
12. Lanzamiento total el lunes: acceso completo de usuarios. Tened a alguien monitorizando todo el día. Mantened el backup de v18 caliente al menos 14 días.

El punto de fallo más frecuente es el paso 5. Los equipos infraestiman cuánto lleva portar módulos a medida, revientan su estimación y aceleran el UAT para llegar a la fecha. No lo hagáis. Mover la fecha de corte antes que comprimir el UAT.

Tiempos de parada por tamaño de despliegue

¿Cuánto tiempo van a estar los usuarios sin acceso? Depende del tamaño de la base de datos y la complejidad de personalización. Estos son los rangos realistas a partir de mis propias ejecuciones y datos de partners.

• Pequeño (menos de 5 GB de base de datos, 5-10 usuarios, 0-3 módulos a medida): ejecución de OpenUpgrade 4-6 horas. Ventana total de corte 24-36 horas. Viernes por la tarde a domingo por la mañana.
• Medio (5-20 GB, 10-30 usuarios, 5-15 módulos a medida): ejecución de OpenUpgrade 6-12 horas. Corte total 36-72 horas. Viernes por la tarde a lunes por la mañana, con usuarios online el lunes a las 09:00.
• Grande (20-100 GB, más de 30 usuarios, personalizaciones profundas): ejecución de OpenUpgrade 12-24 horas. Corte total 3-5 días. A menudo un puente largo o migración escalonada por empresa/sucursal.
• Muy grande (100 GB+ o grupos multiempresa): 5-10+ días, a menudo por fases por empresa. Requiere herramientas de migración de datos a medida más allá del estándar de OpenUpgrade.

El tiempo de ejecución de OpenUpgrade es la parte que nadie presupuesta con precisión. Los proveedores dicen '4 horas' y os presupuestan eso. La realidad incluye: pasadas de validación de datos, scripts post-actualización, compilación de assets, reconstrucción del índice de búsqueda, scripts de migración de módulos a medida y vuestras pruebas de humo post-migración. Sumad un 50-100% de margen sobre lo que el partner os presupueste para la ventana de corte.

Checklist de re-certificación Verifactu (específico de España)

Si vendéis a clientes españoles y estáis pasada la fecha de obligatoriedad de Verifactu para vuestro tamaño, esta sección no es negociable. Migrar Odoo sin re-certificar Verifactu es buscarse un hallazgo de inspección de Hacienda.

¿Por qué importa? Verifactu, bajo el RD 1007/2023, exige registros de factura encadenados por hash que se puedan enviar a la AEAT en tiempo real o casi real. La cadena enlaza cada factura con el hash de la anterior. Una migración que rompe la cadena es un evento de incumplimiento.

• Verificad la validez del certificado AEAT: regenerad o renovad si caduca en los 60 días posteriores al corte.
• Confirmad la versión del módulo Verifactu en v19: l10n_es_edi_verifactu debe ser el release v19, no un retroporte manual de v18.
• Pasad una prueba de envío al entorno de pruebas: configurad el endpoint de pre-producción de la AEAT, enviad 3-5 facturas de prueba desde staging, verificad que cada una vuelve con un CSV (Código Seguro de Verificación) válido.
• Validad la continuidad de la cadena hash: la última factura emitida en v18 debe enlazar limpia con la primera factura emitida tras la migración en v19. Misma secuencia de hash, sin huecos. Vuestro desarrollador o partner debe confirmarlo en código.
• Probad la reimpresión de facturas: reimprimid una factura antigua (de la era v18) desde v19 — confirmad que el QR y el CSV siguen resolviendo bien al escanear.
• Coordinad con vuestra gestoría o contable: avisadles de la ventana de migración. Deben aguantar los envíos fiscales hasta que el sistema esté verificado limpio.
• Corred la prueba de envío SII si aplica: las empresas en régimen SII (grandes empresas, declarantes mensuales de IVA, tributación de grupo específica) deben verificar que el módulo SII también funciona en v19. Enviad 3-5 registros de prueba a pre-producción de la AEAT.
• Documentad la certificación: guardad un registro de resultados de prueba, validación de certificado y verificación de cadena hash. Hacienda lo pide en inspecciones — tenerlo listo ahorra semanas.

Cruzad esto con mi guía Odoo en España: Verifactu, SII y nóminas para la configuración de cumplimiento más profunda que hay que verificar tras la migración. Si estáis eligiendo vuestro enfoque Verifactu desde cero, mi guía de selección de software Verifactu cubre el contexto más amplio del mercado.

Costes reales de partners en España por tamaño de proyecto (€)

Pedí presupuestos a cuatro partners españoles de Odoo en marzo de 2026 para tres escenarios de referencia. Estos son los rangos realistas. Datos verificados en marzo de 2026, esperad un drift del 5-10% durante el año.

• Proyecto pequeño (5-10 usuarios, v18 estándar con 0-3 módulos a medida simples, una sola empresa, l10n_es_aeat + Verifactu): 8.000-15.000 € total. Incluye auditoría, ejecución de OpenUpgrade, portado de módulos a medida, soporte en UAT, fin de semana de corte, 2 semanas de soporte post-arranque.
• Proyecto medio (10-30 usuarios, 5-15 módulos a medida, multi-almacén, nóminas, integraciones con extracto bancario y un canal de e-commerce): 18.000-40.000 € total. Incluye todo lo anterior más pruebas de integración, validación de datos más profunda, más ciclos de UAT, 1 mes de soporte.
• Proyecto grande (más de 30 usuarios, personalizaciones profundas, multiempresa, flujos complejos, varias integraciones): 40.000-150.000 €+ total. A menudo escalonado en fases. Incluye gestión formal de proyecto, líder técnico dedicado, reuniones semanales de estado, 2-3 meses de soporte.

Partners españoles que merece la pena meter en la lista corta basándose en experiencia real con migración v18 a v19: Tecnativa (Madrid, también lidera el desarrollo de OpenUpgrade), Acysos (Valencia), Domatix (Madrid/Valencia), Aselcis (Barcelona), Factor Libre (Madrid) y Sygel (A Coruña). Para el mercado de partners más amplio mirad mi guía de mejores partners de Odoo en España.

Tarifas por hora de desarrolladores Odoo españoles en 2026: junior 40-55 €, mid-level 55-75 €, senior 75-110 €, arquitecto/líder 100-150 €. La mayoría de proyectos se factura a una tarifa mezclada de unos 70-85 € por hora. Si un partner presupuesta muy por debajo o subcontrata fuera (preguntad) o está tirando precios para ganar el proyecto (bandera roja).

Si un partner presupuesta 5.000 € fijos por una migración v18 a v19 con módulos a medida, marchaos. O no entiende el alcance, o piensa colaros un scope-creep hasta triplicar el precio a mitad de proyecto. El presupuesto creíble más barato en España para una migración con personalización real anda por los 8.000 €. Por debajo, algo huele mal.

Plan de rollback: qué hacer cuando algo se rompe

La esperanza no es una estrategia. Vuestra migración tiene una probabilidad no nula de salir lo bastante mal como para tener que volver a v18. Este es el plan que os protege.

1. Snapshot pre-corte: pg_dump completo de la base de datos productiva v18, tar completo del filestore, tar completo del directorio addons, snapshot de la configuración a nivel SO. Almacenado en infraestructura separada, probado para que restaure.
2. Mantened el servidor v18 en caliente: no desmantelad el servidor v18 productivo durante el corte. Dejadlo corriendo pero desconectado de los usuarios (regla de firewall). Lo podéis reactivar en 30 minutos si hace falta.
3. Criterios de decisión para rollback: definid antes del corte qué dispara un rollback. Ejemplos: envíos Verifactu fallando, cálculos de nómina dando importes erróneos, más del 20% de usuarios sin poder iniciar sesión, cualquier problema de integridad de datos que afecte a contabilidad.
4. Procedimiento de rollback (menos de 1 hora): si se dispara en las primeras 24 horas tras el corte, parad el acceso a v19, redirigid usuarios al servidor v18, comunicad que vais a hacer rollback y reprogramar. Investigad el fallo y arregladlo antes de reintentar.
5. Procedimiento de rollback (24-72 horas tras el corte): más difícil. Cualquier operación de negocio que ocurra en v19 no existe en el backup de v18. Tendréis que reintroducir manualmente pedidos de venta, facturas y otras transacciones de v19 a v18. Por eso no podéis tardar demasiado en tomar la decisión.
6. Desmantelad v18 solo cuando: el cierre de fin de mes en v19 termine sin problemas, los envíos Verifactu y SII de un periodo completo funcionen, todas las integraciones hayan procesado al menos un ciclo completo. Típicamente 30-45 días tras el go-live.

He visto un rollback en mis propios proyectos — un cliente de fabricación donde un módulo MRP a medida producía movimientos de stock erróneos tras la migración. Lo cazamos el domingo por la tarde, hicimos rollback a v18 el domingo por la noche, arreglamos el módulo durante la semana siguiente y reintentamos la migración dos fines de semana después con éxito. La lección: cazad los problemas rápido, no intentéis parchear en vivo.

Post-migración: qué probar en la primera semana

El go-live no es la línea de meta. La primera semana decide si la migración fue un éxito o un desastre a cámara lenta. Esto es lo que hay que verificar a diario.

• Día 1: cada usuario puede iniciar sesión, el CRUD básico funciona en registros comunes, los envíos Verifactu pasan, sin excepciones en el log de errores.
• Día 2: ciclo completo de venta (presupuesto a factura), ciclo completo de compra (RfQ a factura de proveedor), los movimientos de inventario se reflejan correctamente en los informes de stock.
• Día 3: las integraciones externas han procesado al menos un ciclo (extractos bancarios, sincronización de e-commerce, notificaciones de pasarela de pago).
• Día 5: el primer lote de facturas nuevas concilia contra los extractos bancarios, los informes contables muestran saldos correctos.
• Final de semana 1: nómina semanal si aplica, todas las acciones programadas se ejecutaron bien, las subidas de adjuntos funcionan, el envío de email funciona, el acceso desde móvil funciona.
• Semana 2: primeros informes para dirección. El equipo financiero confirma que los números cuadran con los saldos de cierre de v18.
• Final del mes 1: el cierre de fin de mes completo termina limpio. Los envíos Verifactu/SII del periodo funcionan. Comparad KPIs contra el mismo mes en v18.

Mantened un log de incidencias compartido durante la primera semana. Cada problema, por pequeño que sea, se registra con timestamp, usuario afectado, mensaje de error y resolución. Del log emergen patrones que apuntan a problemas sistémicos que de otra forma se os escaparían. A los 30 días, revisad el log con vuestro partner — esa es vuestra retrospectiva real post-migración.

Si todavía estáis valorando la decisión más amplia de si Odoo encaja, mi análisis de precios Odoo Community vs Enterprise y la guía de migración Odoo vs Holded cubren decisiones adyacentes que quizá os interese tomar antes de comprometeros con la actualización a v19.

Recomendación final

Migrad ahora. Elegid un partner español con al menos tres proyectos v18 a v19 a sus espaldas. Presupuestad realista — las pymes pequeñas caen en el rango 8.000-15.000 €, los proyectos medios 18.000-40.000 €. Pasad dos ensayos limpios con OpenUpgrade antes de fijar el corte. Re-certificad Verifactu antes del go-live. Mantened v18 en caliente 30-45 días tras el corte.

Si estáis en v17, ya no tenéis opción. Si estáis en v18, tenéis hasta el verano de 2027 antes de que la cosa apriete. El release de v20 en octubre de 2026 va a crear un acantilado de disponibilidad de partners — quien programe migraciones después de ese release pagará tarifas de urgencia y esperará meses por un hueco.

La categoría ERP es un compromiso a largo plazo y el mercado de software ERP está más saturado que nunca, pero la flexibilidad de Odoo más la comunidad OpenUpgrade es una combinación dura de batir para pymes españolas que han personalizado mucho. Tomad la migración en serio y os renta los próximos 3 años. Recortad esquinas y la estaréis depurando hasta Navidad.