Migración de datos a un ERP nuevo: el paso que hunde más proyectos

Cuando una implantación de ERP se tuerce, rara vez es porque el software no sirva. Lo habitual es mucho más prosaico: los datos que se metieron dentro estaban mal. Referencias duplicadas, clientes con el CIF cambiado, stock que no cuadra con el almacén, saldos que no casan con la contabilidad anterior. El sistema funciona perfectamente; lo que responde son mentiras heredadas.

La migración de datos es la parte del proyecto que menos atención recibe en las reuniones comerciales y la que más horas consume al final. Esta guía desarrolla en detalle esa fase concreta; si lo que buscas es la visión de conjunto del proyecto, empieza por implantar un ERP paso a paso, y si vienes de un sistema anterior, por migrar de un ERP antiguo a uno nuevo.

Primera decisión: qué migrar y qué no

El impulso natural es querer llevarlo todo. Es casi siempre un error. Migrar histórico completo multiplica el trabajo de limpieza, alarga las pruebas y arrastra al sistema nuevo la suciedad acumulada durante años.

Una separación que funciona bien:

• Datos maestros: clientes, proveedores, artículos, cuentas contables, tarifas. Son imprescindibles y hay que migrarlos con calidad máxima. Son los que más se usan y los que más daño hacen si vienen mal.
• Saldos de arranque: existencias, saldos de clientes y proveedores, balance de apertura. Imprescindibles, pero se cargan como una foto a fecha de corte, no como histórico de movimientos.
• Movimientos históricos: facturas, albaranes y asientos de ejercicios anteriores. Aquí es donde conviene ser restrictivo. En muchos proyectos basta con migrar el ejercicio en curso y dejar el resto consultable en el sistema antiguo o en un export documental.

La pregunta útil para decidir cada bloque no es “¿podríamos necesitarlo?” sino “¿qué proceso concreto se rompe si esto no está dentro del ERP nuevo?”. Si nadie sabe responder, probablemente no hace falta migrarlo.

Limpiar antes de migrar, no después

Migrar datos sucios solo cambia de sitio el problema. La limpieza tiene que ocurrir antes de la carga, y conviene empezarla mucho antes de lo que parece razonable, porque siempre lleva más tiempo del previsto.

Los focos habituales de suciedad:

Duplicados. El mismo cliente dado de alta tres veces con variantes del nombre. El mismo artículo con dos referencias porque lo crearon dos personas distintas. Detectarlos requiere criterios claros (por CIF, por código, por descripción normalizada) y alguien que decida cuál se queda.

Registros obsoletos. Clientes que no compran desde hace años, artículos descatalogados, proveedores que ya no existen. Migrarlos ensucia las búsquedas del día a día para siempre. Un criterio de antigüedad razonable elimina buena parte del volumen.

Campos incompletos o inventados. Direcciones a medias, CIF con formato inválido, códigos postales rellenos con ceros para poder guardar el registro. El ERP nuevo suele ser más estricto que el antiguo y rechazará justo esos.

Codificaciones incoherentes. Unidades de medida mezcladas, familias de producto que significan cosas distintas según quién las asignó, tarifas con reglas que solo conoce una persona.

Este trabajo lo tiene que hacer quien conoce el negocio, no el consultor. Es la parte que no se puede subcontratar del todo.

El mapeo entre sistemas

Cada campo del sistema antiguo tiene que tener un destino en el nuevo, o una decisión explícita de que se descarta. El documento de mapeo es aburrido de hacer y es lo que evita descubrir en la semana de arranque que no hay dónde guardar un dato que resulta ser crítico.

Puntos que suelen dar problemas en el mapeo:

• Campos libres del sistema antiguo donde la gente metía información importante sin estructura. Hay que decidir a qué campo estructurado van, o si se llevan a observaciones.
• Relaciones que el sistema nuevo modela distinto: direcciones de envío múltiples, contactos por cliente, jerarquías de artículos.
• Formatos: fechas, decimales, longitudes máximas de texto. Truncar sin avisar es una fuente clásica de datos corrompidos.
• Codificación de caracteres: acentos y eñes que se convierten en símbolos raros al exportar e importar.

Pruebas de carga: siempre más de una

Una sola carga de prueba no basta. El patrón que funciona es hacer varias pasadas, cada una sobre un entorno de pruebas, y usar cada una para corregir lo que salió mal en la anterior.

En la práctica suelen hacer falta al menos tres:

1. Carga técnica: comprobar que los ficheros entran, que los formatos son correctos y que el sistema no rechaza registros. Aquí salen los errores de formato y longitud.
2. Carga con validación de negocio: los datos entran, y ahora alguien del área comprueba que lo que ve tiene sentido. Aquí salen los errores de mapeo y de criterio.
3. Ensayo general: carga completa en condiciones lo más parecidas posible al arranque real, cronometrada. Sirve para saber cuánto tiempo hace falta de verdad y para detectar lo que solo aparece con volumen completo.

Cronometrar la carga no es un detalle menor: si el corte real solo dispone de un fin de semana y la carga tarda más que eso, es mejor saberlo con antelación.

Validación: cómo saber que ha ido bien

“Parece que está todo” no es un criterio. Antes de dar por buena la migración conviene tener números que cuadren:

• Recuentos: número de clientes, proveedores y artículos activos en origen y en destino. Si no coinciden, hay que saber exactamente por qué (registros descartados a propósito cuentan, registros perdidos no).
• Sumas de control contables: el balance de apertura del sistema nuevo tiene que cuadrar con el cierre del antiguo. Es la validación más importante y la menos discutible.
• Valoración de existencias: el valor total del stock migrado debe coincidir con el del inventario de corte.
• Muestreo manual: elegir una decena de registros de cada tipo, incluidos casos raros conocidos, y revisarlos campo a campo.

Conviene fijar estos criterios por escrito y antes de la carga, con un responsable que los firme. Si no, la validación se convierte en una sensación general y las discrepancias aparecen semanas después.

Cómo encajar el corte

La migración obliga a una decisión operativa: qué pasa con la actividad mientras se hace el cambio. Las opciones habituales son un corte limpio —se para la operación, se carga y se arranca en el sistema nuevo— o un periodo en paralelo en el que ambos sistemas conviven un tiempo.

El corte limpio es más barato y más rápido, pero exige que la carga esté ensayada y que el equipo esté preparado. El paralelo da red de seguridad, pero duplica el trabajo administrativo durante semanas y agota al equipo. Para la mayoría de PYME, un corte limpio bien ensayado en un momento de baja actividad es la opción más sensata; el paralelo solo compensa cuando una parada es inasumible.

Sea cual sea la opción, hay dos precauciones que no se negocian: mantener el sistema antiguo accesible en modo consulta durante un tiempo razonable, y conservar los ficheros de la migración con su documentación, por si hay que reconstruir algo.

Errores que se repiten

Dejar la migración para el final. Se planifica el proyecto por módulos funcionales y los datos quedan como una tarea del último mes. Para entonces no hay margen para limpiar.

Que nadie sea responsable de los datos. Si la propiedad de los datos maestros no está asignada a personas concretas del negocio, las decisiones de limpieza no se toman y todo se acaba migrando “por si acaso”.

Confiar en que el proveedor lo resuelva. El consultor sabe mover datos de un sistema a otro; no sabe si ese cliente duplicado es el bueno o el malo. Esa parte es siempre interna.

No versionar los ficheros de carga. Después de tres pasadas nadie sabe cuál era el fichero correcto. Numerarlos y guardarlos cuesta nada.

Arrancar sin cuadrar la contabilidad. Es el error más caro: se descubre en el primer cierre, y para entonces ya hay movimientos nuevos encima.

Por dónde empezar

Si tienes una implantación por delante, tres cosas que puedes hacer ya, antes incluso de elegir producto:

1. Inventariar qué datos tienes y dónde: cuántos clientes, artículos y proveedores activos, en qué sistemas y con qué calidad aproximada.
2. Asignar propietarios: una persona responsable por cada bloque de datos maestros, con capacidad de decidir.
3. Empezar a limpiar en el sistema actual: cada duplicado que elimines hoy es trabajo que no harás bajo presión durante el proyecto.

La migración de datos no es una tarea técnica que ocurre al final. Es un proyecto de negocio que conviene arrancar el primer día.

---

Si estás en fase de selección y quieres contrastar el software de gestión disponible, el directorio de software de gestión empresarial de Dataprix recoge fichas y análisis editorial de las principales opciones.