Migración de módulos personalizados de Odoo 16 a Odoo 19 sin perder datos
Qué revisar antes de mover una instancia con desarrollos a la medida de Odoo 16 a Odoo 19, para no descubrir hasta producción qué se rompió.
Contexto oficial
Lo que sí está documentado y lo que debe validarse
Guía práctica
¿Por qué no es "solo" un upgrade de versión?
Entre Odoo 16 y Odoo 19 hay tres versiones mayores; cada una puede cambiar firmas de método, vistas heredadas, campos renombrados o eliminados que tu módulo personalizado usa.
Un módulo que funcionaba en 16 puede instalar "sin error" en 19 y aun así fallar en tiempo de ejecución, porque Python no siempre detecta en la instalación lo que sí rompe al usarlo.
Los reportes personalizados (QWeb) son de los elementos más frágiles: cambios menores en la estructura de vistas base pueden dejar reportes con formato roto o datos faltantes.
Los conectores a sistemas externos (PAC, e-commerce, bancos) deben validarse aparte, porque dependen tanto de la versión de Odoo como de la API del tercero.
Los permisos y grupos de seguridad personalizados también migran, pero deben revisarse contra la nueva estructura de aplicaciones; un permiso mal heredado puede exponer datos que antes estaban restringidos.
Guía práctica
Auditoría previa: ¿qué módulos sobreviven y cuáles no?
Inventaría todos los módulos instalados, separando estándar de Odoo, OCA de terceros y desarrollo propio de QUADIT o de otro proveedor.
Para cada módulo personalizado, documenta qué proceso de negocio resuelve; sin ese contexto, decidir si migrarlo, rehacerlo o descartarlo es una apuesta a ciegas.
Revisa dependencias cruzadas: un módulo personalizado que hereda de otro personalizado multiplica el riesgo si solo uno de los dos se actualiza.
Identifica qué funcionalidad personalizada ya existe de forma nativa en Odoo 19; migrar código viejo que el estándar actual ya resuelve es esfuerzo desperdiciado.
Prioriza por impacto de negocio, no por complejidad técnica: un módulo simple que factura mal un producto pesa más que uno complejo que solo genera un reporte interno.
Guía práctica
Estrategia de datos: ¿qué se conserva, qué se transforma?
Los datos transaccionales estándar (ventas, compras, contabilidad, inventario) siguen el proceso de actualización oficial de Odoo y normalmente se conservan sin intervención manual.
Los campos personalizados requieren mapeo explícito: si un módulo propio agregó campos a un modelo estándar, hay que confirmar que sobrevivan con el mismo significado tras la migración.
El historial fiscal (CFDI timbrados, complementos de pago, cancelaciones) debe conservarse íntegro y verificable; no es un dato que se pueda "recalcular" después.
Los documentos adjuntos y archivos vinculados (PDF de CFDI, evidencias, contratos) necesitan revisión aparte, porque no siempre viajan igual que los registros de base de datos.
Los registros archivados o marcados como inactivos también deben considerarse en la estrategia; descartarlos por parecer irrelevantes puede eliminar evidencia que el negocio necesite consultar después.
Guía práctica
Ambiente de pruebas: migrar sin arriesgar producción
Trabaja siempre sobre una copia de la base de datos productiva, nunca sobre el ambiente en vivo, aunque la ventana de mantenimiento parezca corta.
Prueba los procesos críticos de punta a punta: crear un pedido, facturarlo, timbrarlo, cobrarlo y cerrarlo contablemente, no solo abrir cada pantalla.
Involucra a los usuarios que operan el sistema todos los días; ellos detectan diferencias de comportamiento que un equipo técnico puede pasar por alto.
Compara reportes clave (ventas, inventario, contabilidad) entre la versión anterior y la nueva sobre el mismo periodo, para confirmar que los números cuadran antes de salir a producción.
Define de antemano un plan de reversa: si algo crítico falla el día del cambio, debe existir una forma clara de regresar a la versión anterior sin perder operación del día.
Guía práctica
Errores que sí causan pérdida real de datos o de negocio
Migrar directamente sobre producción sin ambiente de prueba, apostando a que "debería funcionar" porque funcionó en una instancia demo.
Ignorar módulos personalizados menores porque parecen poco usados, y descubrir después que un área específica del negocio dependía completamente de ellos.
No validar el historial fiscal después de la migración, y enterarse meses después de una auditoría que hay CFDI o complementos inconsistentes.
Migrar sin capacitar al equipo en lo que cambió de interfaz o de flujo, generando errores de captura que se confunden con "bugs de la migración".
Subestimar el tiempo del proyecto y forzar una fecha de salida antes de terminar las pruebas de los módulos personalizados críticos.
Guía práctica
¿Qué preguntarle a tu proveedor antes de aceptar una migración?
¿Van a auditar cada módulo personalizado uno por uno, o van a "probar y ver qué truena" directamente en un ambiente de prueba?
¿Quién valida el historial fiscal después de migrar: el equipo técnico, contabilidad, o nadie de forma explícita?
¿Existe un plan de reversa documentado, con tiempo estimado, en caso de que algo crítico falle el día del cambio?
¿Qué pasa con los módulos personalizados que ya no tienen sentido en Odoo 19 porque el estándar los resuelve mejor: se descartan o se migran igual por costumbre?
Si tu proveedor no tiene respuesta clara a estas preguntas antes de empezar, es una señal de que el proyecto se está cotizando como un upgrade técnico y no como lo que realmente es.
Guía práctica
Después de migrar: ¿qué monitorear las primeras semanas?
Revisa a diario, no solo la primera semana, que el timbrado de CFDI y complementos de pago siga funcionando sin incidencias nuevas.
Da seguimiento cercano a los módulos personalizados de mayor uso; los problemas que no aparecieron en pruebas suelen salir con volumen real de operación.
Compara cierres contables del primer mes post-migración contra el histórico, para detectar a tiempo cualquier diferencia que las pruebas no hayan capturado.
Mantén habilitado, al menos por un periodo definido, el acceso al ambiente anterior o a un respaldo consultable, por si se necesita comparar un dato puntual.
Documenta cada incidencia real (no cada duda de usuario) para cerrar el proyecto con evidencia de que la migración quedó estable, no solo con la percepción de que "ya no hay quejas".
Establece un canal claro para que los usuarios reporten diferencias de comportamiento durante el primer mes; muchas señales tempranas de un problema mayor llegan primero como un comentario informal de alguien que opera el sistema a diario.
Programa una revisión formal a 30 y a 90 días después de salir a producción, no solo la primera semana; algunos problemas de datos o de módulos personalizados solo aparecen con un ciclo completo de operación.
Cierra el proyecto de migración formalmente, con fecha y responsable, en lugar de dejarlo abierto de forma indefinida; eso obliga a documentar qué quedó pendiente y qué se dio por resuelto.
Guía práctica
¿Qué no deberías intentar migrar tú mismo sin apoyo técnico?
Módulos personalizados que tocan facturación, CFDI o complementos de pago: un error aquí no es solo técnico, es fiscal, y puede tardar meses en detectarse si nadie audita el historial.
Migraciones donde el desarrollador original del módulo personalizado ya no está disponible y nadie más documentó cómo funciona por dentro.
Bases de datos con volumen alto de transacciones históricas sin un ambiente de prueba con capacidad equivalente para validar tiempos y comportamiento real.
Cualquier escenario donde la fecha de salida a producción se decidió antes de terminar la auditoría de módulos personalizados; forzar el calendario ahí es donde más se pierde control del proyecto.
Integraciones críticas con bancos, PAC o plataformas de e-commerce sin un plan de contingencia si el conector deja de responder igual que en la versión anterior.
Decisiones de "aprovechar y reescribir todo desde cero" tomadas sin evaluar primero si el estándar de Odoo 19 ya cubre gran parte de lo que el módulo personalizado resolvía en Odoo 16.
Cualquier migración que se decida por presión de fecha comercial en lugar de por preparación técnica real; el costo de una salida apresurada casi siempre termina siendo mayor que el de esperar unas semanas más.
Fuentes oficiales
Referencias usadas para esta guía
Siguiente lectura
Páginas relacionadas de QUADIT
¿Necesitas llevar esto a una implementación real?
Podemos revisar tu proceso, tu configuración actual o tu plan de migración antes de comprometer presupuesto.
Solicitar diagnóstico Solicitar diagnóstico de rescate