Si tienes una fecha de go-live a Odoo 19 en el horizonte, la parte técnica de la migración — actualizar el esquema, convertir los módulos, mover los datos — suele estar bien cubierta por quien hace la migración. Lo que suele quedarse fuera de la hoja de ruta es todo lo que rodea esa migración: datos sucios desde el origen, módulos de terceros que nadie ha probado de verdad, ningún plan si algo sale mal, o un equipo que llega al primer día sin saber dónde está lo que usaba cada día. Este artículo recoge, en forma de checklist, los seis bloques que hemos visto marcar la diferencia en migraciones reales.
Idea clave: un go-live casi nunca falla por un único error técnico grande — falla por la acumulación de varios puntos pequeños que nadie verificó a tiempo: un dato maestro duplicado que descuadra un informe, un módulo de terceros que «debería funcionar» pero nadie probó con datos reales, o un equipo que no supo qué hacer en la primera hora porque nadie le enseñó el flujo real. Este checklist cubre los seis bloques que, en nuestra experiencia implantando Odoo, marcan la diferencia entre un go-live tranquilo y uno de bomberos.
Por qué la mayoría de migraciones se complican por el mismo punto
No suele ser la migración técnica en sí — la actualización de esquema o la conversión de módulos — lo que descarrila un go-live. Suele ser alguno de los seis bloques de este checklist, dado por hecho porque «ya se había hablado» pero nunca verificado con datos reales ni por escrito. Repasarlos antes de fijar fecha no alarga el proyecto: evita que la fecha fijada tenga que moverse a última hora.
El checklist completo antes del go-live
Seis bloques, un punto de control por bloque y por qué es crítico — en forma de tabla para que puedas usarlo tal cual con tu equipo.
Tabla resumen: los 6 bloques a revisar antes de dar el go-live por bueno
| Bloque | Punto de control | Por qué es crítico |
|---|---|---|
| Datos maestros | Contactos, productos, tarifas, plantillas de impuestos y saldos revisados, sin duplicados ni huérfanos | Un dato maestro mal migrado no falla en el momento de migrar — falla semanas después, en una factura o un informe, cuando ya es difícil rastrear el origen |
| Módulos de terceros | Cada módulo instalado (OCA o propietario) existe en versión 19, se ha instalado en staging y se ha probado con un caso de uso real | Un módulo que «figura como compatible» en su ficha no es lo mismo que un módulo probado con tus datos y tu flujo real |
| Entorno de staging | Réplica de producción con datos reales (no de demostración), donde se ha completado al menos un ciclo real: pedido, factura, cobro, stock, informe | Los fallos con datos de demo casi nunca reproducen los fallos con datos reales — volumen, formatos, casos límite |
| Plan de rollback | Backup verificado y procedimiento documentado y ensayado de vuelta al sistema anterior | Sin un plan probado, un problema imprevisto en las primeras horas de producción se convierte en una parada de operación sin salida clara |
| Ventana de mantenimiento | Franja horaria de bajo tráfico definida, comunicada al equipo y, si aplica, a clientes, con margen sobre el tiempo estimado | Un go-live sin ventana clara mezcla usuarios trabajando en el sistema mientras se migra, lo que multiplica el riesgo de inconsistencias |
| Formación del equipo | Cada usuario ha hecho, en staging, las tareas reales de su puesto de trabajo — no solo ha visto una demo | El primer día de producción no es el momento de aprender el sistema desde cero |
Los seis bloques, en detalle
1. Datos maestros limpios
Antes de fijar fecha de go-live, alguien del equipo — no solo quien migra — debería haber revisado contactos duplicados, productos sin código o con tarifas contradictorias, plantillas de impuestos correctas por país si hay operativa internacional, y que los saldos contables migrados cuadran con el sistema anterior. Migrar datos sucios a Odoo 19 no los limpia — solo los traslada a un sistema nuevo donde son más difíciles de detectar.
2. Módulos de terceros portados y probados
Cada módulo OCA o propietario que usa la empresa debe existir en versión 19 y haberse instalado y probado en staging con un caso de uso real del negocio, no solo con la instalación técnica limpia. Es habitual descubrir en producción que un módulo «compatible con 19» según su ficha falla con una combinación concreta de datos que nadie probó antes.
3. Entorno de staging validado con datos reales
El staging no sirve como validación si se prueba solo con datos de demostración. Hace falta una réplica de producción con datos reales — o una copia representativa — donde se haya completado al menos un ciclo entero: crear un pedido, facturarlo, cobrarlo, mover stock, generar los informes que el equipo usa cada semana. Es la única forma de encontrar antes del go-live los fallos que solo aparecen con volumen y casos reales.
4. Plan de rollback
Un backup reciente no es un plan de rollback — el plan incluye el backup verificado (restaurado y comprobado, no solo generado), y un procedimiento documentado paso a paso de cómo volver al sistema anterior si el go-live falla, con los roles de quién decide activarlo y en qué plazo.
5. Ventana de mantenimiento
El go-live necesita una franja horaria de bajo tráfico, comunicada con antelación al equipo y, si corresponde, a clientes, con margen de tiempo sobre la estimación técnica — las migraciones casi siempre tardan más de lo previsto. Hacer el cambio con usuarios trabajando en el sistema antiguo mientras se migra es una de las causas más comunes de datos inconsistentes.
6. Formación del equipo
La formación que sostiene un go-live no es un manual genérico ni una demo pasiva: es que cada persona haya ejecutado, en staging, las tareas concretas de su puesto de trabajo diario, y sepa a quién acudir si algo no coincide con lo que esperaba el primer día real.
Enlaces útiles dentro de FlexigoTech
Si prefieres que nos encarguemos de todo el proceso — datos maestros, módulos, staging, rollback y formación incluidos — nuestro servicio de migración a Odoo 19 cubre exactamente estos seis bloques antes de fijar fecha de go-live. Y si además necesitas cubrir procesos que Odoo estándar no resuelve — logística, compliance, marketplaces — puedes revisar nuestro catálogo de módulos antes de decidir qué migrar y qué sustituir.
Preguntas frecuentes
¿Qué es exactamente el go-live en una migración a Odoo 19?
El go-live es el momento en el que la base de datos migrada y probada en staging pasa a ser el sistema real de producción: el punto en el que el equipo empieza a trabajar sobre Odoo 19 y se desconecta o congela el sistema anterior. No es un evento técnico aislado, es el final de un proceso de validación (datos, módulos, entorno, plan de vuelta atrás y equipo formado) que debería haber empezado semanas antes.
¿Cuánto tiempo antes del go-live debo tener el entorno de staging listo?
Con margen suficiente para completar al menos un ciclo entero de pruebas con datos reales, no de demostración, antes de fijar la fecha: crear un pedido, facturarlo, cobrarlo, mover stock y generar los informes que el equipo usa cada semana. Si en ese ciclo aparecen incidencias hace falta tiempo para corregirlas y repetir la prueba, así que cuanto antes esté el staging operativo, menos presión hay sobre la fecha final.
¿Qué pasa si un módulo de terceros no está portado a Odoo 19?
Si el módulo no existe en versión 19, o existe pero nadie lo ha probado con datos reales, no debería marcarse como hecho en el checklist aunque el proveedor lo anuncie como compatible. Las opciones son probarlo tú mismo en staging con un caso real antes del go-live, sustituirlo por una alternativa nativa o un módulo equivalente, o posponer esa funcionalidad concreta sin bloquear el resto de la migración.
¿Es obligatorio tener un plan de rollback si todo se ha probado bien en staging?
Sí. Staging nunca reproduce el 100% de las condiciones de producción (volumen real de usuarios simultáneos, integraciones externas en vivo, picos de uso), así que el plan de rollback (backup verificado y procedimiento documentado de vuelta al sistema anterior) es lo que evita que un problema imprevisto en las primeras horas se convierta en una parada de operación sin salida clara.
¿Cómo sé si mi equipo está realmente listo para el cambio?
Cuando cada persona que va a usar Odoo 19 el primer día ha hecho, en staging y con datos reales, las tareas concretas de su puesto (no un manual genérico ni una demo pasiva) y sabe a quién acudir si algo no coincide con lo que esperaba. Una sesión teórica sin práctica sobre el entorno real casi nunca es suficiente para sostener el primer día de producción.
¿Quieres que revisemos tu checklist de migración antes del go-live?
Te ayudamos a repasar los seis bloques con tu caso real — datos, módulos, staging, rollback, ventana y equipo — antes de fijar la fecha. Escríbenos a comercial@flexigobe.com o llama al +34 616 809 504.