Migrar de un ERP viejo a Odoo sin frenar la operación

Nota técnica · Integración de sistemas

La pregunta que casi siempre llega primero es cuánto tarda la migración. Es la pregunta equivocada. La que importa es otra: cuántos días va a tener que dejar de facturar la empresa. Y la respuesta correcta a esa es cero.

En el parque de PyMEs argentinas hay una enorme cantidad de empresas que todavía operan sobre ERPs de los noventa y los dos mil. Funcionan. Facturan. Nadie los ama, pero el negocio depende de ellos, y ahí está exactamente el problema: lo que hace difícil cambiarlos no es su tecnología, es que la empresa no puede parar.

Por qué fracasa la migración de corte

El plan clásico es el "corte": se congela el sistema viejo un viernes, se migran los datos el fin de semana y el lunes todos trabajan en el nuevo. Es ordenado, es prolijo en un diagrama, y es donde se queman la mayoría de los proyectos.

Falla por una razón simple: no hay forma de probar de verdad hasta que es tarde. Por bien que se haya hecho el ambiente de prueba, el lunes aparecen los casos que nadie documentó — el cliente que factura con otro CUIT, el artículo que se vende por unidad pero se compra por caja, el descuento que un vendedor aplica "como siempre" y que nunca estuvo escrito en ningún lado. Y para cuando aparecen, volver atrás ya no es gratis: hay comprobantes emitidos en el sistema nuevo.

Peor todavía: el equipo que tiene que aprender la herramienta nueva es el mismo que está tratando de despachar los pedidos del día. El costo real de un corte no se mide en horas de consultoría, se mide en las semanas de operación degradada que vienen después.

La alternativa: que convivan

El enfoque que funciona es menos elegante y mucho más seguro: los dos sistemas vivos en paralelo durante la transición, con una regla clara de quién manda sobre qué.

Eso implica aceptar algo incómodo: durante un tiempo vas a tener la misma información en dos lugares. No es una falla del plan, es el plan. El trabajo consiste en que esa duplicación sea controlada — que para cada dato haya un sistema que es dueño de la verdad y otro que la recibe, nunca dos que la editan a la vez.

La pregunta de diseño no es "¿cómo migro más rápido?" sino "¿en qué momento la empresa depende de que esto salga bien?". Si la respuesta es "nunca", el plan es correcto.

Lo que hay que decidir antes de tocar nada

Antes de la primera línea de configuración hay que responder, dato por dato, quién es el dueño. El stock, ¿lo manda el ERP viejo o el nuevo? Los precios, ¿de dónde salen? Un cliente nuevo que entra por la web, ¿dónde se da de alta primero?

Esta conversación suele ser la parte más valiosa del proyecto y la que más incomoda, porque obliga a explicitar reglas de negocio que hasta ese momento vivían en la cabeza de dos o tres personas. Es común descubrir que dos áreas creían cosas distintas sobre el mismo proceso, y que venían funcionando igual porque el sistema viejo era lo suficientemente flexible como para dejar que cada una hiciera lo suyo.

El problema que nadie anticipa: los códigos no coinciden

En el papel, conciliar dos catálogos es cruzar dos listas por código de artículo. En la realidad no coinciden nunca. El ERP viejo tiene el código del modelo y la variante aparece en la descripción. El canal de venta tiene su propio código. Y alguien, en algún momento, cargó el mismo producto dos veces con un espacio de diferencia.

Hay que resolverlo con normalización y coincidencia aproximada, pero —y esto es lo importante— con una regla de qué hacer cuando la coincidencia no es segura. La tentación es dejar que el sistema elija la opción más probable. Es un error. Si hay una diferencia de talle o de color entre dos registros que parecen el mismo producto, lo correcto es frenar y pedir confirmación humana, aunque sea más lento.

Un sistema que adivina en silencio no avisa cuando se equivoca. El error aparece semanas después, en forma de un cliente que recibió otra cosa, y para entonces ya se replicó en cientos de registros.

En qué orden conviene migrar

No por módulos, como sugieren casi todos los planes. Por dolor. Lo primero que se migra es aquello que hoy le está costando plata o tiempo a la empresa, aunque sea la parte menos prolija de hacer. Eso tiene dos ventajas: el beneficio se nota temprano, y el equipo empieza a usar la herramienta nueva por voluntad propia en vez de por obligación.

La facturación, contra toda intuición, suele convenir dejarla para el final. Es lo más regulado, lo más riesgoso y lo que menos tolera un error. Mientras tanto puede seguir saliendo del sistema viejo sin que eso frene nada.

Lo que conviene exigirle a quien te lo proponga

Que te diga en qué momento exacto la operación corre riesgo, y qué pasa si ese día algo sale mal. Si la respuesta es "no va a salir mal", desconfiá. Si la respuesta es "seguís facturando por el sistema viejo hasta que el nuevo esté probado con datos reales", vas por buen camino.

Y que te deje escrito quién es dueño de cada dato. Ese documento vale más que el cronograma, porque el cronograma se va a mover y las reglas de negocio no.