dgi-gi-20121010 guía migración de datos

Programa de Modernización de la Gestión Administrativa

GUÍA DE MIGRACIÓN DE DATOS MGA-ADMI-20120220

09 de diciembre de 2014

2014/12/9- GUÍA DE MIGRACIÓN DE DATOS 3 de 26

ORIGINAL: Magnético en la sede del Share Point SUBGERENCIA DE INFORMÁTICA 12 - 2003

CONTENIDO

Pág.

CONTENIDO ....................................................................................................................... 3

1 INTRODUCCIÓN ............................................................................................ 5

1.1 OBJETO ................................................................................................................ 5

1.2 ALCANCE ............................................................................................................. 5 1.3 AUDIENCIA .......................................................................................................... 5

1.4 CONDICIONES GENERALES .................................................................................. 5 1.5 ORGANIZACIÓN DEL DOCUMENTO ....................................................................... 5

2 REGLAS PARA LA MIGRACIÓN DE DATOS .......................................... 6

2.1 CUMPLIMIENTO DEL PRINCIPIO Y POLÍTICAS DE GESTIÓN DE LA INFORMACIÓN EN

EL BANCO 6 2.2 LA MIGRACIÓN DE DATOS ES UN TEMA DE NEGOCIO ............................................ 6 2.3 NINGUNA ÁREA DE NEGOCIO NECESITA, QUIERE O ESTA DISPUESTA A PAGAR POR

DATOS PERFECTOS ................................................................................................................... 6 2.4 LO QUE NO SE MIDE, NO SE PUEDE CONTROLAR Y NO INTERESA ........................... 7

3 ROLES ............................................................................................................... 9

4 CLASIFICACIÓN DE INFORMACIÓN PARA MIGRAR ...................... 11

5 ENTIDADES ................................................................................................... 11

5.1 IDENTIFICACIÓN DE ENTIDADES ......................................................................... 11 5.2 METADATOS PARA MIGRACIÓN .......................................................................... 12

6 CALIDAD DE LA INFORMACIÓN ........................................................... 14

6.1 DEFINICIÓN ........................................................................................................ 14

6.2 REGLAS DE CALIDAD .......................................................................................... 14 6.3 CATEGORÍA DE LAS REGLAS DE CALIDAD .......................................................... 14 6.4 TIPIFICACIÓN DE LAS REGLAS DE CALIDAD ........................................................ 15 6.4.1 Reglas técnicas o de forma ............................................................................... 15 6.4.2 Reglas de adherencia a un catálogo de referencia ............................................ 15

6.4.3 Reglas de semántica.......................................................................................... 15 6.4.4 Reglas de completitud ...................................................................................... 16

6.4.5 Reglas de negocio ............................................................................................. 16

7 MÉTODOS DE DESARROLLO DE LA MIGRACIÓN ........................... 16

7.1 MÉTODOS PARA LA EXTRACCIÓN ....................................................................... 16



7.2 MÉTODOS PARA LA TRANSFORMACIÓN .............................................................. 16 7.3 MÉTODOS PARA LA LIMPIEZA ............................................................................. 16 7.4 MÉTODOS PARA GENERAR Y CERTIFICAR LAS PRUEBAS ...................................... 17

8 LA MIGRACIÓN COMO PROYECTO ..................................................... 17

8.1 INICIACIÓN ......................................................................................................... 17

8.2 PLANEACIÓN ..................................................................................................... 18

8.3 EJECUCIÓN ........................................................................................................ 18 8.4 CONTROL ........................................................................................................... 23 8.5 CIERRE .............................................................................................................. 24 8.6 LISTA DE ENTREGABLES POR ETAPA .................................................................. 24

9 RECURSOS TECNOLÓGICOS .................................................................. 25

RECURSOS DISPONIBLES ......................................................................................................... 25

10 CONDICIONES PARA APROBAR LA MIGRACIÓN ............................ 25

11 BIBLIOGRAFÍA ............................................................................................ 26

12 AGRADECIMIENTOS ................. ¡ERROR! MARCADOR NO DEFINIDO.

13 HISTORIA DE CAMBIOS DEL REGISTRO ........................................... 26



1 INTRODUCCIÓN

1.1 OBJETO

Este documento sirve para guiar labores de migración de datos.

1.2 ALCANCE

Esta guía contempla las pautas para las labores que hacen parte de:

La gerencia de un proyecto de migración

La preparación, extracción, transformación, limpieza, y conciliación de información

de los sistemas actuales que serán remplazados a la nueva solución.

La preparación, extracción, transformación, limpieza, y conciliación de información

de los sistemas actuales que serán remplazados al esquema establecido para la

información histórica que no se migra a la nueva solución.

La disposición de la información que no se migra a la nueva solución o a los

esquemas de información histórica.

Cabe anotar que el alcance del documento se limita a proyectos de migración de datos que

se generan por cambios en el software. No incluye proyectos de migración de hardware ó

bases de datos.

1.3 AUDIENCIA

Este documento debe ser conocido y utilizado por todos los miembros del equipo de

migración.

1.4 CONDICIONES GENERALES

Ninguna conocida hasta el momento.

1.5 ORGANIZACIÓN DEL DOCUMENTO

El capítulo dos contiene reglas generales que se deben tener en cuenta para proyectos de

migración de datos, los capítulos 3,4 5 y 6 explican conceptos básicos relacionados con

migración de datos, el capítulo 7 explica métodos para el desarrollo de scripts y generación

de pruebas, el capítulo 8 integra todos los conceptos y explica cómo debería realizarse un

proyecto de migración y las etapas del mismo, el capítulo 9 presenta una visión general de

las herramientas tecnológicas con las que cuenta el Banco, el capítulo 10 explica las

condiciones generales que se deben cumplir para aprobar la migración y el capítulo 11

nombra los recursos bibliográficos que se estudiaron para la generación de la guía.



1.6 RECONOCIMIENTOS

Agradecemos a las personas que hicieron posible esta guía de migración. Sin su dedicación

y entrega difícilmente este trabajo se habría logrado

Lorena Arrieta Moreno, Fauricio Hernández Samaca, Heyber Danengel Parra Galindo,

Mónica Ruiz Muñoz, Ángela Liliana Rojas Parra, Freddy Delfin Lizarazo Rodríguez, María

Consuelo Rincón Riveros, Andrea Marcela Mora Villamizar, José Francisco Celis Pinilla y

Sandra Johanna Ossa Taborda.

2 REGLAS PARA LA MIGRACIÓN DE DATOS

A continuación se describen unas reglas de juego que el conocerlas, comprenderlas y

acordarlas aumentan la probabilidad de éxito del proyecto de migración de datos.

2.1 CUMPLIMIENTO DEL PRINCIPIO Y POLÍTICAS DE GESTIÓN DE LA INFORMACIÓN

EN EL BANCO

Es necesario conocer y seguir el Principio, las Políticas y el Marco de Gobierno de la

gestión de la información en el Banco establecido en la Carta Circular GG-435 de julio 8 de

2011.

2.2 LA MIGRACIÓN DE DATOS ES UN TEMA DE NEGOCIO

La migración de datos obedece a la implantación de la solución para el mejoramiento de los

procesos administrativos del Banco. Sin embargo, quien entiende su significado y valor

son las áreas del Banco. Es este valor y significado el que debe mantenerse en el proceso de

migración. Todas las actividades que se realicen en el proceso de migración deben

orientarse hacia este objetivo.

Esta guía ayuda a identificar los diferentes roles y responsabilidades que aumentarán el

éxito del proyecto de migración de datos.

2.3 NINGUNA ÁREA DE NEGOCIO NECESITA, QUIERE O ESTA DISPUESTA A PAGAR POR

DATOS PERFECTOS

http://manualesycirculares/02%20Circulares/gg435-11.pdf

http://manualesycirculares/02%20Circulares/gg435-11.pdf



La información que actualmente se maneja se puede ver representada en el siguiente

diagrama.

Generalmente, la información de los sistemas corporativos y departamentales no tiene la

calidad perfecta: no es completa, no se puede interpretar, no es interesante, no es útil o una

parte de ella es inconsistente. Es necesario ser honestos con esta realidad e importante

conocerla desde el inicio del proyecto de migración. Es indispensable llegar a acuerdos

sobre las fuentes de información, sobre la calidad desde el inicio, sobre las prioridades y no

cuando los problemas sucedan y el éxito del proyecto este comprometido.

Esta guía ayuda a definir el alcance de la información requerida para la nueva solución y el

alcance de la información requerida para conservación.

2.4 LO QUE NO SE MIDE, NO SE PUEDE CONTROLAR Y NO INTERESA

Es necesario medir los resultados para poder establecer si se han logrado o nó. Por

ejemplo, cómo se sabe si se logró el nivel de calidad esperada de los datos o cómo se sabe

cuanto falta para llegar a la situación objetivo.

Es necesario desde el inicio del proyecto de migración llegar a un acuerdo de qué se

medirá, cómo se realizarán estas mediciones y cómo se interpretarán.

Esta guía ayuda a identificar y definir las mediciones que son necesarias realizar para

conocer el avance y logro de la migración.

Información requerida

para la nueva solución

Información sistemas

corporativos actuales Información sistemas

departamentales

Información requerida

para conservación



3 ROLES

A continuación se presentan los diferentes roles que deben estar involucrados en un

proyecto de migración de datos y la forma de identificarlos.

Rol Descripción Responsabilidad ¿Cómo se detecta?

Roles Estándar para un proyecto según SGINF-PN-15

Gerente del proyecto Es la persona que lidera

el proceso de migración

como proyecto.

Responsable de coordinar

y resolver todos los

temas funcionales

durante el proceso de

migración.

Es la persona que

cumple con los

requisitos establecidos

en la metodología de

gerencia de proyectos de

la DG-T (ver documento

SGINF-PN-15).

Ingeniero Líder Es la persona que conoce

la tecnología.

Responsable de coordinar

y resolver todos los

temas técnicos durante el

proceso de migración.

Es el ingeniero Líder.

Otros roles estándar

para un proyecto

Aquí se encuentran todos los roles descritos en la metodología de gerencia de

proyectos tales como:

Grupo ejecutivo, Grupo de trabajo (Usuarios, Grupo de Soporte de Ingeniería,

Organismos de Control), Grupo de pruebas, Grupo de configuración y Compañía

contratista.

Roles específicos para un proyecto de migración que hacen parte del grupo de trabajo

Responsable de la

información

Persona de nivel

directivo del área de

negocio.

Responsable de la

calidad de la información

y de su uso.

Es la persona quien

puede firmar/autorizar el

desmantelamiento o

dada de baja de un

sistema de información.

Experto de negocio Es la persona que esta en

contacto día a día con la

información.

Conoce la forma en que

la información/fuentes es

usada.

Resuelve dudas sobre el

uso de la información.

Es la persona que esta en

contacto día a día con la

información.

Es la persona que conoce

como las fuentes de

datos se están usando en

la actualidad.


los detalles, las

características distintivas

y propias de la

información.


las soluciones

alternativas en el uso de

la información.

http://dgt/Documentos_Internos/Norma_Guia_Politica/DG-T-PN-15_Metodologia_de_Gerencia_de_Proyectos.pdf



Experto Técnico del

negocio


los formatos utilizados,

modelo de dominio de

negocio.

Responsable de apoyar el

proceso de migración.

Es el administrador del

sistema.

Experto de seguridad Conoce las políticas y

lineamientos de la

seguridad de la

información

Apoyo en el

establecimiento de los

procedimientos

requeridos para asegurar

la seguridad de la

información.

Ingeniero del

Departamento de

Seguridad Informática.

Grupo de arquitectura

de datos

Es el que conoce la

información de manera

transversal.

Conocer las fuentes y

cómo la información está

distribuida en los

diferentes sistemas.

Facilita la

consolidación/integración

de la información.

Conocer la estructura del

sistema final.

Estará compuesto por los

ingenieros líderes de

cada sistema.

Contratista sistemas

actuales

Es el que conoce en

detalle la aplicación y

está encargado del

soporte y

mantenimiento.

Colabora en los procesos

de identificación,

extracción y

transformación de los

datos en el sistema de

información fuente.

Empresa contratista de

cada sistema.

Usuarios de los datos Tramita transacciones

como parte del proceso

de negocio.

Cabe anotar que no es el

cliente final del proceso

de negocio.

Facilita la búsqueda e

incorporación de datos

que no existen en los

sistemas legacy.

Colaboradores de las

áreas de negocio.

Entes de control Ingenieros de Auditoría

y Control Interno.

Seguimiento y control de

cumplimiento de las

políticas.

Auditoría y control

interno

Profesional de apoyo

en gestión documental

Conoce las políticas y

metodologías de la

gestión de la

información.

Apoyar la valoración de

la información con

respecto a las políticas de

conservación y

disposición, necesarias

para la información

histórica.

Profesional del

Departamento de

Gestión Documental.

Grupo decisorio sobre

fuente de datos

Toma decisiones acerca

de la fuente de datos

oficial en caso de existir

varias fuentes posibles.

Nota: la migración debe ser adelantada como proyecto. Esto incluye tener los roles

asociados a un proyecto como gerente, ingeniero líder, grupo ejecutivo, etc. y adelantar las



actividades de gerencia establecidas. Para mayor detalle ver metodología de gerencia de

proyectos documento SGINF-PN-15.

4 CLASIFICACIÓN DE INFORMACIÓN PARA MIGRAR

Para facilitar la referencia y toma de decisiones sobre la información, se recomienda

estructurar los datos en las siguientes categorías: Categoría Definición Ejemplos

Datos Maestros Información básica utilizada para procesos de

negocio.

Sucursales

Terceros

Centros de costo

Datos transaccionales

abiertos

Información que combina datos maestros para

crear documentos de negocio.

Incluye las transacciones con estado Activo o en

trámite

Orden de compra

Contratos

Pagos

Datos transaccionales

cerrados

Información que combina datos maestros para

crear documentos de negocio.

Incluye las transacciones con estado cerrado

Orden de compra tramitada

Contratos finalizado

Pagos tramitados

Datos históricos Datos maestros o Transacciones finalizadas que

se requieren para consulta pero que no se utilizan

para operaciones de negocio

Saldos de la contabilidad del

2000

Datos de auditoría Registros de trazabilidad sobre operaciones

realizadas en los sistemas de información

Log de cambios a los

empleados.

5 ENTIDADES

Para el presente documento un modelo conceptual de entidades es un modelo de datos con

la información de negocio agregada para formar agrupaciones de datos que tienen

significado para el Banco.

También se define como un diagrama donde las entidades del modelo de datos (modelo

entidad-relación) son agrupadas para formar entidades de alto nivel que tienen significado

para la empresa.

5.1 IDENTIFICACIÓN DE ENTIDADES

Para identificar entidades, existen dos escenarios:

Escenario 1: El modelo de datos destino ha sido definido previamente y se conoce:




Este escenario se refiere a los sistemas destino previamente desarrollados. En este caso,

se debe:

Analizar los procesos de negocio.

Analizar el modelo entidad-relación del sistema destino para identificar las

entidades requeridas para la migración. En este punto se puede contar con el apoyo

del fabricante del producto para que de acuerdo con su metodología entregue la lista

de entidades con sus descripciones.

Analizar si se entregan tablas transitorias. Los expertos recomiendan la creación

tanto de tablas transitorias como de tablas de equivalencias en los escenarios donde

la información requerida tiene como fuente más de un sistema.

Identificar qué información se clasificará como información histórica.

Escenario2: El modelo de datos no ha sido definido:

Este escenario se refiere a los sistemas destino que están en definición y sin desarrollar.

Para estos sistemas se debe:

Analizar los procesos de negocio.

Analizar el sistema fuente para identificar grupos de datos relacionados.

Identificar qué información se clasificará como información histórica.

5.2 METADATOS PARA MIGRACIÓN

Se refiere a la información que se debe identificar y diligenciar para cada entidad.

Proceso: Proceso de negocio relacionado con cada entidad descrita.

Nombre de la entidad: Nombre descriptivo de la entidad.

Descripción de la entidad: Describe la información que se guardará en esa entidad.

Estructura de la entidad: Listado de los atributos/campos que se requieren por

cada entidad.

Tipo de Información: Se refiere a la clasificación de la información (Datos

maestros, transaccionales, etc) que se guardará en la entidad identificada (Ver

capítulo 4 – Clasificación de la información).

Responsable de la información: Responsable de la calidad de la información y de

su uso. (Ver capítulo 3 – Roles).

Responsable de validar y certificar la información: Se refiere a la persona que

prueba la información que se carga a la entidad destino.

Volumen estimado: No de registros que serán guardados en la entidad.



Por cada fuente de datos se debe identificar:

Servidor fuente de datos: Nombre del servidor o equipo donde se encuentra la

fuente de datos que servirá para realizar la extracción y cargue.

Tipo de la fuente de datos: Descripción de la fuente de datos donde se describe si

su clasificación corresponde a archivos Excel, bases de datos Oracle, SQL Server,

etc.

Nombre de la fuente de datos: Nombre del archivo Excel o base de datos que

contiene la información.

Descripción de la fuente de datos: Describe la información que se almacena en la

base de datos descrita.

Tablas relacionadas en la fuente de datos: Tablas que contienen la información

que se requiere para llenar la estructura de la entidad.

Descripción de la tabla: Descripción de la información que contiene cada tabla

relacionada.

Ciclo de actualización de información: Frecuencia con la que es actualizada la

información en la tabla. Esta frecuencia puede ser diaria, mensual, anual.

Reglas de calidad asociadas: Son las reglas asociadas a la tabla y que se deben

cumplir para la migración

Métrica objetivo: métrica de calidad que la información debe cumplir.

Calidad: Especifica el porcentaje de cumplimiento de las métricas de calidad.

Responsable de la información fuente: Persona que es responsable de la

información que se guarda en la tabla fuente.

Volumen de registros en la tabla: No de registros estimados en la tabla fuente.

Campos de la fuente de datos: Se relaciona si se migran todos los campos de la

tabla relacionada. Si no se migra toda la información, se especifica el nombre de los

campos que se requieren migrar.

Requiere transformación: Se relaciona si se requiere realizar cambios en la

información que se extrae de la fuente. Estos cambios están relacionados con las

reglas de calidad. (Ver capítulo 5 – Calidad de la Información).

Nombre del proceso de transformación: Si se requiere realizar transformación, se

debe especificar el nombre del procedimiento almacenado para la transformación

requerida.

Nombre del proceso de extracción: Nombre del procedimiento almacenado que se

ejecutará para extraer la información de la fuente.

Tablas destino: Nombre de las tablas en el sistema destino que recibirán la

información guardada en la entidad.



Estructura de la tabla destino:

Tipo de cargue: especifica de qué manera se ejecutará el cargue: manual,

automático, única vez al inicio (Precargue).

Observaciones: Describe información relacionada que se debe tener en cuenta.

Con el fin de facilitar la tarea de recolección de metadatos, se creó una plantilla y un

ejemplo en Excel. Esta plantilla se puede encontrar en la sede “Grupo Aprendizaje –

Estrategias de Migración”.

6 CALIDAD DE LA INFORMACIÓN

6.1 DEFINICIÓN

Según el sistema de gestión de calidad ISO9000, la calidad es el grado en el que un

conjunto de características inherentes cumple con los requisitos establecidos. Es así como

la calidad de la información es el conjunto de propiedades de los datos que satisfacen las

necesidades prescritas.

Es importante tener en cuenta que un proyecto de migración de datos es un ejercicio de

migración de datos; no es un ejercicio de calidad de la información. No es recomendable

aprovechar un proyecto de migración de datos para hacer algo más como mejorar la calidad

de los datos. La migración es lo suficientemente pesada como para incrementar de manera

consciente la complejidad, costo, tiempo y riesgo del proyecto.

La calidad de los datos se debe mejorar solamente al nivel en que el nuevo sistema lo

requiera para operar exitosamente. Mejorar la calidad de los datos más allá de este nivel es

importante pero debe ser alcance de otro proyecto diferente al de migración.

6.2 REGLAS DE CALIDAD

Las reglas de calidad son los enunciados de las métricas que serán utilizadas para

determinar la calidad de los datos; y el conjunto de pasos que transformará los datos

actuales al nivel donde las métricas son alcanzadas.

6.3 CATEGORÍA DE LAS REGLAS DE CALIDAD

De la definición de las reglas de calidad, se desprenden dos categorías de estas reglas. La

categoría “Reglas para determinar la calidad de los datos” contiene las reglas que

establecen el tamaño del problema; es decir, indican el grado en que los datos cumplen con

las características requeridas. Eso implica que para esta categoría de reglas de calidad es

necesario identificar métricas que permitan medir la calidad de los datos.



La categoría “Reglas para la corrección de la información” contiene las reglas que

establecen la forma como se corrigen los datos para que cumpla con las características

requeridas.

Tanto las reglas para determinar la calidad de los datos como las reglas para la corrección

de la información son de diversos tipos. Estos tipos se describen en la siguiente sección.

6.4 TIPIFICACIÓN DE LAS REGLAS DE CALIDAD

En este documento guía, las reglas de calidad se agrupan en tipos de reglas para facilitar su

entendimiento y creación. Es importante resaltar que algunas veces una regla de calidad

puede llegar a clasificarse en más de un tipo. Esto no debería generar ningún problema; lo

importante de esta clasificación, es poder establecer las reglas para los datos. A

continuación se describe los tipos de reglas de calidad.

6.4.1 Reglas técnicas o de forma

Este tipo de reglas se caracterizan por revisar formato o sintaxis de acuerdo a estándares

establecidos, nulidad o la existencia de valores, rangos de valores y tipos de datos.

A continuación se mencionan algunos ejemplos:

Nulidad: la información de fecha de nacimiento para el empleado debe tener un

valor y no puede ser nulo.

Formato: la información de fecha de nacimiento para el empleado debe estar en

formato “DD/MM/YYYY”.

Rango de valores: la información de fecha de nacimiento para el empleado debe

estar entre “23/09/1923” y “fecha actual”.

Tipos de datos: la información de fecha de nacimiento para el empleado debe ser de

tipo “fecha” y no puede ser de tipo “texto”.

6.4.2 Reglas de adherencia a un catálogo de referencia

Este tipo de reglas establecen que los valores de los datos deben ser los mismos indicados

en un catálogo establecido en el Banco como referencia. Por ejemplo, los códigos de

ciudades y municipios de Colombia deben ser iguales a los códigos indicados por el

Instituto Agustín Codazzi.

6.4.3 Reglas de semántica

Este tipo de reglas se caracterizan por validar la interpretación correcta de los datos. Por

ejemplo, el tipo de empleado “1” significa que es “activo”.



6.4.4 Reglas de completitud

Este tipo de reglas se caracterizan por asegurar que se cuenta con todos los datos de una

manera integral. Por ejemplo, la suma de cada detalle es igual al total o el número de

registros en la fuente debe ser igual al número de registros en el destino.

6.4.5 Reglas de negocio

Este tipo de reglas se caracterizan por validar la consistencia de los datos de acuerdo a las

características propias de cada negocio. Por ejemplo, un empleado puede tener

beneficiarios a los hijos que tengan edad inferior a 25.

7 MÉTODOS DE DESARROLLO DE LA MIGRACIÓN

7.1 MÉTODOS PARA LA EXTRACCIÓN

El método principal que se requiere utilizar para la extracción de datos, es la generación de

scripts. Estos scripts se pueden construir en diferentes herramientas tales como TOAD,

SQL Developer, SQL server – Integration Services, etc. La herramienta se establece

teniendo en cuenta factores como la fuente de datos, las transformaciones necesarias y el

sistema destino.

Adicionalmente, se recomienda utilizar las herramientas especializadas para realizar ETL y

calidad de datos si el Banco cuenta con ellas.

7.2 MÉTODOS PARA LA TRANSFORMACIÓN

Similar a la extracción, el método más común son los scripts que pueden ser desarrollados ó

generados con herramientas como Toad, sql developer y SQL Server – integration services.

Adicionalmente, es indispensable incluir las reglas de calidad, las cuales son la guía a

seguir para generar los scripts de transformación que se requieren.

7.3 MÉTODOS PARA LA LIMPIEZA

Para la limpieza de datos existen dos alternativas:

a. Limpieza manual de la información: Este método requiere que el rol de usuario

de datos (Ver sección 3-Roles) incluya información que falta o corrija información.

Generalmente se utiliza cuando la información no se encuentra en ningún sistema de

información, o se encuentra inconsistente. Esta corrección puede implicar la



necesidad de recurrir a documentación física, a consultas telefónicas ó a entrevistas

para obtener la información.

b. Limpieza automatizada información: Es un proceso automático que implementa

las reglas de calidad de información de acuerdo a la sección 6.2-Reglas de Calidad.

7.4 MÉTODOS PARA GENERAR Y CERTIFICAR LAS PRUEBAS

Durante la etapa de planeación del proyecto se debe definir la estrategia de pruebas. Esta

estrategia debe incluir los métodos de validación de cada prueba y los soportes que se

deben generar para certificar las pruebas realizadas.

Los soportes de las pruebas firmados son indispensables para aprobar la migración.

La metodología de pruebas se encuentra en los documentos internos de tecnología: SGINF-

PN-17-Metodología de pruebas

8 LA MIGRACIÓN COMO PROYECTO

En un proyecto de migración se construyen entregables que corresponden tanto con los

productos propios de un proyecto estándar como productos adicionales requeridos por un

proyecto específico de migración.

En este capítulo nos concentraremos en los productos adicionales requeridos en un proyecto

de migración. Cabe anotar que en un proyecto de esta naturaleza, los procesos desarrollados

son iterativos.

8.1 INICIACIÓN

En esta etapa se construye la carta de constitución tal como lo describe la metodología de

gerencia de proyectos. Para un proyecto de migración, se debe incluir como mínimo lo

siguiente:

Definición del método para definir las políticas de retiro de los sistemas actuales y

los responsables.

Necesidades especiales para la ejecución de pruebas desde el punto de vista de

migración.

Validación de la estrategia de migración con el Arquitecto de datos.

Definición de la gestión del cambio.

http://dgt/Documentos_Internos/Norma_Guia_Politica/DG-T-PN-17_Metodologia_de_Pruebas.pdf

http://dgt/Documentos_Internos/Norma_Guia_Politica/DG-T-PN-17_Metodologia_de_Pruebas.pdf



Identificar el equipo de trabajo y el rol de cada persona incluyendo a los

“Interesados”, según roles descritos en el “capítulo 3 – Roles”.

Identificar el alcance del proyecto: Sistemas legacy, áreas de negocio clave y

entregables.

Incluir requerimientos de recursos.

La carta de constitución debe ser aprobada y firmada. Se recomienda presentarla en

términos de negocio.

Los demás documentos que se mencionan en la metodología de gerencia de proyectos tales

como la especificación de riesgos, factores críticos de éxito, puntos de control, selección de

la gerencia del proyecto, plan de alto nivel, etc. se deben documentar de acuerdo a la

metodología de gerencia de proyectos documento SGINF-PN-15.

8.2 PLANEACIÓN

En la etapa de planeación se deben realizar las actividades definidas en la metodología de

gerencia de proyectos. Estas actividades están relacionadas con elaborar presupuesto del

proyecto, desarrollar la planeación organizacional, planear la gerencia de riesgos,

formalizar la planeación de adquisiciones, desarrollar la planeación de calidad, realizar la

planeación de comunicaciones y realizar la planeación de configuración.

Durante la planeación de un proyecto de migración, se definen los entregables específicos

por cada etapa del proyecto, se determina el formato de los entregables y se integra el plan

de la ejecución de la migración al plan general del proyecto.

Adicionalmente, se inicia la definición de la estrategia de pruebas, lo que incluye: tipos de

pruebas, actores involucrados, herramientas requeridas, entregables, etc. En caso de que no

exista una estrategia de pruebas se deja un espacio en el plan indicando que esta decisión se

pospone.

8.3 EJECUCIÓN

Para iniciar la ejecución del proyecto se debe conocer la lista de los entregables que fue

definida en la etapa de planeación y se debe garantizar que se cuenta con los recursos

requeridos.

Paso 1: Análisis de los datos desde la perspectiva de los sistemas fuente

Análisis de los sistemas Legacy




En esta etapa se establece la ficha técnica (descripción) de cada sistema Legacy. Este

ejercicio además de facilitar la identificación de los sistemas que debemos migrar, mejora

el entendimiento de las áreas de negocio clave.

Después de establecer la ficha técnica, se deben comparar los modelos existentes para cada

sistema con la base de datos real e identificar inconsistencias.

Actualización de los modelos de datos para cada área de negocio clave

Si se identifican inconsistencias de los modelos o documentación existentes del sistema con

la realidad, se deben documentar estas diferencias. Un ejemplo típico es la creación de

nuevos campos para ingreso de información. Las diferencias pueden ser documentadas

actualizando el modelo de datos o creando un nuevo archivo para su registro.

Crear la primera versión de las políticas de retiro

Todo sistema Legacy que es candidato a ser remplazado por el nuevo sistema debe tener

definida una política de retiro.

Estas políticas deben estar firmadas por el responsable de la información y revisadas por el

ingeniero líder.

Identificar entidades fundamentales

Crear las reglas de calidad de datos

Se debe iniciar la definición de las reglas de calidad de acuerdo a lo definido en el capítulo

“6 - Calidad de la información” de este documento y a las entidades identificadas.

Ejecutar las reglas de calidad de datos

En la primera iteración de las reglas de calidad, se busca establecer el tamaño del problema

y el grado de consistencia. Y en la segunda iteración se intenta solucionar los problemas

encontrados. Es importante enfatizar que la calidad de los datos es un tema de negocio. Por

este motivo se debe involucar a los roles: Responsable de la información, Experto de

negocio y Experto Técnico del negocio. (Ver capítulo “3-Roles”)

En caso de definir actividades de limpieza de datos en los sistemas Legacy, se recomienda

definir prioridades y responsables.

Paso 2: Análisis de los datos conociendo los sistemas destino

Nominar los sistemas legacy



Después de que ya tenemos la lista de todos los posibles sistemas legacy que requerimos,

debemos hacer comparaciones para identificar cuáles se deben tener en cuenta en la

migración. Los gaps encontrados en la comparación se deben analizar y registrar.

Existen tres tipos de gap:

o Gaps de acceso: Se verifica que existan las conexiones entre los datos ó tablas

que permitan que los datos requeridos puedan ser asociados y cargados.

o Problemas de estructura de los datos: Se verifican posibles inconsistencias

generadas por la existencia de sinónimos definidos como información que se

escribe diferente pero tiene el mismo significado (máquina y equipo) y de

homónimos definidos como las palabras que se escriben igual pero tienen

diferente significado (cuenta).

o Gaps de datos: Se identifican las entidades que hacen falta. Este gap se debe

definir en un alto nivel.

Después de analizados los gaps, debemos seleccionar los sistemas legacy requeridos y

obtener aprobación de los interesados acerca de los grupos de datos y la fuente de datos

propuesta. Al obtener la aprobación de los interesados, se puede bajar un nivel para realizar

el mapeo campo a campo. Ya cuando se tiene el mapeo se procede a crear un borrador de

las definiciones de transformación y cargue de datos.

Revisión y mejora de reglas de calidad

En este momento se tienen algunas reglas de calidad generadas en el “paso 1 – Preparación

de los datos desde la perspectiva de los sistemas fuente” y relacionadas con los sistemas

fuente. Se deben generar la totalidad de las reglas de calidad necesarias teniendo en cuenta

las restricciones que nos impone el sistema destino.

Es importante que el área de negocio se pregunte:

o Si he vivido con el sistema con información que tiene un x grado de confiabilidad,

requiero mejorar esa confiabilidad en este momento? O puedo continuar con esa

misma información en el nuevo sistema?

Las actividades para generación de reglas de calidad se describen detalladamente en el

capítulo 6 – Calidad de la información.

Validación y aprobación de las reglas de calidad



Se requiere un alto compromiso del área de negocio ya que ellos son los expertos para

auditar y obtener datos. Todas las reglas definidas deben obtener aprobación del área de

negocio.

Mejora de las políticas de retiro

Cada sistema legacy debe tener políticas de retiro del sistema, donde se especifica lo

mínimo que debe hacerse antes de retirar el sistema. La definición de estas reglas inicia en

el “Paso 1 - Preparación de los datos conociendo los sistemas destino” y se completan en su

totalidad en este momento.

Dentro de las políticas de retiro se debe especificar:

o Datos que no serán migrados

o Manejo de datos transitorios ó transacciones vivas durante el periodo en que se

inicia la utilización del nuevo sistema

Cierre del paso 2

Para el cierre, se deben completar los siguientes entregables:

o Lista de las definiciones para generar los scripts de extracción, transformación y

cargue

o Reglas de calidad tanto del paso 1 (fuentes) como del paso2 (incluyendo modelo

destino)

o Políticas de retiro para cada sistema legacy firmadas.

Paso 3: Construcción, pruebas y salida en vivo

En esta fase se toman los datos analizados y probados en las fases previas y se realizan los

programas y planes de migración

Inicio

Para iniciar la etapa de construcción se debe revisar que los entregables de las etapas

previas se encuentren finalizados.

En caso de que todas las reglas de calidad no se encuentren finalizadas, es importante

realizar la evaluación del riesgo generado debido a la entrega tardía de las reglas de calidad.



En esta etapa se debe revisar y completar detalladamente el plan de trabajo tanto del

proyecto de migración general como de la etapa de la salida en vivo.

Diseño físico de la migración

En el diseño físico se detalla:

o El plan de la salida en vivo incluyendo los puntos de control y pistas de auditoría

o La “ventana de tiempo” que se utilizará para la migración teniendo en cuenta las

restricciones de negocio que se deben soportar y las políticas de retiro establecidas.

o Run-time (deltas): Corresponde a la información que ingresa en el sistema legacy

durante la migración y la estrategia que se seguirá para identificar y cargar esa

información en el nuevo sistema.

o Especificación técnica de la migración: Este documento Incluye las especificaciones

de los programas de cargue, especificaciones de los sistemas transitorios

necesitados en la migración y especificaciones técnicas de los cambios a los

sistemas legacy ó la creación de nuevos repositorios que permitan la retención de la

información histórica. La especificación Programas de cargue incluye el desarrollo

de los scripts, su organización e integración.

o Especificaciones plan de retorno: En el plan de la salida en vivo deben existir

puntos de control y las acciones que se deben tomar en caso de fallo. El plan de

retorno debe estar coordinado con el plan de la salida en vivo ya que el orden físico

en que se realiza el proceso de carga afecta el diseño del plan de retorno.

o Especificación no funcional: En este documento se documenta información sobre

los servidores que se van a utilizar, nombre de la base de datos, esquema de

contingencia y arquitectura de red.

o Políticas de retiro: Se documenta cómo se van a implementar las políticas de retiro,

incluyendo la definición de los datos que serán migrados, los que no serán migrados

y lo que sucederá con la información no migrada.

o Sign off: Se deben firmar los documentos. Se debe evitar la tentación de hacer

revisar por parte del usuario un solo documento “gigante” con todas las

especificaciones tanto funcionales como técnicas.

Pruebas de la migración:

Se deben ejecutar pruebas de acuerdo con lo especificado tanto en las políticas de retiro

como en las reglas de calidad.



Es importante reconocer que el software de migración es un producto para uso único y

que no se usará después de ejecutada la migración, por este motivo, incluir esfuerzo

adicional para mejorar en algunos minutos los tiempos de ejecución no agregan valor.

Es mejor asegurarse que la transformación y migración se realice correctamente.

Ejecución:

Para iniciar la ejecución, se debe verificar que todos los documentos requeridos se

encuentren disponibles. Lo anterior implica que debemos contar con: la definición

completa de las políticas de retiro aprobadas, reglas de transición de datos aprobadas,

La tabla de tiempos de la migración establecida, los programas de cargue

implementados y probados, los “Data Stakeholders” listos a atender cualquier pregunta,

los sistemas legacy and los sistemas intermedios de transición, con datos de calidad

suficiente para la migración y los aspectos no funcionales acordados.

En este punto se ejecutan todos los programas de cargue de acuerdo con el plan de la

salida en vivo.

Revisión posterior

No todos los sistemas pueden ser “apagados” inmediatamente con la implementación del

nuevo sistema debido a transacciones en curso, etc. Sin embargo, asegúrese de implementar

las políticas de retiro.

8.4 CONTROL

Monitoreo permanente de todos los puntos de control establecidos para el proyecto,

incluyendo los definidos para la salida en vivo del proyecto de migración.

Se debe mantener la definición del estado actual de los productos a controlar. En un

proyecto de migración se debe controlar:

Documento de carta de constitución que contiene la estrategia de migración

Lista y definición de los sistemas Legacy

Documento de las reglas de calidad

Políticas de retiro para cada sistema

Todos los puntos de control para la gerencia del proyecto según la SGINF-PN-15




8.5 CIERRE

En este proceso se realiza el cierre del contrato, el cierre administrativo y se documentan

las lecciones aprendidas tal como se especifica en la metodología de gerencia de proyectos.

8.6 LISTA DE ENTREGABLES POR ETAPA

Etapa Entregables

Iniciación Carta de constitución

Planeación Plan del Proyecto de migración

Plan para la generación de modelos de datos

Plan para la generación de reglas de transición de datos

Plan para la generación de Definiciones de la extracción,

transformación y cargue de datos.

Especificaciones generales del Diseño físico.

Definición del mecanismo para controlar el versionamiento de los

productos.

Ejecución Lista completa de áreas de negocio clave.

Lista completa de los sistemas legacy.

Lista completa de los Data Stakeholders.

Documento de reglas de calidad completo y firmado.

Documento de las políticas de retiros de sistemas completo y firmado.

Bases de datos ó sistemas transitorios.

Reglas para la transición de datos.

Definiciones de la extracción, transformación y cargue de datos.

Control Informes de avance del proyecto

Solicitudes de cambio

Bitácora de control de la configuración

Listas de chequeo diligenciadas

Actas de acuerdo



Acciones preventivas y correctivas

Línea base y plan del proyecto actualizado

Estructura de descomposición del trabajo actualizada (EDT)

Estimativos de costos actualizados

Carta de constitución actualizada

Cambios al contrato

Pagos

Cierre Lecciones aprendidas

Certificación de la migración firmada.

9 RECURSOS TECNOLÓGICOS

RECURSOS DISPONIBLES

Personal asignado a cada rol del proyecto con las habilidades requeridas para

cumplir las funciones a cargo.

Herramientas tecnológicas:

Software: ETL(En proceso de adquisición trimestre 3 de 2013), TOAD, SQL

Developer, SQL Server – Integration services.

Base de datos: Bases de datos fuente, intermedias y destino

Hardware: Servidores fuente, intermedios y destino

10 CONDICIONES PARA APROBAR LA MIGRACIÓN

El conjunto de condiciones para lograr la aprobación de la migración debe contemplar los

siguientes elementos:

Que se hayan migrado todos los datos necesarios para que el nuevo sistema pueda

operar exitosamente.



Que el nivel de calidad de los datos migrados sea el mínimo necesario para que el

nuevo sistema pueda operar exitosamente.

Que se cumplan las políticas de retiro previamente acordadas y firmadas

La aprobación se formaliza mediante un acta firmada por los responsables de la

información y la gerencia del proyecto.

Para facilitar la consecución de la aprobación es importante tener en cuenta:

Determinar oportunamente los datos a migrar y su alcance en las etapas tempranas

del proyecto. Es necesario que se apruebe por la gerencia del proyecto, los

responsables de la información y el contratista que implantará el nuevo sistema.

Determinar de manera precisa el nivel de calidad de los datos que el nuevo sistema

requiere. Es necesario que este nivel sea aprobado por el responsable de la

información. Es importante recordar que es un proyecto de migración y no un

ejercicio de mejorar la calidad de la información.

11 BIBLIOGRAFÍA

Practical Data Migration, Edición 2006, Autor John Morris

12 HISTORIA DE CAMBIOS DEL REGISTRO

2013/01/30. Sandra Ossa, Francisco Celis

- Creación del documento

dgi-gi-20121010 guía migración de datos

Documents