Antes de trasladar tus datos, pregúntate si es necesario hacerlo

Si eres ingeniero o arquitecto de datos y te han encargado la modernización de una base de datos, la conversación suele venir ya con una conclusión preestablecida. Por ejemplo, si hay que eliminar el sistema heredado o si hay que trasladar los datos. A la hora de plantearse la migración de datos, es importante preguntarse si la migración de datos es realmente el enfoque adecuado.

Por qué se elige la migración por defecto

La migración de bases de datos es un proceso bien conocido que cuenta con un conjunto de herramientas bien consolidado. SQL Server Migration Assistant, AWS Database Migration Service, Azure Migrate y una amplia gama de plataformas de terceros hacen que la migración parezca un problema ya resuelto. Evaluar herramientas, estimar plazos y elaborar un plan de migración son tareas que los equipos saben cómo llevar a cabo.

Lo que no se entiende tan bien es por qué se plantea la migración en primer lugar. La razón que se suele aducir es la modernización: pasar de un sistema local heredado a una plataforma en la nube, consolidar almacenes de datos fragmentados o habilitar capacidades analíticas que el sistema actual no admite.

La verdadera razón, en muchos casos, es que resulta difícil realizar consultas en el sistema actual. A continuación se enumeran algunos de los problemas más habituales de los sistemas heredados:

• Informes tardíos

• Imposibilidad de conectar de forma fiable las herramientas de BI

• Los analistas no pueden extraer datos sin la ayuda del departamento de informática o de ingeniería.

Aunque los datos en sí están bien, la capa de acceso no lo está. Se propone la migración como solución porque es visible y cuantificable, pero no resuelve el problema real.

Cuánto cuesta realmente la migración

Durante la migración, se ejecutan dos sistemas en paralelo. El sistema antiguo no puede darse de baja porque la producción sigue dependiendo de él, mientras que el nuevo sistema debe alimentarse con datos, validarse y mantenerse sincronizado hasta que se determine la ventana de transición. Ese periodo de funcionamiento en paralelo supone un elevado coste en tiempo de ingeniería, costes de infraestructura y atención por parte de la organización.

La migración no resuelve necesariamente todos los problemas relacionados con los datos. Por ejemplo, las consultas que funcionaban de forma aceptable en la base de datos antigua pueden comportarse de manera diferente en la nueva, y si se ha dejado algún sistema en funcionamiento porque su retirada resultaba demasiado arriesgada, ahora tendrás que mantener indefinidamente un proceso de sincronización entre la antigua y la nueva.

Nada de esto significa que la migración no sea nunca la solución adecuada. A veces, los datos realmente necesitan trasladarse a una plataforma que los gestione mejor. Pero el coste técnico y el riesgo operativo de la migración merecen el mismo análisis que sus ventajas.

El problema de acceso que la migración está tratando de resolver

Cuando el verdadero motivo de una migración es el rendimiento de las consultas o la conectividad con herramientas de BI, el abanico de soluciones es más amplio de lo que parece.

Un sistema heredado al que resulte difícil acceder mediante una herramienta de BI no tiene por qué ser necesariamente un sistema que deba sustituirse. En cambio, lo que requiere es una capa de acceso más eficaz. Los controladores ODBC y JDBC basados en estándares proporcionan a las herramientas de BI, las plataformas de análisis y los flujos de integración una interfaz SQL coherente para acceder a fuentes a las que actualmente no pueden llegar. Los datos permanecen donde están, mientras que las capas de generación de informes y análisis operan directamente sobre ellos.

Esto resulta especialmente relevante para aquellas organizaciones que ya disponen de datos en formatos como Apache Iceberg o que están barajando la posibilidad de utilizar Trino como capa de consulta. Trino es un motor de consultas SQL distribuido que permite consultar datos de múltiples fuentes simultáneamente, incluidas las tablas de Iceberg, sin necesidad de mover ni copiar los datos.

Cuándo la migración es y cuándo no es la respuesta adecuada

La migración tiene sentido cuando la propia plataforma es el factor limitante. Si un sistema heredado no puede gestionar los volúmenes de datos que necesita la empresa, si carece de las capacidades de seguridad y cumplimiento normativo exigidas por la legislación, o si se acerca al final de su vida útil sin perspectivas de soporte por parte del proveedor, se trata de auténticos problemas de plataforma que justifican un cambio de plataforma.

La migración no es la solución adecuada cuando el factor limitante es el acceso. Los informes lentos, las conexiones de BI poco fiables y la dependencia de los analistas respecto al equipo de ingeniería para la extracción de datos son síntomas de un problema de conectividad. Resolverlos trasladando los datos añade meses de trabajo y una complejidad operativa continua a un problema que un «driver» podría solucionar en cuestión de días.

La pregunta clave a la hora de tomar una decisión es, pues: si todas las herramientas de tu pila de análisis pudieran consultar directamente tu sistema actual, ¿seguirías necesitando realizar la migración? Para muchas organizaciones, la respuesta sincera es «no».

Considerar la conectividad como infraestructura

En la mayoría de los debates sobre migración, se tiende a considerar el acceso a los datos como una característica de la base de datos, en lugar de como una cuestión independiente relacionada con la infraestructura. Si resulta difícil realizar consultas en la base de datos, se da por sentado que es la base de datos la que debe cambiar. La alternativa —crear una capa de acceso fiable sobre el sistema existente— rara vez recibe la misma atención.

Simba, de insightsoftware, es la capa de conectividad en la que confían las principales plataformas de datos del mundo —entre ellas, Google, Microsoft y Databricks— para impulsar sus propios productos de acceso a datos. Esa misma conectividad basada en estándares ODBC y JDBC, que abarca bases de datos heredadas, plataformas en la nube, sistemas SaaS, almacenes NoSQL y motores de consulta como Trino y Presto, está a disposición de los equipos empresariales a través del catálogo de controladores de Simba. Cada controlador expone su fuente a través de una interfaz SQL compatible con Tableau, Power BI, Logi Symphony y otras plataformas importantes de BI.

Un controlador Simba para Trino conecta cualquier herramienta de BI compatible con ODBC o JDBC directamente a esa capa de consulta, lo que permite a los analistas acceder mediante SQL a datos a los que antes no se podía acceder sin un proyecto de migración.

Por poner un ejemplo concreto: una organización cuyos datos operativos se encuentren repartidos entre bases de datos locales y almacenamiento en la nube podría utilizar Apache Iceberg como formato común de tablas y Trino como motor de consultas, para luego conectar Power BI, Tableau o Logi Symphony a través de un controlador Simba Trino. Los datos nunca se mueven. La experiencia analítica es idéntica a la de realizar consultas en un almacén de datos moderno en la nube. Para obtener más información sobre cómo funciona esto en la práctica, insightsoftware ha explicado en detalle la integración entre Apache Iceberg y el controlador Simba aquí.

Las organizaciones que se enfrenten a la decisión de realizar una migración deben sopesar las ventajas de una capa de conectividad frente al impacto de una migración completa. Los sistemas heredados merecen ser modernizados, y una mejor capa de acceso permite alcanzar el mismo resultado que una migración sin los costes ni los riesgos adicionales.

¿Estás listo para saber más? Lee nuestro informe técnico sobre el marco para la toma de decisiones en materia de conectividad de datos.