Rescate Odoo: migración sin pérdida de datos cuando la configuración está rota

Por qué 2026 es el año del rescate Odoo en LATAM

De 60 implementaciones Odoo que revisé en LATAM en los últimos ocho años, 47 eran rescatables sin reinstalar, sin migrar a SAP y sin perder una sola fila de datos. Este artículo es el mapa de cómo se hace, en qué orden y cuándo conviene dejar el paciente en paz.

El partner desaparece. El contador cierra el mes a mano en Excel. El CFO mira el presupuesto de migración a SAP Business One y firma sin volver a mirar. Esa es la escena típica con la que llega un PYME latinoamericano a pedir un rescate Odoo, y nueve de cada diez veces la operación sale mejor que la promesa del proveedor que viene a venderle un ERP nuevo.

Resumen en un minuto

• 78% de los Odoo rotos se rescatan. De 60 casos revisados en Perú, México, Colombia, Chile y Argentina, 47 se repararon en 4-12 semanas, contra 4-6 meses de reimplementación.
• El problema casi nunca es Odoo. En 73% de los casos la raíz es entrenamiento deficiente del equipo más localización fiscal abandonada (l10n_pe, l10n_mx, l10n_co, l10n_cl, l10n_ar).
• Migrar sin perder datos es la norma, no la excepción. Con un pipeline serio (snapshot read-only → staging → diff → cutover) la pérdida queda acotada a campos que el propio cliente reconoce como basura.
• La ventana de decisión son 5 días. El triaje define si caes en el 78% rescatable, en el 15% de reset, o en el 7% donde lo honesto es cambiar de ERP.
• El costo del rescate es 4-8 veces menor que reinstalar desde cero o migrar a SAP Business One.
• La mejor inversión previa es una auditoría independiente de 5 días: cuesta como mínimo 30 veces menos que abrir un proceso de selección de ERP nuevo.

Antes de pasar al método, vale la pena fijar qué es un rescate, por qué este año concreto reventaron tantos partners simultáneamente, y cómo se mide el éxito del proceso. Es la diferencia entre tirar plata en consultoría y operar sobre un sistema vivo sin pararlo.

Qué es "rescate Odoo" y por qué este año tronó

Un rescate Odoo no es un upgrade, no es una implementación nueva y no es una migración en sentido clásico. Es un procedimiento híbrido para devolver a producción una instancia Odoo que el partner anterior dejó inutilizable o medio funcionando. El objetivo no es reinstalar: es mover el estado desde la configuración rota hasta una configuración correcta sin tocar el 100% del dato útil — clientes, documentos, saldos, movimientos históricos y adjuntos.

2026 concentró el pico por cinco motivos regulatorios independientes que se alinearon casi al mismo tiempo:

• Perú — SUNAT. Paso integral al SIRE (Sistema Integrado de Registros Electrónicos) obligatorio para todo sujeto que lleve libros electrónicos. En paralelo, rollout por fases de la GRE (Guía de Remisión Electrónica) y endurecimiento de validaciones CPE. Multa: hasta 50% de la UIT por documento no presentado. La nuestra guía Odoo Perú trae el detalle por fase.
• México — SAT. Carta Porte 3.1 más validación real-operations de CFDI 4.0 rompen cualquier integración que antes "pasaba" sin validar campos a fondo. Los certificados PAC cambian de comportamiento al inicio de 2026.
• Colombia — DIAN. Nómina electrónica y documento equivalente reescribieron la lista de campos obligatorios. Nómina mal reportada pierde deducibilidad: hasta USD 15 000 al año de impacto para un PYME mediano.
• Argentina — ARCA. En 2024 AFIP pasó a llamarse ARCA (Agencia de Recaudación y Control Aduanero). El Régimen de Transparencia Fiscal y la revisión del monotributo en dos ventanas estacionales (enero, agosto) obligan a reajustar los hooks contables.
• Chile — SII. Boleta electrónica con formato DTE actualizado, más reglas nuevas para libro de compras y ventas.

Cada cambio por separado es menor. El problema es que un Odoo con 2 000 líneas de código custom y un l10n_xx desactualizado los recibe a todos a la vez. El partner que escribió ese custom durante tres años desaparece. El equipo entra en pánico. El CFO ve el presupuesto de migración a SAP en USD 80 000 y firma. Ese es el punto exacto donde rescatar Odoo es más barato y más rápido que cualquier alternativa — siempre que se sepa qué reparar y en qué orden.

Migración sin pérdida de datos: el pipeline en 6 pasos

El método se apoya en un principio único: nunca tocar producción hasta que staging haya pasado validación completa. Abajo el pipeline que aguantó 47 rescates seguidos sin perder una fila.

#1. Snapshot read-only y auditoría (5 días)

• pg_dump --format=custom --no-owner de la base productiva, restaurado en un staging aislado de la misma versión mayor de Odoo.
• Copia paralela del filestore (~/.local/share/Odoo/filestore/<dbname>/) — sin esto, los adjuntos se vuelven links rotos al migrar.
• Auditoría de 12 áreas: estado de módulos instalados, código custom, hooks fiscales, cron-jobs, integraciones, datos huérfanos, seguridad, performance, backups, documentación, formación y bus factor.
• Inventario del custom: contar líneas, buscar tests (normalmente cero), revisar el último commit en git y medir acoplamiento con el core.

Salida: un plan de una página con 3-5 must-fix, 5-10 should-fix, 5-10 nice-to-have, todo a precio cerrado.

#2. Estabilización de la localización fiscal

Es el frente donde 41 de 60 casos colapsan. Checklist mínimo:

• Versión actual de l10n_xx instalada (por ejemplo l10n_pe_edi para Perú, l10n_mx_edi para México, l10n_co_dian para Colombia).
• Hooks de cálculo de impuestos parchados después de la última reforma.
• Cron-jobs de envío al regulador alineados con las ventanas correctas — SUNAT, DIAN y SAT aceptan en horarios distintos.
• Retries con backoff exponencial; sin eso, el primer 503 del regulador deja todo el pipeline parado.
• Cola de dead-letter para documentos que fallaron tres veces seguidas.
• Certificado digital firmado y con vencimiento mayor a 60 días.

En 95% de los rescates esta sección se reescribe desde cero, pero sin borrar datos: solo configuración y la envoltura alrededor de los registros existentes.

#3. Quick wins (semanas 2-3)

Al cierre de la segunda semana el equipo y el CFO tienen que ver una diferencia tangible. Wins habituales:

• Borrar cron-jobs zombi (típico: 11 activos, sirven 3).
• Restablecer recepción de facturas electrónicas tras la reforma fiscal.
• Limpiar el top-N de partners duplicados — el caso típico es clientes cargados tres veces con distintas mayúsculas.
• Reindex Postgres más VACUUM ANALYZE — quita hasta 60% de la latencia sin cambiar una línea de código.
• Desinstalar módulos sin uso (suele haber 20-40 en installed, en uso real 12-18).

Garantía contractual: si en 2 semanas no hay diferencia visible, se devuelve el dinero. En 47 rescates nadie ejerció la cláusula.

#4. Reparación profunda (semanas 4-8)

Trabajo que no se puede hacer en producción:

• Refactor del custom. Meta: bajar 50-80% las líneas custom. Lo que Odoo hace nativo no debería estar reescrito. Es común que 2 400 líneas se reduzcan a una configuración Studio más 3-4 server actions.
• Limpieza de datos. Scripts SQL para fusionar duplicados con el wizard de res.partner, reconstruir relaciones BoM y arreglar contraparte en asientos contables. Cada script se valida primero en staging.
• Recompilación de integraciones con retries, idempotency keys y colas dead-letter. Crítico para bancos, marketplaces y reguladores.
• Tests CI para todos los módulos custom. Como mínimo smoke-tests de carga y acceso. Sin ellos, el próximo upgrade vuelve a romper.

#5. Cutover sin pérdida de datos

El momento más sensible. Esquema:

1. 24 horas antes del cutover: freeze de cualquier cambio de configuración en producción.
2. Diff staging vs prod — qué se agregó entre el snapshot y el momento actual (típico: 1 000 a 10 000 filas nuevas en account.move, stock.move, mail.message).
3. Aplicar el delta — scripts de importación de documentos nuevos, usuarios y adjuntos.
4. Ventana de cutover en horario nocturno de fin de semana. Producción se conmuta a la configuración nueva.
5. Smoke-test de 20 operaciones clave: factura, despacho, payment matching, reporte y envío al regulador.
6. Plan de rollback: pg_dump tomado antes del cutover. En 4 horas se vuelve atrás si algo cruje.

#6. Re-training y hand-off (semanas 9-12)

Nada de videos en una biblioteca que nadie abre. Sesiones en vivo, tres por rol (contador, ops, ventas), grabadas, acompañadas de un runbook en Notion con 18 escenarios típicos: "qué hacer si SUNAT no acepta la boleta", "qué hacer si el cron cae", "cómo dar de alta a un usuario nuevo".

Al cerrar, se entregan: el código fuente en el repositorio git del cliente, los accesos, la documentación, y — lo que distingue a un rescate serio del partner promedio — el contacto de un ejecutor alternativo, por si el cliente no quiere quedarse atado al mismo proveedor durante años.

El paciente sigue vivo porque nadie intentó hacerle un trasplante de corazón en la mesa de la cocina. La cirugía mayor va a staging; en producción solo se aplican los puntos de sutura ya ensayados.

5 errores típicos de migración que pierden datos

Casi todas las pérdidas de datos que vi vienen de los mismos cinco vicios. Ninguno es un bug del producto: son decisiones humanas, casi siempre tomadas para "ahorrar tiempo". Si tu plan de migración tiene cualquiera de estos, devuélvelo al remitente. Más contexto en el checklist de migración de la sección de recursos.

#1. Intentar upgrade de Community con la herramienta Enterprise

El upgrade.odoo.com oficial corre con licencia Enterprise. Community con módulos custom necesita pedido explícito o OCA/OpenUpgrade. Pasar un dump Community por el pipeline Enterprise sin acordarlo se acaba con campos custom descartados: lo que la herramienta no conoce, lo tira.

Qué hacer: para Community usar OpenUpgrade con dry-run previo en staging. Los scripts de migración se revisan antes de correr en producción.

#2. Migrar entre versiones mayores con backup-restore

Bajar un .zip de Odoo.sh y restaurarlo en una base de la versión siguiente es pérdida de datos prácticamente garantizada. Entre 16.0 y 18.0 decenas de campos cambiaron de nombre, fueron eliminados o se movieron a otro modelo. Sin scripts de migración los datos se descartan o "se filtran" al campo equivocado (por ejemplo partner.name aparece en partner.commercial_company_name).

Qué hacer: el servicio Enterprise upgrade o OpenUpgrade con scripts por cada transición de versión. No se "saltan" versiones mayores.

#3. Mover el filestore sin validación de hash

En Odoo cada adjunto se guarda con nombre-hash SHA1. Si la copia del filestore queda incompleta, los adjuntos figuran en la base pero los archivos no existen en disco. Todo parece funcionar hasta que alguien hace clic en "descargar". A los tres meses el contador descubre que la factura del 2024 ya no se abre.

Qué hacer: después de copiar el filestore, correr un SQL contra ir_attachment que valide la existencia de cada archivo en disco. Los faltantes se recuperan del backup antes del cutover.

#4. Desactivar la localización fiscal "mientras dura la migración"

Es el error clásico del partner que quiere "simplificar". El l10n_xx apagado deja los hooks registrados, pero estos arrancan sin contexto y disparan excepciones. Parte de los documentos en ese periodo nunca llega al regulador. Un mes después, SUNAT, DIAN o SAT manda una notificación de divergencia. La multa se suma por todos los documentos no entregados.

Qué hacer: la localización no se desactiva. Se actualiza in-place; en el peor caso se pausa el cron de envío y se deja el hook activo solo para logging.

#5. Bus factor 1 sobre la propia migración

Un desarrollador recuerda qué manipulaciones de base de datos hay que correr para el siguiente upgrade. Si renuncia entre fases, la migración se vuelve arqueología. Paciente en coma, operación a medio terminar.

Qué hacer: todos los pasos van al runbook antes de empezar. Cada script versionado en git. Cada decisión la firman al menos dos personas. Bus factor mínimo 2 como condición de arranque.

Caso anónimo: PYME-retail en Lima, 80 empleados

El cliente llegó con la frase: "migración a SAP B1 en dos meses, ¿qué opinas?". Presupuesto de la migración: USD 65 000 de implementación más USD 1 800 por usuario al año de licencias. El partner Odoo llevaba siete semanas sin responder. La contadora cerraba el mes a mano en Excel.

El triaje detectó cinco must-fix:

1. l10n_pe_edi de hace dos años, incompatible con la API actual del SIRE.
2. 11 cron-jobs: 6 fantasmas de módulos desinstalados, 2 corriendo cada minuto y comiéndose ~30% de CPU.
3. 4 200 líneas de código custom para funciones que Odoo Enterprise 17+ resuelve nativamente.
4. 1 743 partners duplicados — clientes cargados de nuevo cada vez que fallaba la validación SUNAT, basura acumulada por meses.
5. Un solo empleado "recordaba" cómo reparar e-invoices fallidos a mano. Sin él, la operación se paraba.

Plan: 10 semanas, USD 14 200 a precio cerrado. Incluye triaje, quick wins, reparación profunda, re-training y hand-off.

Resultado en la semana 10:

Todos los clientes, documentos y saldos quedaron validados con un script de reconciliación (count + checksum sobre 12 tablas clave). El CFO firmó una carta de agradecimiento. La migración a SAP Business One se canceló. Ahorro neto: USD 50 000+ de CAPEX y un número incalculable de horas de equipo.

Checklist: ¿está su Odoo listo para rescate?

Si en tu Odoo se cumplen al menos tres de estos diez puntos, vale la pena reservar 30 minutos para un triaje gratuito. La conversación dura lo que tarda un café y define si tu caso es de los rescatables o de los que necesitan otro enfoque.

1. El equipo se queja de que "Odoo va lento".
2. El partner no responde hace más de 4 semanas.
3. El regulador (SUNAT, DIAN, SAT, SII, ARCA) rechaza facturas más de una vez por semana.
4. El cierre contable mensual toma más de 7 días hábiles.
5. Menos de 3 personas en la empresa entienden la configuración.
6. Hay más de 1 000 líneas de código custom y cero tests automatizados.
7. Hay más de 8 cron-jobs y no existe documentación de qué hace cada uno.
8. El CFO está evaluando seriamente migrar a SAP, Oracle u otro ERP "grande".
9. El último upgrade fue hace más de 18 meses.
10. El filestore pesa más de 50 GB y no hay política de ciclo de vida.

Descargar el template completo de auditoría (PDF) — 38 puntos de revisión, listo para imprimir y completar en una mañana.

Rescate Odoo vs migración a SAP Business One: la cuenta real

La conversación con el CFO normalmente arranca en el precio de licencias, que es la parte menos interesante. La diferencia estructural es el TCO a 24 meses incluyendo implementación, licencias, hardware, formación y costo de oportunidad por downtime.

El número que más sorprende al CFO no es el precio de las licencias: es la continuidad histórica. En un rescate Odoo, los registros de los últimos 5 años quedan donde estaban, con los mismos ids y las mismas trazas de auditoría. En una migración a SAP, se vuelven a cargar como datos de apertura — y la trazabilidad se rompe en la fecha del corte. Para una empresa con auditoría externa, la diferencia es un costo escondido que rara vez aparece en la cotización original.

Preguntas frecuentes