Una empresa del sector naval adquirió un buque con un sistema de software diferente al de su flota y Aeromarine migró la base de datos existente con el histórico de los últimos 5 años de vida útil de certificados, histórico de mantenimiento, equipos y almacén al sistema estándar de la naviera, sin perder datos. A continuación se describe el proceso de migración y las claves de su éxito.

El cliente y sus objetivos

Nuestro cliente es una empresa naviera que gestiona en tierra y a bordo mediante un sistema informático, los equipos, el almacén, las compras, el mantenimiento y los certificados de la flota. Adquirió un barco junto con la base de datos que contenía su histórico de los últimos 5 años. El objetivo del cliente era instalar el sistema estándar del resto de la flota en este buque, recuperando todos los datos sin perder histórico y accediendo a los datos tanto a bordo como en las oficinas centrales. Contrató el servicio a Aeromarine que realizó la migración y la instalación cumpliendo con los requisitos de la naviera. Veamos cómo.

Migración de una base de datos: ¿Qué es y por qué se lleva a cabo?

Una migración de base de datos es un proceso por el que los datos almacenados en una base de datos origen se mueven o trasladan a una base de datos destino. La migración de una base de datos se produce por muchas razones diferentes, para actualizar la versión del software, cambiar el motor de base de datos, cambiar la base de datos a una plataforma diferente, sustituir las aplicaciones que usan los datos por otras diferentes, etc.

Por tanto, el motivo de la migración va a determinar el procedimiento exacto que hay que seguir; aunque independientemente del motivo hay un conjunto de prácticas (best practices) que facilitan el proceso. Vamos a ver en primer lugar los pasos que se realizaron en esta migración y en segundo lugar, las prácticas que se usaron.

Pasos de la migración

Hay que tener en cuenta que en la naviera existía un sistema informático estándar en la flota y por tanto la incorporación de un nuevo barco suponía:

• Acceder y transformar los datos origen para hacerlos compatibles con el sistema estándar de la naviera.
• En el nuevo buque, había que instalar los sistemas y aplicaciones estándar, sin perder datos e incorporando los datos comunes a la flota.

El primer paso fue el análisis

Se requirió en un primer momento contemplar los siguientes puntos y darles repuesta.

• ¿Los datos obligatorios se encuentran en la base de datos origen? Por ejemplo, si el sistema requiere el número de serie de los equipos, ¿la base de datos origen lo tiene? ¿están todos los datos obligatorios? ¿qué se hace si no lo están?
• ¿Qué datos se quieren migrar y cuáles no?
• ¿Podemos identificar claramente todos los datos del sistema que se sustituye? Por ejemplo, tenemos 1500 horas, ¿es la frecuencia del mantenimiento o es el número de horas del equipo cuando se realizó un mantenimiento?
• ¿Los tipos de datos coinciden en ambos sistemas? Por ejemplo, ¿los decimales tienen la misma precisión? ¿Qué transformaciones se requieren?
• ¿Cómo afectarán los nuevos datos al conjunto de los datos de la empresa? Por ejemplo, si en los datos origen hay nuevos proveedores o fabricantes ¿se incorporarán?
• ¿Los datos de la nueva instalación o del nuevo barco cumplen las reglas de validación de la flota? ¿Los proveedores tienen la misma codificación ? ¿Cómo se van a modificar para que sean consistentes con el código que se usa en la naviera?
• ¿Qué intercalación (collation) se debe elegir para la nueva base de datos, de forma que se eviten problemas de caracteres o fechas?

Con los resultados de este análisis, se determinó qué hacer con los datos antes de migrarlos y se detallaron tareas de :

Limpieza para corregir los datos los datos incorrectos, duplicados, inconsistentes o incompatibles.

Homologación para unificar criterios, códigos, tipos de datos, etc. En otras palabras, se clasificaron los datos según los requisitos y necesidades del cliente.

Enriquecimiento para completar y/o perfeccionar los datos origen con el objetivo de garantizar que al integrarlos en la flota son fiables y consistentes con el resto.

Segundo paso: extraer y transformar

Hay que extraer y modificar los datos para una vez limpios, homologados y enriquecidos, volcarlos al nuevo sistema. Los datos origen pueden encontrarse en muchos formatos; por ejemplo, podemos tener una copia de base de datos o podemos tener ficheros (texto, hoja de cálculos). En nuestro caso, los datos se encontraban en una copia de base de datos de tipo SAP SQL Anywhere. La base de datos destino iba a estar en Microsoft SQL Server. El procedimiento que elegimos fue extraer los datos desde el origen y transformarlos a través de scripts.  

Los scripts son el conjunto de instrucciones o comandos escritos en un formato regular compatible con el motor de base de datos que al ejecutarse realizan operaciones. Aquí puedes ver ejemplos de scripts. Se construyeron scripts para transformar, convertir y ordenar los datos de origen según las reglas estándar del sistema del cliente. Una vez que los datos estaban modificados correctamente, los volcamos a ficheros de  tipo .csv ;  ya que para cargarlos en la nueva base de datos ibamos a usar un asistente de Microsoft para la importación de ficheros de texto plano.

Tercer paso: la validación

La validez de los datos garantiza que antes de usarlos en un sistema en operación, los datos son correctos. Dicho de otra forma, los datos han de ser veraces, operativos y permitir la correcta ejecución de las aplicaciones que los usan. Para ellos realizamos las siguientes tareas:

• Creación de una nueva base de datos vacía de tipo MSQL con la estructura adecuada para funcionar con el sistema informático estándar del cliente.
• Simulaciones de Cargas para identificar los inconvenientes que se pueden tener en las cargas reales y proceder a ajustar.
• Pruebas exhaustivas funcionales para verificar la integridad de los datos migrados y comprobar que estos datos son correctos desde el punto de vista funcional

En resumen, se realizó un piloto que permitió comprobar y reajustar el procedimiento hasta conseguir el resultado adecuado.

El cuarto paso fue la carga de los datos

Una vez que las simulaciones y pruebas fueron satisfactorias, se instaló el sistema estándar y se cargó una nueva base de datos con los datos ya limpios y validados del barco.

Se hizo una carga completa o migración Big Bang, es decir, se pasó toda la información al nuevo sistema. La ventaja de este procedimiento es el ahorro de tiempo. Su principal desventaja en comparación con una carga incremental que carga poco a poco y comprueba posibles problemas, es que si algo va mal con la carga completa, los problemas pueden ser importantes. En este caso, esta posibilidad era pequeña por varios motivos: la experiencia que tenía el equipo de Aeromarine en este tipo de migraciones, la cantidad de simulaciones y pruebas funcionales realizadas y porque en esta carga los datos sólo se cargaron en el sistema del barco y no afectaron en la primera carga al conjunto de la flota. Era el momento de detectar cualquier problema y resolverlo antes de sincronizar con el resto de la flota.

Las tareas realizadas fueron las siguientes:

• Carga completa de datos en la base de datos del barco
• Pruebas funcionales y revisión del sistema en el barco
• Replicación de los datos cargados hacia las oficinas centrales de la naviera, de forma que los datos en la base de datos del barco y en oficina fueran los mismos. Ahora sí que los datos del barco iban a afectar al conjunto de la flota.
• Pruebas funcionales finales y revisión en el sistema del conjunto de la naviera
• Seguimiento

No fué necesario hacer las tareas presencialmente en el barco. Todo el proceso de carga se realizó en conexión remota desde las oficinas de Aeromarine a los equipos de las oficinas centrales del cliente.

Caso de éxito: Buenas prácticas de migración

Las buenas prácticas permiten aumentar la garantía de éxito del procedimiento. Las buenas prácticas que se usaron en esta migración fueron las siguientes:

Copias de seguridad: antes y después de la migración

Creación de varios repositorios: un repositorio origen o fuente, un repositorio temporal o piloto y un repositorio final

Buen cálculo y planificación de los tiempos con un cronograma  que prestó especial atención a los tiempos en los que el sistema en producción iba a estar inoperativo.

Infraestructura correcta de dimensionamiento

Staging (clonación) del origen y del piloto, de esta forma se pudieron realizar las tareas de limpieza, homologación y enriquecimiento de los datos; así como las simulaciones y pruebas funcionales necesarias.  

Creación de un documento de parámetros y referencias para controlar las transformaciones o cambios que se realizaron y usarlo como guía futura de referencia o consulta.

Reutilización de estrategias, procesos y scripts siempre que fue posible, en procesos de extracción, transformación y/o carga, disminuyendo tiempo y armonizando resultados.

Especial cuidado con problemas de caracteres y fechas. Se prestó especial atención a los triggers, procedimientos almacenados, constraints e intercalación. 

Se documentó el procedimiento, los parámetros y configuraciones utilizadas, el mapeo campo a campo realizado, las limpiezas, las irregularidades y cualquier transformación realizada.

Contamos con un equipo de trabajo idóneo de personas con experiencia en Sistemas de Información, Administración de las bases de datos, Usuarios del sistema en el cliente y Responsables que definieron las soluciones adoptadas durante el proceso de migración.

Conclusión

Aeromarine ha creado desde cero o ha migrado cientos de bases de datos a lo largo de los años. Con nuestra experiencia, nuestros clientes han visto cómo sus datos no se pierden, se incorporan de una forma fluída dentro de sus sistemas, se archivan o se transforman según los cambios que experimenta su negocio.  Incorporamos una nueva instalación a la empresa y los datos de 5 años registrados en una tecnología informática diferente, se volcaron dentro del sistema estándar del cliente de una manera ágil, optimizada y sin pérdidas. En esta entrada se habla de un caso en el sector marítimo, pero los principios y las buenas prácticas que se usaron se pueden aplicar en cualquier otro sector. Si desea más información, aquí está nuestro contacto