La Llamada Que No Quiero Volver a Recibir

Hace unos años, una empresa de distribución a la que asesoraba puso en marcha un nuevo ERP durante un fin de semana largo. El lunes por la mañana, el equipo de cuentas por pagar descubrió que cuarenta facturas de proveedores se habían migrado dos veces: mismo número de factura, mismo monto, registradas como dos pasivos distintos. El equipo de ventas encontró el problema inverso: casi trescientos registros de clientes se habían fusionado incorrectamente durante la importación, de modo que pedidos abiertos quedaron repartidos entre dos números de cuenta distintos para el mismo cliente. Tomó seis semanas de limpieza manual, dos reuniones generales bastante tensas y la pérdida de una relación comercial para resolverlo por completo.

Nada de esto pasó porque el software nuevo fuera malo, sino porque nadie trató la migración de datos como un proyecto con plan, pruebas y criterios propios de continuar o detener. La migración de datos para pymes suele tratarse como una casilla dentro de un proyecto de software más grande, cuando debería ser lo que más preocupe.

He ejecutado este proceso suficientes veces —cambios de ERP, consolidaciones de CRM, reemplazos de aplicaciones a medida— como para tener una opinión clara: migrar los datos suele ser más difícil que cualquiera de los sistemas involucrados. Este es el marco que uso para que un cambio de sistema no termine en un proyecto de limpieza.

Por Qué Fallan las Migraciones, en Realidad

Antes de entrar en el marco de trabajo, vale la pena nombrar los puntos reales de falla, porque casi nunca tienen que ver con que la tecnología sea poco confiable.

  • Nadie es dueño de la calidad de los datos en el origen. Años de carga manual y un "ya lo arreglamos después" dejan el sistema viejo lleno de duplicados, formatos inconsistentes y registros huérfanos.
  • El mapeo de campos se trata como un detalle menor. Un campo "estado" en el CRM viejo casi nunca significa lo mismo que en el nuevo, y nadie lo valida hasta que los datos ya están cargados.
  • Las pruebas se hacen sobre una muestra, no sobre todo el conjunto. Los casos límite —el cliente con tres identificaciones fiscales, el pedido con cantidad negativa— se esconden en el último 5% de los registros y solo aparecen en producción.
  • No existe un plan de reversión real. Los equipos asumen que el sistema viejo "seguirá ahí" si algo sale mal, sin un procedimiento probado para revertir de verdad.

Las estimaciones del sector varían, pero coinciden en que bastante más de la mitad de los proyectos de migración exceden presupuesto o plazo. Sea el número real 40% u 80%, el patrón es el mismo: las migraciones fallan por el proceso, no por la herramienta.

Paso 1: Auditar y Limpiar los Datos de Origen Primero

No dejo que un cliente empiece a mapear campos sin antes perfilar los datos de origen. Eso significa correr reportes de detección de duplicados, tasas de valores nulos en campos obligatorios, claves foráneas huérfanas y formatos inconsistentes (tres formatos de fecha distintos en una misma columna es más común de lo que parece).

Este es también el momento de decidir qué realmente necesita migrar. No todos los registros de un sistema de quince años merecen un lugar en el nuevo:

  • Archivar clientes inactivos y pedidos cerrados más antiguos que el requisito legal de retención, en vez de migrarlos en vivo.
  • Deduplicar antes de mapear, no después: fusionar duplicados tras la carga obliga a desenredar también el historial de transacciones.
  • Asignar un dueño de datos del lado del negocio, no solo de IT, para las decisiones sobre registros ambiguos.

Saltarse este paso es la razón número uno por la que las migraciones se salen de presupuesto, porque la limpieza descubierta a mitad de proyecto siempre cuesta más que la limpieza hecha desde el principio.

Paso 2: Mapear los Campos y Construir el Proceso ETL con Cuidado

Una vez que los datos de origen están limpios, hay que mapear explícitamente cada campo entre el sistema viejo y el nuevo, incluyendo los campos que parecen obvios. He visto un menú desplegable de "tipo de cliente" con cuatro opciones en el sistema viejo mapearse a un campo con siete opciones en el nuevo, asignando en silencio a los valores no mapeados la primera opción por orden alfabético. Nadie lo notó hasta que, un mes después, las comisiones de ventas se calcularon mal.

Un proceso sólido de extracción, transformación y carga para una migración de pyme normalmente incluye:

  • Extraer los datos hacia un formato intermedio neutral (archivos planos o una base de datos temporal), en vez de transformar directamente de un sistema a otro.
  • Transformar los datos en esa capa intermedia —normalizando formatos, aplicando reglas de negocio, resolviendo duplicados— donde se puede inspeccionar y volver a ejecutar sin riesgo.
  • Cargar en lotes controlados, empezando por los datos de referencia (catálogo de productos, plan de cuentas) antes que los transaccionales (pedidos, facturas) que dependen de ellos.

Los sistemas heredados sin una API utilizable se convierten aquí en un cuello de botella real: si la plataforma vieja solo exporta mediante un reporte manual poco práctico, la extracción será lenta y propensa a errores sin importar qué tan bueno sea el proceso de transformación. Trato esta dependencia en modernización de sistemas heredados, y las limitaciones de integración que describo en integración de API a medida aplican directamente al trabajo de extracción en una migración.

Paso 3: Correr Ambos Sistemas en Paralelo Antes de Comprometerse

Este es el paso que más se saltean las pymes, generalmente por costo o impaciencia, y es en el que más insisto cuando un cliente quiere recortarlo.

Correr en paralelo significa operar el sistema viejo y el nuevo lado a lado durante una ventana definida —al menos un ciclo completo de negocio: un cierre de mes, un ciclo de facturación, una corrida de nómina— y hacer que los usuarios reales trabajen en ambos y comparen resultados. Cuesta más en el corto plazo, pero evita descubrir que los cálculos de impuestos están mal después de terminada la temporada fiscal.

Para una migración de pyme más pequeña, una corrida en paralelo comprimida de dos a tres semanas, enfocada en los tipos de transacción de mayor riesgo (facturación, nómina, conteos de inventario), suele bastar, siempre que se elijan las transacciones cuyo error dolería más.

Paso 4: Reconciliar los Datos, No Solo Mirarlos por Encima

La validación tiene que ser sistemática, no un gerente revisando una planilla en busca de algo raro. Como mínimo, hay que construir:

  • Reconciliación de cantidad de registros entre origen y destino, para cada tabla o entidad.
  • Comparación de sumas de control o valores totales en los datos financieros —facturas abiertas, valor de inventario, cuentas por cobrar— antes y después de la migración.
  • Verificaciones de integridad referencial, para confirmar que cada pedido apunte a un cliente válido y cada línea a un producto válido.
  • Revisión puntual de reglas de negocio, no solo de la presencia de datos: ¿el sistema nuevo calcula recargos por mora, descuentos e impuestos igual que el viejo, con los mismos datos de entrada?

Definí umbrales de aceptación explícitos antes de empezar: por ejemplo, los totales financieros deben coincidir exactamente, y la cantidad de registros debe coincidir dentro de una variación documentada y explicada. Criterios vagos como "se ve bien" son la forma en que las migraciones terminan aprobadas con pérdida silenciosa de datos incluida.

Paso 5: Planificar el Corte y la Reversión Antes del Día del Lanzamiento

El corte (cutover) debe programarse hora por hora, con un manual escrito: quién congela la carga de datos en el sistema viejo, quién inicia la sincronización final, quién aprueba antes de que los usuarios vuelvan a entrar, y en qué orden se reactivan los sistemas.

Igual de importante: decidir de antemano los criterios de aborto. Si la reconciliación muestra una diferencia del 3% en los conteos de inventario una hora antes del lanzamiento, ¿se avanza o se revierte? Decidir eso bajo presión, en el momento, es como se toman las malas decisiones. Recomiendo mantener el sistema viejo en modo de solo lectura y accesible durante dos a cuatro semanas después del corte, como una simple póliza de seguro mientras el sistema nuevo demuestra que funciona bajo carga real.

Cambiar de Sistema Sin la Historia de Terror

La empresa de distribución que mencioné al principio finalmente logró que su nuevo ERP funcionara bien, pero las seis semanas de limpieza y el cliente que perdieron en el camino fueron completamente evitables. Un proceso de migración disciplinado cuesta más tiempo y dinero por adelantado que "simplemente importar los datos y arreglar lo que vaya surgiendo". Es dramáticamente más barato que la alternativa.

Si está planificando un cambio de sistema y quiere una segunda opinión sobre el plan de migración antes de comprometerse con una fecha de lanzamiento, hablemos de su situación.