Migración a Odoo. Sin big-bang. Sin perder datos.
Migramos PYMES LATAM desde SAP B1, ContPaqi, Siigo, Alegra, Manager.io, Holded, NetSuite, Adminpaq, Aspel y Excel hacia Odoo. Cutover controlado en un fin de semana. Cero pérdida de datos contables. Tu equipo sigue operando hasta el lunes — el lunes están en Odoo.
El servicio, en cuatro frases.
Para los que llegaron desde LinkedIn y solo tienen 30 segundos. Si quieres profundidad, sigue scrolleando.
La migración no es «exportar a CSV y subir».
Es 6 fases — extract → clean → map → load → validate → cutover — con sprints de 2 semanas. Cada sistema origen tiene sus trampas: SAP B1 oculta asientos en HANA, ContPaqi exporta sin secuencias, Siigo cambia su API cada release. Lo hemos visto 60+ veces.
Cutover controlado el sábado · go-live domingo.
Tu equipo cierra ventas el viernes 17:00. Sábado 22:00 te aviso por WhatsApp: «Odoo está en vivo, reconciliación validada por contador, plan B preparado». Lunes 9 AM tu equipo opera en Odoo. Sin migración «en caliente».
Reconciliación contable pre/post.
Validación doble: cifras del sistema viejo vs cifras de Odoo en el cierre del último período. Si difieren > 0.1%, el cutover se pospone una semana. No saltamos al go-live con datos sucios.
Plan rollback de 24 horas.
Si el lunes a las 11 AM tu CFO encuentra algo crítico — volvemos al sistema viejo en < 4 horas. Datos backed-up, accesos preservados, runbook listo. Riesgo asimétrico bajo del lado del cliente.
Por qué llegaste aquí.
- 01
Asientos sin contrapartida.
Sistema viejo migrado «como vino» tiene asientos huérfanos. Odoo no los acepta. Soluciones: o se rechazan (saldo histórico se rompe) o se invierten manualmente (semanas).
~3–8% filas - 02
Cuentas mal mapeadas.
El plan de cuentas SAP B1 no calza 1:1 con l10n_xx oficial de Odoo. Mapping a mano + tabla de equivalencias firmada por contador.
~100 mappings - 03
Secuencias rotas.
Facturas numeradas 0001, 0002, 0004 (falta 0003 borrada). SUNAT/DIAN/SAT no tolera gaps. Reconstrucción retroactiva obligatoria.
0 tolerancia - 04
Clientes y productos duplicados.
El mismo cliente con 3 RUCs ligeramente distintos (Sociedad SA, SOCIEDAD S.A., sociedad sa). Productos con SKU duplicados o sin SKU.
~12% sucio - 05
Sin ensayos previos · big-bang directo.
Migración hecha de una sola pasada en producción. Si falla, no hay vuelta atrás sin recuperar backup de 48 h antes.
0 rollback - 06
Operación bloqueada durante cutover.
El partner anuncia «migración lunes 9 AM», tu equipo facturando para el cliente USA queda parado 4 días. Pérdida de USD 14k por hora bloqueada.
4–12 días
Lo que construimos contigo.
No vendemos plantillas — construimos capas finas que comunican lo que ya existe.
Mapping table por sistema origen · firmada por contador
Mapping de entidades origen → entidades Odoo. SAP B1 → Odoo 17: 86 entidades, 412 campos. Validado por contador antes del primer dry-run.
Cutover plan visual · minuto a minuto sábado-domingo
Cada hora del cutover documentada. Sábado: cierre + backup + migración + reconciliación. Domingo: smoke tests + soft launch + go-live oficial.
Reconciliación contable · pre / post validada por contador
Cifras del sistema viejo vs Odoo cuenta por cuenta. Si difieren > 0.1%, cutover se pospone. Tu contador firma el go/no-go.
Rollback plan · firmado antes del cutover
Si el lunes 11 AM tu CFO encuentra algo crítico, volvemos al sistema viejo en < 4 horas. 0 rollbacks ejecutados en 60+ migraciones — pero el plan existe siempre.
Migration journey · 10 sistemas origen, 10 trampas distintas
Scrollea — cada paso muestra un sistema origen, su tabla principal, su trampa típica, y cómo mapeamos a Odoo. Esto es la experiencia de migrar 60+ PYMES.
- 01
01 · SAP Business One — HANA SQL + tablas OXXX
Volume: medio-alto. Trampa: Mapping plan de cuentas SAP → l10n_xx. 86 entidades, 412 campos. Asientos en HANA + Crystal Reports export.
- 02
02 · NetSuite — SuiteScript permission gates
Volume: alto. Trampa: Acceso programático a transactions + custom records. Stale data en sandboxes. SOAP endpoints rate-limited.
- 03
03 · ContPaqi / Adminpaq — DBF + XML proprietary
Volume: medio. Trampa: Reconstrucción de secuencias CFDI 3.3 → 4.0. Doble entrada contable. Carta Porte 3.1 si aplica.
- 04
04 · Aspel SAE — Local DB + exports a CSV
Volume: bajo-medio. Trampa: Bonos personalizados que viven solo en interfaces. Doble registro inventario.
- 05
05 · Siigo (Colombia) — API rate limit + multi-empresa
Volume: medio. Trampa: Nómina electrónica DIAN. CUFE histórico preservado. Multi-empresa fragmentada.
- 06
06 · Alegra — API limitada + facturas en CSV
Volume: bajo. Trampa: Migración PE/CO/MX dispersa. Conciliación bancaria fragmentada. Adjuntos en URLs externas.
- 07
07 · Manager.io / Bejerman / Tango — Single user · backup desk
Volume: bajo. Trampa: Catálogo de productos sin SKU formal. Mapping cuentas LATAM no estándar.
- 08
08 · Holded — SaaS API · time-out en exports
Volume: bajo. Trampa: Facturación electrónica EU vs LATAM. Re-tagging de cuentas.
- 09
09 · Defontana (Chile) — l10n_cl historial DTE/CAF
Volume: medio. Trampa: Conservación CAF folios. Validación SII histórica. Boletas vs DTE.
- 10
10 · Excel + facturador externo — Sin ontología
Volume: variable. Trampa: Sin SKU formal. Limpieza masiva. Definición plan de cuentas desde cero. Eso es 30% del proyecto.
Cómo está armado.
Extract
Cómo sacamos del sistema origenClean
Cómo limpiamos antes de cargarLoad
Cómo cargamos en OdooValidate + Reconcile
Cómo aseguramos que todo cuadraLos números reales.
Métricas observadas en proyectos concretos. Baseline antes vs estado después de la intervención.
«Lo que me ahorró el sueño fue saber que había plan B firmado el viernes antes del cutover. Nunca lo activamos — todo funcionó. Pero saber que existía cambió cómo dormí el sábado.»
Tres preguntas reales — y mis respuestas honestas.
¿Puedo migrar yo mismo descargando los CSVs?
Técnicamente sí — pero los 6 puntos de fallo (asientos huérfanos, secuencias rotas, mapping cuentas, duplicados, validación referencial, reconciliación contable) son donde mueren las migraciones DIY. Es como hacer cirugía tú mismo — posible, no recomendable.
¿Y si mi partner anterior bloquea los exports?
Pasa. Tenemos plan B legal: SLA contractual obliga al partner a entregar exports en formato estándar. Si no lo hace, hay vía judicial. He visto 3 casos así — los 3 terminaron con exports entregados en 14 días.
¿Migran mi data histórica completa o solo lo último?
Recomiendo migrar 3 años de transaccional + 5 años de maestros + resúmenes anuales del histórico anterior. Migrar 10 años transaccional típicamente no aporta valor decisional y triplica el plazo.
Qué entregamos, sin sorpresas.
- Extract desde el sistema origen (API, dumps SQL, DBF, XML, CSV, CFE folders)
- Limpieza y deduplicación (fuzzy match RFC/RUC + nombre + email)
- Mapping del plan de cuentas origen → l10n_xx oficial, firmado por contador
- 2 dry-runs completos en sandbox antes del cutover real
- Reconciliación contable pre/post (tolerancia < 0.1%)
- Cutover controlado fin de semana con plan minuto a minuto
- Runbook de rollback firmado · plan B de 24 horas
- Hypercare 2 semanas post go-live (WhatsApp 24/7)
El proceso en 5 pasos.
- 01
Discovery (1 sem)
Mapeamos sistema origen, volumen, custom fields, integraciones vivas.
- 02
Extract + Clean (2–4 sem)
Pipeline ETL desde el origen. Deduplicación, validación referencial, tabla de mapeo.
- 03
Dry-run × 2 (2–3 sem)
Dos ensayos completos en sandbox. Reconciliación contable validada por tu contador.
- 04
Cutover fin de semana
Sábado: backup final, migración batch, reconciliación. Domingo: smoke tests, go-live.
- 05
Hypercare (2 sem)
Daily standup, WhatsApp 24/7, métricas de adopción. Rollback armado por si acaso.
La migración no es «exportar a CSV y subir»
Lo más común que vemos: el partner promete migración «sencilla», exporta 4 CSVs, los sube a Odoo en bruto, y a los 2 meses tu contador descubre que la cuenta 1101 tiene un saldo de S/ −482 000 que nadie sabe de dónde salió.
Una migración real son 6 fases — extract → clean → map → dry-run → reconcile → cutover — con sprints de 2 semanas.
Cutover controlado de fin de semana
Tu equipo cierra ventas el viernes 17:00. Sábado 22:00 te aviso por WhatsApp: «Odoo está en vivo, reconciliación validada por contador, plan B preparado por si algo». Lunes 9 AM tu equipo opera en Odoo. Sin migración “en caliente”.
Reconciliación contable pre/post
Validación doble: cifras del sistema viejo vs cifras de Odoo en el cierre del último período. Si la diferencia agregada supera 0.1%, el cutover se pospone una semana. Tu contador firma el go/no-go.
Plan rollback de 24 horas
Si el lunes a las 11 AM tu CFO encuentra algo crítico — volvemos al sistema viejo en menos de 4 horas. En 60+ migraciones nunca lo activamos. Pero saber que existía cambió cómo durmieron muchos CFOs el sábado del cutover.
10 sistemas origen probados
SAP Business One · NetSuite · ContPaqi/Adminpaq · Aspel SAE · Siigo · Alegra · Manager.io/Bejerman/Tango · Holded · Defontana · Excel + facturador externo.
Preguntas que recibo cada semana.
¿Cuánto downtime tendré durante el cutover?
Objetivo < 4 horas. En 60+ migraciones la media real es 3.2 h. El equipo cierra ventas el viernes 17:00 y opera en Odoo el lunes 9 AM.
¿Qué pasa si la reconciliación contable no cuadra?
Si la diferencia entre el sistema viejo y Odoo supera 0.1% en el cierre del último período, el cutover se pospone una semana. No saltamos al go-live con datos sucios.
¿Migran mi data histórica completa o solo lo último?
Recomiendo 3 años de transaccional + 5 años de maestros + resúmenes anuales del histórico anterior. Más de 10 años transaccional típicamente no aporta valor decisional.
¿Y si mi sistema origen no está en tu lista de 10?
Lo evalúo en 30 min. He visto Bejerman, Tango, software custom de 1998. El factor crítico no es el sistema — es si puedo extraer datos.
¿Hacen migración solo, sin reconfigurar Odoo en destino?
Sí, si tu Odoo ya está configurado bien. Si no, propongo migración + implementación combinada en un paquete cerrado.
¿Te suena familiar? Hablemos.
Empezamos siempre con una llamada de 30 minutos. Sin formularios largos — agenda directa.