Migración de Datos....y muchas cosas más.

Aunque parezca mentira, el hecho de cambiar un sólo dato puede arruinar a una Organización. ¿Por qué? Por que ese movimiento puede conllevar que un cliente (o todos) pierda su vínculo emocional, económico, laboral....con la Organización y deje de querer permanecer ligado a dicha Empresa. También puede darse la situación contraria, que a partir de un mínimo cambio una empresa adopte una imagen o comportamiento atractivo para muchos clientes.

Por lo cual antes de llevar a cabo un paso en este sentido, se hace necesaria la actuación de las Áreas más relacionadas con el Cliente(Front-Back-Marketing-BI-DWH) para evaluar a priori los comportamientos de los clientes ante la nueva forma de "su" Servicio. Y a partir de esos requerimientos, se debe iniciar un proceso tan arduo, pesado, farragoso, tenso y largo como sea necesario para asegurar que los pasos que el Negocio desea dar son aceptados y soportados por la Infraestructura existente.



Lo anterior denota como venimos comentando, que las personas resultan claves y (des)ventajas competitivas en este proceso, que a primera vista es eminentemente técnico.
Dicho lo cual en aquellos proyectos dónde se ha de disponer de los datos actuales en la nueva infraestructura, generalmente se ha de seguir esta estrategia en la migración:

1- Revisión y aceptación funcional/del Negocio entre Integrador e Integrado. Es decir asegurar que los clientes de dicha(s) entidad(es) estarán satisfechos o por lo menos informados. Y esa función la asumirán las áreas de Proyectos y Desarrollo.

2.- Traducción de los requerimientos de Negocio a Mundo IT. En el peor de los escenarios contaremos con lógica de datos, estructura de BBDD, entornos y Planificadores diferentes.  Desarrollo llevará a cabo la realización del software de extracción, validación, conversión, carga y validación última. Y normalmente Explotación agrupa todos estos procesos Batch en una Planificación ejecutada bajo un Planificador de Procesos. A partir de aquí, los batch son probados en numerosos (y arduos) Ciclos de Prueba en Entornos No-Pro. Esto permite depurar errores en el propio proceso de Conversión e identificar problemas de rendimiento

En el mundo Mainframe, normalmente con BBDD Informix, Adabas o DB2, se hace necesario en migraciones con grandes volúmenes de datos, realizar Rebinds de los pgms y Runstats y Reorganizaciones de las BBDD para eficientar el acceso a los mismos
En Sistemas Distribuidos, ya sea Oracle, SQL Server..., igualmente se hará necesario revisar los planes de ejecución y reorganizar las tablas.

3.- Puesta en Producción: Cuando el Batch está lo suficientemente depurado (o así debiera ser) se elegirá un momento con el mínimo impacto al Cliente existente para llevar a cabo el proceso de Migración. No es siempre posible elegir indisponibilidad 0, pero existen mecanismos que mitiguen esa situación.
Por ejemplo, en el Mundo Mainframe existen mecanismos que permiten a los dispositivos trabajar en desconexión interactuando con los Clientes con una "foto" de los datos previa al corte.
Es indispensable mantener los tiempos comprometidos con el Negocio y, establecer en puntos de revisión frecuentes durante la secuencia del Batch para determinar el estado del proceso y tomar, en caso que sea necesario, la decisión de dar Marcha atrás a la Migración.

Los que habeis vivido un proceso de Migración de datos os sentiréis identificados con alguna de esta líneas, estoy convencido.

FIN