Criterios de selección y migración

La selección sana empieza por una lista de requisitos escrita antes de ver ninguna demostración, con una marca de obligatorio o deseable. Lo obligatorio elimina candidatos; lo deseable desempata. Sin esa lista, gana quien presenta mejor.

Entre los criterios que conviene fijar están el lugar donde se alojan los datos, el modelo de datos (riesgo, control, dueño, evidencia), la facilidad para exportar todo en un formato abierto, el esfuerzo de mantenimiento y la licencia. Las plataformas abiertas se publican con licencias distintas: de una se sabe que su código comunitario va bajo AGPLv3 con una carpeta comercial aparte, de otra que su núcleo usa la licencia pública de Mozilla 2.0, y de otra que es de código disponible con restricciones de modificación. Hay que leer el archivo de licencia de la versión que se va a instalar, y confirmarlo con el área jurídica, porque cambia lo que se puede hacer con ella.

La plataforma de Piedra Viva se midió contra cinco requisitos. En la tabla de evaluación cada uno tiene un resultado: cumple, cumple en parte o no cumple. Un obligatorio que se cumple a medias es el caso más peligroso, porque en el resumen se lee como un casi-sí y en la práctica puede bloquear una salida.

Consulta SELECT * FROM requisitos_de_piedra_viva.

Migrar de una hoja de cálculo no es copiar y pegar. Las filas duplicadas, las que no tienen dueño y las que cumplen ambas cosas a la vez se arreglan antes o durante la carga, y cada una tiene una decisión humana detrás. Para dimensionar el trabajo se cuenta cuántas filas pasan limpias.

Consulta SELECT * FROM hojas_a_migrar. En la hoja de riesgos, descuenta las filas con problemas sin contar dos veces las que tienen los dos.

El plan de migración lista cada dato de la hoja con su destino en la plataforma y el problema detectado. Los más frecuentes son los formatos de fecha distintos, las escalas con otros nombres y los campos de texto libre que la plataforma quiere como lista. Son pequeños, y si se pasan por alto, la carga entra pero el registro queda inconsistente.

Consulta SELECT * FROM plan_de_migracion.

Dos precauciones sirven para casi todas las migraciones. La primera es una prueba piloto con un subconjunto de los datos, que se verifica contra el original antes de cargar el resto. La segunda es la salida: antes de comprometerse, comprobar que se puede exportar todo en un formato abierto y reconstruir el registro en otro sitio. Una plataforma que no se puede dejar es una dependencia, aunque el código sea abierto.