Los procesos de migración de datos de un ERP son muy complicados, pero se tienden a infravalorar, al pensar que son una cuestión menor, sin dificultad y que ya vienen incorporados en el ERP, siendo procesos totalmente automatizados.

Además, pueden suponer la diferencia entre el éxito y el fracaso de un proyecto en función del grado de confianza y fiabilidad logrado en el proceso. Si bien los clientes son capaces de percibir que una migración manual puede conllevar bastante tiempo, por lo tanto, coste económico, no tiene la misma percepción cuando esa labor la realiza una organización externa.

Se tiende a pensar que la migración de datos ERP consiste en un traslado total e íntegro del sistema anterior al nuevo, es decir, maestros, datos vivos e histórico de todos los movimientos.

Podemos categorizar la migración en función del ámbito y nivel de complejidad exigido: algunos maestros (clientes, artículos, tarifas, stocks…), transacciones vivas (pedidos pendientes de servir, albaranes pendientes de facturar, registros contables…), todo el sistema (todos los registros). La mayoría de los clientes piensa que una migración implica el “traslado” de todo el histórico y que no tiene que alimentar nada en el nuevo sistema. Deben de realizarse labores didácticas en ese sentido, además las migraciones suelen tener un precio “político” pues no se suele cobrar lo que realmente significa el esfuerzo.

Lógicamente el nivel de complejidad y por lo tanto el coste derivado, va en consonancia a lo comentado, aunque hay que tener en cuenta el nivel de pruebas y test que hay que realizar para garantizar que la información cuadra y es operativa entre los dos sistemas.

Para dimensionar el esfuerzo necesario hay que conocer y cuantificar muchas variables, pero las podríamos dividir en tres: grado de conocimiento del sistema origen, grado de conocimiento del sistema destino y las actividades propias de la migración.

Grado de conocimiento del sistema origen.

Normalmente la colaboración del proveedor anterior no suele ser habitual, dado que el cambio mismo viene dado por la falta de entendimiento con el cliente.

Factores para tener en cuenta:

  • Datos de acceso al sistema. La accesibilidad debe estar garantizada.
  • Estructura de datos y campos. No siempre es inteligible la organización de la base de datos.
  • Relaciones entre las tablas. Las referencias cruzadas entre tablas suelen ser muy diversa y complicada.
  • Tipo de datos de cada campo. Las equivalencias incluso por tipos de datos complican el proceso.

Todo esto suponiendo que la información viene migrada desde un sistema estructurado, en ocasiones la información esta dispersa en otras bases de datos, hojas Excel, etc.…

Grado de conocimiento del sistema destino.

Dando por supuesto que existe, normalmente el mismo implantador suele ser el migrador.

Factores para tener en cuenta:

  • Estructura equivalente de tablas y campos. A mayor conocimiento menor complejidad.
  • Triggers de base de datos que se desencadenan al cargar datos. Su desconocimiento puede desencadenar datos o falta de los mismos necesarios para un tratamiento futuro de los mismos.
  • Procedimientos, Jobs, paquetes, etc. que deberán ejecutarse a posteriori de la carga de datos para dejar consistente la base de datos.

Actividades propias de la migración.

Dando por supuesto que conocemos con cierta profundidad ambos sistemas, llevaríamos a cabo las siguientes tareas.

  • Mapeado de campos entre ambos sistemas. (Equivalencias origen – destino).
  • Conversiones de datos. (Ejemplo: numérico origen, texto destino).
  • (Varios campos origen dan un campo como destino).
  • (Un campo origen dan varios campos como destino).
  • Reemplazar valores. (Valor origen se convierten un valor distinto en destino).
  • Filtros que aplicar. (Selección, depuración de los registros a migrar).

Integridad referencial.

¿Es compatible la carga de datos con la integridad referencial del nuevo sistema?

Una de las preguntas que da mayores quebraderos de cabeza en las migraciones. Para cargar clientes, previamente debo haber cargado otras tablas (países, provincias, formas de pago…), bien en el mismo proceso de migración, o manualmente por el cliente. Para cargar facturas, previamente tengo que haber cargado los clientes, artículos, formas de pago, etc.…. Y así sucesivamente en la mayoría de las tablas, donde cobra vital importancia el orden en que deben ser cargadas.

Si esta carga adicional se hace en el mismo proceso de migración, el coste se multiplica, ahora bien, si lo dejamos en manos dl cliente para que lo haga manualmente, a pesar de que pongamos el máximo de énfasis en que debe hacerse bien, puede incurrir a errores, obviando algunos registros o recodificando datos. En este caso, lograr que la carga no provoque errores de integridad es una labor casi imposible.

En definitiva, dimensionar un proceso de migración, solo se puede hacer, haciéndolo, es decir es muy difícil tener un grado de certeza suficiente, por todos los factores anteriormente mencionados. En el supósito que se conozcan todos los detalles, podríamos cuantificarlo, pero llegados a este punto, el esfuerzo ya está realizado en un 90%.

La vida profesional me ha llevado a vivir desde grandes éxitos a rotundos fracasos. El cliente tiende a pensar que mediante el proceso de darle a un botón se replican los datos de un sistema a otro, sin embargo, hay que convencerle, concienciarle de la complejidad de estos procesos y que no siempre es aconsejable realizar algunas migraciones de datos para evitar ciertas herencias nada aconsejables del sistema anterior. En este aspecto sería mejor ofrecer como un proyecto paralelo la migración de datos del ERP, que le haga entender cuál es el verdadero esfuerzo de esta.