El Proyecto-Trampa

Si preguntáramos a cualquier estudiante de informática cómo imagina el reto más arriesgado al que se enfrentará a lo largo de su carrera profesional, casi todos describirán un motor gráfico con sofisticados algoritmos; o un sistema en tiempo real que exija tal rapidez de procesamiento que haya que afinar a nivel de byte.

Y se equivocarían. Porque —para su sorpresa y, probablemente, la de más de un veterano— el Big Kahuna, «el gran tiburón blanco», el dunderklumpen, el proyecto informático con menos probabilidades de implementarse con éxito —o de hacerlo, sufrir mareantes sobrecostes y retrasos— es una migración de datos.

Sí, nada de llevar a sus límites el edge computing o crear una potente inteligencia artificial capaz de determinar con una solo foto tuya si eres del Dépor. Mover datos de un sitio a otro. Eso es lo que revelan los datos y estadísticas, si rascamos un poco Internet.

Según «Gartner», el 83 % de los proyectos de migración de datos fallan o incumplen su presupuesto y fecha de entrega. Una encuesta de «Bloor Research» refleja que el 75 % no alcanzan sus objetivos. De acuerdo a un estudio de «Experian», apenas el 36 % respetan el presupuesto inicial.

Por eso, minusvalorar un proyecto de migración de datos es uno de los errores más graves que puede cometer una empresa y, sin embargo, también de los más comunes. Es el proyecto-trampa por excelencia. Así que, aunque no trabajes en Informática, te interesa leer este artículo hasta el final para saber reconocerla y tratar de no caer en la misma.

Pero ¿por qué puede ser tan complicado algo aparentemente trivial como copiar datos de un sitio a otro?

Primero, porque el destino no suele ser idéntico al origen de la información. Los cambios van desde un sutil cambio en el modelo de datos a transformaciones más o menos complejas del formato de esos datos. La cosa empieza a complicarse cuando la migración supone un cambio de paradigma —por ejemplo, pasar de una base de datos relacional a una no-relacional— o implica trasladar a la nube información gestionada localmente.

O si debemos migrar datos de una aplicación a otra usando las APIs que nos proporcionan, pero sin conocer por completo el modelo subyacente. Algo que también nos puede pasar con nuestro propio software, porque el segundo problema más habitual en una migración suele ser la carencia de documentación sobre cómo se generan los datos que vamos a migrar y las dependencias de los mismos.

Mención especial merecen las bases de datos creadas directamente desde código, vía ORM, pero con la que luego empiezan a interactuar otras aplicaciones sin que —evidentemente— nada esté documentado.

Cuando por fin tengamos clara la lista exhaustiva de procesos que utilizan los datos a migrar, nos enfrentaremos al tercer problema más común, que es determinar qué datos queremos migrar, descartar o «limpiar»… y la lógica de negocio necesaria para poder hacerlo. Esa transformación de datos puede ir desde la estandarización de valores hasta la generación de metadatos previamente implícitos.

Por ejemplo, si antes teníamos una tabla de «programadores» y otra de «marketers» que vamos a volcar en una única de «empleados», con un campo rol que referencia a otra tabla de «roles», debemos asignar un valor determinado a los primeros y otro a los segundos. Más divertido aún son los casos en los que ese campo ya existe y lo que nos piden es estandarizar los valores del mismo. O, lo que es lo mismo, transformar «desarrollador», «programadora», «JavaScript Ninja» —y cualquier otra cosa que se le haya ocurrido a nuestros usuarios— en un único valor «developer».

Si conseguimos definir qué datos debemos migrar, cómo debemos hacerlo y qué procesos de negocio se verán afectados, aun tendremos que superar un cuarto reto: la posible necesidad de asegurar la disponibilidad de los datos durante una migración.

Cuando los datos de una compañía huelen a chamusquina suele ser porque su negocio está en llamas.

— Tom Redman, presidente de Data Quality Solutions

Porque dependiendo de la naturaleza y uso de los datos, podremos usar una estrategia u otra: un único Big Bang —lo que suele implicar la parada momentánea del servicio, mientras se completa la migración— o en paralelo, manteniendo el servicio en producción mientras esta se produce. Ambas tienen pros y contras.

Si superamos todos estos obstáculos, aun tendremos que lidiar con uno de los criterios de validación más complejos de la Informática. ¿O cómo podremos asegurar que todo se ha migrado con éxito sin repasar uno por uno todos los datos? Y, en el caso de que algo vaya mal, por mucho backup y proceso de rollback que tengamos, la única manera de asegurarnos de que no perderemos NADA de información es hacer el trabajo dos veces —en el antiguo sistema y en el nuevo— hasta que demos por bueno el período de pruebas. Eso o crear un sistema de sincronización que puede convertirse en un proyecto en sí mismo.

A pesar de todas estas dificultades, las organizaciones siguen sin dar demasiada importancia a los proyectos de migración de datos. Quizás porque el mejor resultado de una migración es que nadie la advierta. Que todo funcione como debe funcionar.

Quizás porque no se ganan «medallas» por liderar con éxito una migración de datos. Quizás porque —seamos sinceros— no se nota tanto como ver botoncitos nuevos en la interfaz.

Así que, si te asignan una migración de datos y no puedes esquivar el marrón, ten cuidado. No caigas en la trampa de minusvalorarla. Desgraciadamente, si hacemos caso a las estadísticas la mayoría lo hacemos.

Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!

---

---

---