Guía de migración de Odoo 18 a 19 para pymes españolas (2026)

Tres meses. Eso es lo que tarda una migración de v18 a v19 bien hecha en una pyme española de 25 usuarios si empiezas ya. Y por eso los equipos que esperen a octubre de 2026 pagarán el doble o acabarán empujados al primer trimestre de 2027. Me pasé de febrero a abril de 2026 haciendo una prueba en seco con OpenUpgrade sobre una demo de Odoo v18 con 12 módulos y 3 módulos a medida, y luego comparando presupuestos de cuatro partners españoles de Odoo. Esta guía es lo que me habría gustado que alguien me diera antes de empezar.

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

Escribo esto en primera persona porque los errores los cometí yo. El proceso de OpenUpgrade me reventó dos veces en la demo. La revisión de dependencias de la OCA destapó tres módulos que aún no están portados. La recertificación de Verifactu tardó más que la propia actualización de la base de datos. Tú no tienes por qué repetir nada de eso.

Metodología: monté una instancia v18.0 limpia con la localización estándar l10n_es, 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 que hereda de sale.order, otro que extiende res.partner y otro con un flujo de aprobación creado con Studio). Ejecuté OpenUpgrade 19.0 sobre una instantánea entre el 14 de febrero y el 8 de abril de 2026. Los datos de precios salen de presupuestos que pedí a Tecnativa, Acysos, Domatix y Sygel en marzo de 2026.

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

La ventana oficial de soporte de Odoo SA para clientes Enterprise es de aproximadamente 3 años por versión mayor. v17 salió en octubre de 2023, así que sus parches de seguridad empiezan a agotarse hacia finales de 2026. v18 salió en octubre de 2024, lo que te da hasta más o menos el cuarto trimestre de 2027 antes de que se acaben las correcciones de seguridad de Enterprise. Los usuarios de Community reciben parches de la comunidad, pero todo lo que dependa mucho de la localización (es decir, cualquier empresa española) depende de módulos de la OCA que siguen el ritmo de Odoo SA.

Y ahora la parte de la que nadie habla. La normativa española va a su propio ritmo, y a ese ritmo le da igual tu versión de Odoo.

Verifactu (según 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 normativos cuando Odoo SA pasa página. Si Hacienda cambia un campo obligatorio en 2027 y sigues atascado en v17, tus facturas podrían dejar de validarse. No es un riesgo hipotético: ya pasó con el SII en 2017.

v19 trae además mejoras importantes para la operativa en España: un conjunto de módulos de la AEAT actualizado, un manejo más fino de la cadena de hashes de Verifactu, mejor integración con TicketBAI para clientes vascos y las actualizaciones de nóminas que tanto se hacían esperar, ajustadas a las últimas tablas de cotización. Nada de esto se va a llevar a v17.

Si vendes a grandes empresas que exigen versiones modernas de ERP en sus auditorías de proveedores, tienes otro motivo para moverte. He visto a departamentos de compras dejar fuera a proveedores con un Odoo de hace dos versiones por el riesgo de seguridad percibido.

Así que las cuentas son sencillas. Migra ahora (primavera de 2026), paga tarifas normales, trabaja con módulos de la OCA maduros y esquiva la estampida de octubre. Espera seis meses y pagarás un 30-40% más, te pelearás por la disponibilidad de los partners y te arriesgas a que salga v20 a mitad de proyecto.

Auditoría previa: qué 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 staging: haz inventario de todo. La principal causa de sobrecostes en las migraciones de Odoo es descubrir una personalización olvidada en pleno cambio.

Esta es la checklist que paso en cada proyecto con clientes. Lleva más o menos un día. Sáltatela y te arrepentirás.

• Módulos instalados: lista completa desde el menú Aplicaciones, dependencias incluidas. Expórtala a CSV.
• Módulos a medida en tu ruta de addons: cada carpeta de /mnt/extra-addons o de donde los guardes. Apunta el número de líneas de Python/XML como indicador de complejidad.
• Módulos de la OCA en uso: qué repositorios de la OCA y qué módulos concretos. Comprueba el estado de cada uno para v19 en GitHub.
• Personalizaciones de Studio: cada aplicación, campo personalizado, acción automatizada, flujo de aprobación e informe de Studio. Studio los muestra en su propio menú: exporta la lista.
• Integraciones externas: cada llamada a la API de entrada o salida (Stripe, bancos vía PSD2, Holded si sincronizas, marketplaces, tus propios webhooks). Documenta el método de autenticación y qué modelos de Odoo tocan.
• Acciones de servidor y acciones programadas activas: registros ir.actions.server e ir.cron. Algunos hacen referencia a métodos eliminados en v19.
• Informes QWeb: cada plantilla personalizada de factura, albarán o pedido de venta. Apunta la plantilla padre de la que hereda cada una.
• Plantillas de correo: registros mail.template personalizados, sobre todo cualquiera que sustituya al correo de factura por defecto.
• Tamaño de la base de datos: GB totales y tablas más grandes (normalmente stock_move, mail_message, ir_attachment). Determina cuánto tarda OpenUpgrade.
• Número de usuarios y sesiones activas: te ayuda a dimensionar el entorno de staging y a planificar la ventana de cambio.

Con el inventario hecho, puntúa cada elemento: Verde (estándar, estable en la OCA, migrará limpio), Ámbar (necesita revisión, quizá una reescritura menor), Rojo (a medida, complejo, necesita tiempo de desarrollo seguro). El porcentaje de elementos en rojo decide si estás ante un proyecto de 8.000 € o de 40.000 €. Volveré a esto en la sección de costes.

Si no tienes un desarrollador en plantilla, pide a tu partner que haga la auditoría antes de presupuestar. Los buenos (Tecnativa, Acysos, Domatix, Sygel) le dedicarán 4-8 horas antes de comprometerse con un precio cerrado. Los malos presupuestan sin mirar. Evita a estos últimos.

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

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

v19 trae varios cambios incompatibles que afectan a aproximadamente el 30-50% de los módulos a medida de v18 si no se reescriben. Esto es con lo que te vas a encontrar.

• Cambios en el framework Owl 2: v19 incluye un Owl 2 actualizado con un ciclo de vida de componentes más estricto y una sintaxis de slots distinta. Cualquier widget JS a medida escrito para v18 necesita revisión. Los widgets de campo sencillos suelen portarse sin problema; las extensiones complejas de vistas Kanban o de lista a menudo hay que reescribirlas.
• 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 actualizar explícitamente @api.depends_context.
• Campos renombrados o eliminados: en cada versión Odoo SA renombra campos sin hacer ruido. v19 renombró varios campos de res.partner y unificó algunos campos de seguimiento de sale.order. Tu código a medida que use los nombres antiguos se rompe en silencio: los métodos devuelven None en lugar de lanzar un error.
• Cambios en la arquitectura de vistas: la vista de formulario por defecto de product.template se ha reestructurado. Si tienes añadidos con <xpath> que apuntan a posiciones concretas, la mitad no se aplicarán.
• Cambios en los paquetes de assets: la forma de registrar los assets JS/CSS en __manifest__.py ha cambiado ligeramente. La sintaxis antigua sigue funcionando en v19, pero lanza avisos de obsolescencia; lo más probable es que v20 la elimine.
• Métodos obsoletos eliminados: unos cuantos métodos de modelo marcados como obsoletos en v17/v18 desaparecen en v19. El script de análisis de OpenUpgrade los señala, pero no los arregla.

¿Cómo averiguas qué se rompe? Con dos herramientas. Primero, OpenUpgrade incluye un script de análisis que compara tu módulo de v18 con las definiciones de modelos de v19 y marca los posibles problemas. Segundo, levantas una instancia de staging en v19, instalas tus módulos a medida y ves cómo explotan los logs. Las dos son necesarias; ninguna basta por sí sola.

Regla de presupuesto sacada de mis propios proyectos: los módulos a medida sencillos (menos de 200 líneas, sin JS) se portan en 2-4 horas. Los de complejidad media (algo de JS, lógica entre varios modelos), en 1-3 días. Los complejos (mucho JS, flujos a medida, integraciones), en 3-10 días. Con un desarrollador de Odoo español a 60 €/hora, reescribir un módulo complejo cuesta 1.500-4.800 €. Con tres de esos ya has gastado más que todo el proyecto de migración de un partner pequeño.

Si tienes más de 10 módulos a medida y alguno toca la capa JS, no lo intentes sin un partner que haya entregado al menos tres migraciones de v18 a v19. La primera siempre les hace perder dinero. Te interesa el partner que ya lo perdió con el proyecto de otro.

OpenUpgrade o el servicio de migración de Odoo SA: cuándo conviene cada uno

Hay dos caminos. Odoo SA vende un servicio de migración de pago a los clientes Enterprise: ejecutan los scripts de actualización de la base de datos con sus propias herramientas y te devuelven una copia en v19. La alternativa comunitaria es OpenUpgrade, un proyecto de la OCA que mantiene scripts de actualización open source para cada salto de versión mayor. Tecnativa es uno de los mayores contribuidores del proyecto, y por eso la mayoría de partners españoles tiran de OpenUpgrade por defecto.

¿Cuándo tiene sentido Odoo SA? Cuando estás en Enterprise, tienes pocas personalizaciones y quieres un único responsable al que reclamar si algo falla. La migración de Odoo SA viene incluida en algunos contratos Enterprise y se puede añadir a otros. El precio depende del tamaño de la base de datos, del número de usuarios y de la complejidad de las personalizaciones: Odoo SA presupuesta caso a caso, normalmente 4.000-20.000 € para proyectos del tamaño de una pyme.

¿Cuándo tiene sentido OpenUpgrade? Casi en todos los demás casos. Estás en Community, usas módulos de la OCA, tienes código a medida que de todos modos hay que portar a mano o quieres que un partner español lleve el proyecto de principio a fin. OpenUpgrade además te da visibilidad total: puedes ejecutar tú mismo los scripts de análisis, depurar los fallos y repetir en staging tantas veces como necesites.

Un matiz importante: el servicio de Odoo SA migra la base de datos, pero no tus módulos a medida. Su equipo ejecuta la actualización estándar y te entrega una base de datos en v19. Tú (o tu partner) sigues teniendo que portar el Python/JS/XML a medida. Así que, si tienes personalizaciones, el servicio de Odoo SA es una pieza del puzle, no el puzle entero.

OpenUpgrade para v19 pasó a estable en el primer trimestre de 2026. La comunidad de la OCA suele ir resolviendo los fallos de casos límite durante los primeros 6 meses, así que a mediados de 2026 debería estar muy sólido. Si migras entre octubre de 2025 y enero de 2026, eres de los primeros y te toparás con fallos que nadie ha reportado aún. A partir de abril de 2026, la cosa se estabiliza.

La espera de los módulos de la OCA: qué dependencias es probable que vayan con retraso en v19

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

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

• l10n-spain: portado en gran parte. Los módulos principales de la AEAT (mod303, mod347, mod349, mod111, mod190, SII), Verifactu y TicketBAI están en 19.0. Algunos módulos de nicho (reglas fiscales concretas de comunidades autónomas) pueden ir aún con retraso.
• account-financial-tools: casi todo en 19.0. Gestión de activos, account_lock_date_update, informes avanzados: casi todo listo.
• account-banking: parcial. account_banking_pain_base y los importadores CAMT/MT940 están en 19.0; algunos conectores específicos de bancos (adaptadores de CaixaBank y Santander) van 2-3 meses por detrás.
• server-tools: casi todo en 19.0. base_technical_features, scheduler_error_mailer y similares están portados.
• web: casi todo en 19.0. El tema web_responsive, web_advanced_search y las extensiones de interfaz más populares suelen portarse en los 2-3 primeros meses.
• hr / payroll-spain: variable. Las extensiones estándar de hr_employee suelen estar listas pronto; las variantes específicas de nóminas españolas (módulos ligados a la cotización) 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.
• *vertical- repos**: muy lentos. Si tu negocio depende de vertical-isp, vertical-hotel u otros repositorios verticales, cuenta con 6-12 meses de retraso.

Cómo comprobarlo tú mismo: entra en github.com/OCA/<nombre-del-repo>/branches y busca la rama 19.0. Si existe y tiene commits recientes, perfecto. Si está vacía o nadie la ha tocado en meses, el módulo aún no está portado. No te fíes de artículos genéricos que dicen que «la OCA ya está lista para v19»: comprueba tus módulos concretos.

Qué hacer cuando un módulo crítico de la OCA no está portado: contrata a un desarrollador (tu partner, un contribuidor de la OCA o un freelance) para que lo porte. Cuesta 1.000-5.000 € por módulo según la complejidad. Envía la PR de vuelta a la OCA: le ahorrarás a otro el mismo sufrimiento y ganarás crédito en la comunidad. Así es como el ecosistema sigue funcionando.

Paso a paso: el plan de migración real

Este es el plan que le daría a un desarrollador interno competente o a un consultor junior. Da por hecho Community o Enterprise autoalojado con OpenUpgrade. Si usas Odoo.sh, sigue una versión simplificada (la plataforma se encarga de los pasos 7-9 automáticamente).

1. Inventario previo (semana 1): pasa la checklist de auditoría de arriba. Puntúa cada módulo en Verde/Ámbar/Rojo. Confirma el estado de los módulos de la OCA. Estima los días de desarrollo para los elementos en rojo.
2. Monta la infraestructura de staging: prepara un servidor apto para v19 (Python 3.10+, PostgreSQL 14+, RAM suficiente: al menos 8 GB para una pyme). Replica exactamente las versiones de sistema operativo, Python y PostgreSQL de producción. Documéntalo todo en el plan.
3. Haz una instantánea de producción: pg_dump completo, tar completo de los directorios /opt/odoo y addons, y copia completa del filestore. Guárdalo en una infraestructura aparte. Comprueba que la copia se restaura de verdad.
4. Primera prueba en seco con OpenUpgrade: instala OpenUpgrade 19.0, apúntalo a una copia de la base de datos de producción y lanza la actualización. Espera errores. Guarda cada log de error.
5. Corrige errores y porta los módulos a medida: ve resolviendo el log de errores, arreglando problemas de configuración de OpenUpgrade, dependencias de módulos que faltan e incompatibilidades de los módulos a medida. Aquí es donde se va el tiempo de verdad.
6. Segunda ejecución limpia de OpenUpgrade: repítela sobre una copia nueva de producción. El objetivo es cero errores. Si no llegas a cero, documenta cada aviso pendiente y decide si sales con él.
7. Pruebas de usuario en staging: que usuarios reales (1-3 usuarios avanzados por departamento) ejecuten flujos reales durante 1-2 semanas. Pedidos de venta, facturas, pedidos de compra, ciclos de nóminas, envíos a Verifactu, envíos al SII, flujos a medida, informes.
8. Planifica la ventana de cambio: elige un sábado sin actividad crítica. Avisa a todos los usuarios con una semana de antelación. Coordínate con los proveedores de extractos bancarios, pasarelas de pago y demás integraciones.
9. Cambio el viernes por la tarde: para la producción en v18, saca el último pg_dump y la instantánea del filestore, restaura en el servidor v19 ya preparado y ejecuta los scripts de OpenUpgrade. Cuenta con 4-12 horas para bases de datos del tamaño de una pyme.
10. Pruebas rápidas el sábado: vuelve a pasar los guiones de pruebas de usuario sobre los datos de producción migrados. Verifica la continuidad de la cadena de hashes de Verifactu. Prueba una de cada integración. Ten a tu desarrollador de guardia.
11. Arranque suave el domingo: abre el acceso a un grupo pequeño de usuarios. Vigila los logs sin descanso. Prepárate para volver a v18 si algo crítico se rompe.
12. Arranque completo el lunes: acceso para todos los usuarios. Que alguien vigile todo el día. Mantén la copia de v18 en caliente al menos 14 días.

El punto de fallo más habitual es el paso 5. Los equipos subestiman lo que se tarda en portar los módulos a medida, se pasan de la estimación y recortan las pruebas de usuario para llegar a la fecha. No lo hagas. Mueve la fecha del cambio antes que comprimir las pruebas.

Tiempos de parada según el tamaño de la instalación

¿Cuánto tiempo se quedarán los usuarios sin acceso? Depende del tamaño de la base de datos y de la complejidad de las personalizaciones. Estos son los rangos realistas según mis propias ejecuciones y los datos de los partners.

• Pequeña (base de datos de menos de 5 GB, 5-10 usuarios, 0-3 módulos a medida): OpenUpgrade tarda 4-6 horas. Ventana total de cambio de 24-36 horas. Del viernes por la tarde al domingo por la mañana.
• Mediana (5-20 GB, 10-30 usuarios, 5-15 módulos a medida): OpenUpgrade tarda 6-12 horas. Cambio total de 36-72 horas. Del viernes por la tarde al lunes por la mañana, con los usuarios de vuelta el lunes a las 09:00.
• Grande (20-100 GB, más de 30 usuarios, mucha personalización): OpenUpgrade tarda 12-24 horas. Cambio total de 3-5 días. A menudo un puente largo, o una migración escalonada por empresa o sucursal.
• Muy grande (más de 100 GB o grupos multiempresa): 5-10 días o más, a menudo por fases y por empresa. Requiere herramientas de migración de datos a medida más allá de lo que trae OpenUpgrade.

El tiempo de ejecución de OpenUpgrade es la parte que nadie presupuesta bien. Los proveedores dicen «4 horas» y te presupuestan eso. La realidad incluye: pasadas de validación de datos, scripts posteriores a la actualización, compilación de assets, reconstrucción de índices de búsqueda, scripts de migración de los módulos a medida y tus pruebas rápidas tras la migración. Añade un margen del 50-100% a lo que te presupueste el partner para la ventana de cambio.

Checklist de recertificación de Verifactu (específica de España)

Si vendes a clientes españoles y ya ha pasado la fecha de obligatoriedad de Verifactu para el tamaño de tu empresa, esta sección no es opcional. Migrar Odoo sin recertificar Verifactu es buscarte una incidencia en una inspección de Hacienda.

¿Por qué importa? Para Verifactu, el RD 1007/2023 exige registros de facturación encadenados mediante hash que puedan enviarse 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 incidente de cumplimiento.

• Comprueba la validez del certificado de la AEAT: regéneralo o renuévalo si caduca en los 60 días siguientes al cambio.
• Confirma la versión del módulo Verifactu en v19: l10n_es_edi_verifactu tiene que ser la versión de v19, no una adaptación de v18 copiada a mano.
• Haz la prueba de envío en el entorno de pruebas: configura el endpoint de preproducción de la AEAT, envía 3-5 facturas de prueba desde staging y verifica que cada una vuelve con un CSV (Código Seguro de Verificación) válido.
• Valida la continuidad de la cadena de hashes: la última factura emitida en v18 debe enlazar limpiamente con la primera emitida en v19 tras la migración. Misma secuencia de hashes, sin huecos. Tu desarrollador o partner tiene que confirmarlo en el código.
• Prueba a reimprimir facturas: reimprime desde v19 una factura antigua (de la época de v18) y confirma que el código QR y el CSV siguen resolviéndose bien al escanearlos.
• Coordínate con tu gestoría o tu contable: avísales de la ventana de migración. Deberían esperar para presentar impuestos hasta que el sistema esté verificado.
• Haz la prueba de envío al SII si te aplica: las empresas acogidas al SII (grandes empresas, quienes declaran el IVA mensualmente, determinados regímenes de grupo) deben comprobar que el módulo del SII también funciona en v19. Envía 3-5 registros de prueba a la preproducción de la AEAT.
• Documenta la certificación: guarda un registro de los resultados de las pruebas, la validación del certificado y la verificación de la cadena de hashes. Hacienda lo pide en las inspecciones, y tenerlo preparado ahorra semanas.

Consulta mi guía de Verifactu, SII y nóminas en Odoo para España para la configuración de cumplimiento más a fondo que hay que verificar tras la migración. Si estás eligiendo tu enfoque de Verifactu desde cero, mi guía para elegir software Verifactu cubre el contexto general del mercado.

Costes reales de partners en España según el tamaño del proyecto (€)

En marzo de 2026 pedí presupuesto a cuatro partners españoles de Odoo para tres escenarios de referencia. Estos son los rangos realistas. Cifras verificadas en marzo de 2026; cuenta con una variación del 5-10% a lo largo del año.

• Proyecto pequeño (5-10 usuarios, v18 estándar con 0-3 módulos a medida sencillos, una sola empresa, l10n_es_aeat + Verifactu): 8.000-15.000 € en total. Incluye auditoría, ejecución de OpenUpgrade, portado de módulos a medida, apoyo en las pruebas de usuario, fin de semana de cambio y 2 semanas de soporte tras el arranque.
• Proyecto mediano (10-30 usuarios, 5-15 módulos a medida, varios almacenes, nóminas, integraciones con extractos bancarios y un canal de comercio electrónico): 18.000-40.000 € en total. Incluye todo lo anterior más pruebas de integración, validación de datos más a fondo, más ciclos de pruebas de usuario y 1 mes de soporte.
• Proyecto grande (más de 30 usuarios, mucha personalización, multiempresa, flujos complejos, varias integraciones): 40.000-150.000 € o más en total. A menudo se hace por fases. Incluye gestión de proyecto formal, responsable técnico dedicado, reuniones de seguimiento semanales y 2-3 meses de soporte.

Partners españoles que merece la pena meter en la lista corta por su experiencia real en migraciones de v18 a v19: Tecnativa (Madrid; además lidera el desarrollo de OpenUpgrade), Acysos (Valencia), Domatix (Madrid/Valencia), Aselcis (Barcelona), Factor Libre (Madrid) y Sygel (A Coruña). Para ver el mercado de partners más amplio, consulta mi selección de los mejores partners de Odoo en España en su guía dedicada.

Tarifas por hora de desarrolladores de Odoo en España en 2026: junior 40-55 €, nivel medio 55-75 €, senior 75-110 €, arquitecto o responsable técnico 100-150 €. La mayoría de proyectos se facturan a una tarifa media de unos 70-85 € por hora. Si un partner presupuesta muy por debajo, o está subcontratando fuera (pregúntale) o está tirando el precio para llevarse el proyecto (señal de alarma).

Si un partner te presupuesta 5.000 € cerrados por una migración de v18 a v19 con módulos a medida, vete. O no entiende el alcance, o piensa ampliártelo hasta triplicar el precio a mitad de proyecto. El presupuesto creíble más barato en España para una migración con alguna personalización real ronda los 8.000 €. Por debajo de eso, algo falla.

Plan de vuelta atrás: qué hacer cuando algo se rompe

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

1. Instantánea previa al cambio: pg_dump completo de la base de datos de producción v18, tar completo del filestore, tar completo del directorio de addons e instantánea de la configuración del sistema operativo. Guardado en una infraestructura aparte y con la restauración probada.
2. Mantén el servidor v18 en caliente: no desmontes el servidor de producción v18 durante el cambio. Déjalo funcionando pero desconectado de los usuarios (regla de cortafuegos). Puedes reactivarlo en 30 minutos si hace falta.
3. Criterios para decidir la vuelta atrás: define antes del cambio qué la dispara. Ejemplos: envíos a Verifactu que fallan, nóminas que calculan importes erróneos, más del 20% de los usuarios sin poder iniciar sesión, cualquier problema de integridad de datos que afecte a la contabilidad.
4. Procedimiento de vuelta atrás (menos de 1 hora): si se dispara en las 24 horas siguientes al cambio, corta el acceso a v19, redirige a los usuarios al servidor v18 y comunica que vuelves atrás y reprogramas. Investiga el fallo y corrígelo antes de reintentarlo.
5. Procedimiento de vuelta atrás (24-72 horas tras el cambio): más difícil. Las operaciones que se hicieron en v19 no existen en la copia de v18. Tendrás que volver a introducir a mano en v18 los pedidos de venta, facturas y demás transacciones hechas en v19. Por eso no puedes esperar demasiado para tomar la decisión.
6. Desmonta v18 solo cuando: se haya completado con éxito un cierre de mes entero en v19, los envíos a Verifactu y al SII de un periodo completo funcionen y todas las integraciones hayan procesado al menos un ciclo completo. Normalmente, 30-45 días después del arranque.

He visto una vuelta atrás en mis propios proyectos: un cliente industrial cuyo módulo de MRP a medida generaba movimientos de stock erróneos tras la migración. Lo detectamos el domingo por la tarde, volvimos a v18 esa misma noche, arreglamos el módulo durante la semana siguiente y repetimos la migración con éxito dos fines de semana después. La lección: detecta los problemas rápido y no intentes parchear en vivo.

Tras la migración: qué probar la primera semana

Arrancar no es la meta. La primera semana decide si la migración ha sido un éxito o un desastre a cámara lenta. Esto es lo que tienes que comprobar cada día.

• Día 1: todos los usuarios pueden iniciar sesión, las operaciones básicas de crear, leer, editar y borrar funcionan en los registros habituales, los envíos a Verifactu pasan y no hay excepciones en el log de errores.
• Día 2: ciclo de venta completo (del presupuesto a la factura), ciclo de compra completo (de la solicitud de presupuesto a la factura del proveedor) y movimientos de inventario reflejados correctamente en los informes de stock.
• Día 3: las integraciones externas han procesado al menos un ciclo (extractos bancarios, sincronización de la tienda online, notificaciones de la pasarela de pago).
• Día 5: el primer lote de facturas nuevas se concilia con los extractos bancarios y los informes contables muestran saldos correctos.
• Final de la semana 1: nómina semanal si aplica, todas las acciones programadas se han ejecutado bien, la subida de adjuntos funciona, el envío de correos funciona y el acceso desde el móvil funciona.
• Semana 2: primeros informes para dirección. El equipo financiero confirma que las cifras cuadran con los saldos de cierre de v18.
• Final del mes 1: el cierre de mes completo sale limpio. Los envíos a Verifactu y al SII del periodo funcionan. Compara los KPI con los del mismo mes en v18.

Lleva un registro de incidencias compartido durante la primera semana. Cada problema, por pequeño que sea, se anota con fecha y hora, usuario afectado, mensaje de error y solución. Del registro salen patrones que apuntan a problemas de fondo que, si no, se te escaparían. A los 30 días, revísalo con tu partner: esa es tu verdadera retrospectiva tras la migración.

Si todavía estás dándole vueltas a la decisión de fondo, si Odoo es lo que te conviene, mi comparativa de precios de Odoo Community, Enterprise y Cloud y la guía de migración de Holded a Odoo cubren decisiones relacionadas que quizá quieras tomar antes de comprometerte con la actualización a v19.

Recomendación final

Migra ya. Elige un partner español con al menos tres proyectos de v18 a v19 a sus espaldas. Presupuesta con realismo: las pymes pequeñas se mueven en 8.000-15.000 € y los proyectos medianos en 18.000-40.000 €. Haz dos pruebas en seco limpias con OpenUpgrade antes de fijar el cambio. Recertifica Verifactu antes del arranque. Mantén v18 en caliente 30-45 días tras el cambio.

Si estás en v17, ya no tienes elección. Si estás en v18, tienes hasta el verano de 2027 antes de que el margen se estreche. El lanzamiento de v20 en octubre de 2026 va a provocar un desplome de la disponibilidad de partners: quien programe su migración después pagará tarifas de urgencia y esperará meses por un hueco.

Un ERP es un compromiso a largo plazo y el mercado de software ERP está más saturado que nunca, pero la flexibilidad de Odoo sumada a la comunidad de OpenUpgrade es una combinación difícil de superar para las pymes españolas que han personalizado mucho. Tómate la migración en serio y te compensará durante los próximos 3 años. Recorta esquinas y estarás depurándola hasta Navidad.