Una migración a Odoo puede parecer un cambio técnico. En la práctica, suele ser una discusión sobre disciplina operativa: qué datos ayudan a vender, comprar, cobrar y servir mejor, y cuáles solo alimentan ruido. Mi tesis es sencilla: no deberías migrar años de datos inútiles solo porque existen. De hecho, cuanto más “completa” sea la copia, más probable es que arrastres errores, duplicados y deudas de proceso que luego se esconden detrás del nuevo sistema.
El verdadero riesgo no es perder datos. Es conservar los equivocados.
La escena real: cuando el dashboard miente
Imagina una pyme comercial con 40 personas, varias familias de producto y un equipo administrativo que vive entre hojas de cálculo y correos internos. En el panel todo parece razonable: ventas en curso, stock visible, pedidos “gestionados”. Pero en la realidad hay otro sistema paralelo: notas adhesivas, mensajes de WhatsApp, clientes duplicados y documentos que “ya se mirarán luego”.
Ese es el tipo de fricción que una migración a Odoo puede revelar o esconder. Si solo miras el dashboard, ves actividad. Si miras el trabajo real, ves excepciones. Y las excepciones son las que más tiempo consumen.
La pregunta correcta no es cuántos registros tienes, sino cuántos registros están vivos, cerrados o muertos. Un pedido abierto de hace dos años no es patrimonio de la empresa; a menudo es una anomalía que contamina informes, búsquedas y expectativas.
Qué limpiar, qué archivar y qué reconciliar
Antes de mover nada, conviene separar los datos en cuatro grupos:
- Lo que debe viajar porque sigue activo y afecta a la operación diaria.
- Lo que conviene archivar porque tiene valor legal, histórico o de trazabilidad, pero no debería mezclarse con el trabajo corriente.
- Lo que hay que reconciliar porque el dato existe en dos sitios y no coincide.
- Lo que puede quedar fuera porque ya no aporta decisión ni cumplimiento, aunque alguien se haya acostumbrado a verlo.
Aquí suele aparecer el primer error incómodo: tratar el archivo como una papelera. No lo es. Archivar significa conservar sin estorbar. Para la dirección, eso importa porque un sistema lleno de registros muertos ralentiza búsquedas, confunde al equipo y da una falsa sensación de precisión.
Odoo documenta que una actualización o migración no equivale a mover otra ERP a Odoo; también advierte que, si hay módulos personalizados, la compatibilidad de esos módulos debe estar lista antes de completar la actualización. Además, recomienda pedir primero una base de datos de prueba actualizada y probarla con tiempo, porque el proceso mejora cuando el salto entre versiones es menor. (odoo.com)
El error más caro: confundir limpieza con retraso
Muchos equipos posponen la limpieza porque temen que “revisar datos” retrase el proyecto. A veces sí lo retrasa. Pero ese retraso suele ser más barato que descubrir después que el nuevo ERP reproduce los mismos problemas, solo con una interfaz más moderna.
La regla práctica es esta: si un dato no puede explicarse en dos frases, probablemente no está listo para migrar tal como está. Eso vale para referencias de cliente, estados de pedido, catálogos antiguos, condiciones comerciales heredadas y direcciones que nadie usa desde hace años.
Un escenario muy común: ventas quiere mantener todo “por si acaso”, administración pide rigor, y operaciones solo quiere que el sistema no bloquee pedidos. Ese choque no se resuelve con más campos ni con una promesa de “ya lo depuraremos después”. Se resuelve con criterios visibles:
- ¿Se usa en una decisión semanal?
- ¿Tiene dueño claro?
- ¿Se puede validar contra una fuente fiable?
- ¿Afecta a cobro, entrega o cumplimiento?
Si la respuesta es no en tres de cuatro preguntas, no está listo para pasar como dato vivo.
Un experimento reversible antes del cambio grande
No hace falta abrir un programa gigantesco para empezar bien. Una prueba pequeña y reversible suele decir más que veinte reuniones.
El experimento que proponemos es simple: escoger una sola familia de datos, por ejemplo clientes o productos, y construir tres listas antes de la migración piloto: activos, a archivar y a revisar manualmente. Después, comprobar qué porcentaje falla en conciliación, qué campos faltan y cuánto tiempo tarda el equipo en resolver dudas.
Ese ejercicio enseña algo importante: no se trata de “migrar mejor”, sino de operar con menos incertidumbre. Si el piloto reduce llamadas internas, correcciones manuales y re-trabajos, ya tienes una señal útil. Si no, el problema no es la herramienta; es la calidad de la decisión previa.
En una mini-situación habitual, una empresa descubre que el 12% de sus fichas de cliente están duplicadas. No necesita una gran transformación para empezar; necesita decidir quién es el dueño de cada registro y qué versión del dato manda. Esa decisión, más que el software, es lo que ordena el trabajo.
Qué se lleva la dirección de verdad
La migración a Odoo no debería juzgarse por lo “limpio” que quede el sistema el primer día, sino por si el equipo deja de depender de atajos para operar. Un ERP nuevo no corrige por sí solo una organización desalineada. Pero sí obliga a hacer visible lo que antes se tapaba con costumbre.
Si la empresa aprovecha la migración para eliminar datos muertos, archivar con criterio y probar con un caso pequeño, gana dos veces: reduce el riesgo técnico y mejora la calidad de la operación desde el inicio.
Tres acciones realistas para esta semana:
- Revisa una sola tabla crítica y marca qué campos no se usan en ninguna decisión.
- Pide al equipo que identifique tres tipos de registros que deberían archivarse y no viajar como activos.
- Elige un conjunto pequeño de datos para una prueba de conciliación y mide cuánto tiempo cuesta resolver las discrepancias.
Si te interesa, en Codefuente solemos empezar precisamente por esa parte incómoda: decidir qué datos merecen seguir vivos y cuáles solo ocupan sitio.