· 1 min de lectura
Documentar para no reaprender errores
Por qué, antes de migrar una reportería legacy a la nube, conviene documentar el modelo de datos, y cómo eso cambia la forma en que un equipo escribe consultas.
Cuando me tocó planificar la migración de una reportería legacy hacia un data warehouse en la nube, la tentación era partir migrando consultas. No lo hice. Primero documenté el modelo de datos.
El problema de fondo
Las bases de datos legacy suelen ser enormes y estar poco documentadas. Nadie conoce todas sus tablas, y cada reporte nuevo parte con la misma pregunta: ¿dónde está este dato?
La respuesta suele estar en una consulta antigua, en la memoria de alguien o en una tarde de prueba y error. Y cada vez que alguien la redescubre, el equipo paga el mismo costo.
Un índice consultable
Armé un índice del esquema donde se puede buscar por tabla, vista o columna. Es simple, pero cambia la dinámica: encontrar un dato pasa a ser una búsqueda, no una investigación.
Documentar también los errores
Lo más útil vino después: un registro de convenciones y aprendizajes. Por ejemplo:
- Qué cruces devuelven duplicados si no se filtran bien.
- Qué columnas parecen lo mismo y no lo son.
- Qué diferencias hay entre el sistema legacy y el modelo nuevo para un mismo dato.
Cada error costoso queda escrito una vez, para que nadie lo vuelva a cometer.
Migrar es mapear
Con la documentación lista, el mapeo hacia el modelo en la nube se vuelve un ejercicio ordenado: reporte por reporte, qué se migra igual, qué cambia y qué falta.
La lección
Documentar parece lento, pero no documentar es más lento: solo que el costo se paga de a poco, cada vez que alguien vuelve a empezar.