¿Cuándo hacer proyectos de migración de tecnología en un sistema de información?
Una pregunta muy complicada de responder, porque depende de muchos parámetros. Nos vamos a ceñir a los más importantes (los realmente necesarios para migrar de tecnología un sistema de información):
- Nuestro sistema de información va a dejar de tener soporte en breve. Puede que nuestras licencias de uso de un software propietario dejen de ser atendidas por el soporte por el fabricante. También puede que el mantenimiento de nuestro sistema de información apenas disponga de personal especialista (por obsolescencia tecnológica).
- También, nuestro sistema de información está soportado bajo una infraestructura y un mantenimiento que tiene una tendencia notable al alza en coste.
- Nuestro sistema de información no posee las funcionalidades requeridas por el negocio. Además, el coste de los cambios es superior al coste de un nuevo sistema modernizado. Aquí entran parámetros como la rigidez del sistema, la necesidad de cambio constante y a corto plazo ante coste elevado, etc.
Consejos básicos a tener en cuenta en los proyectos de migración de tecnología
- Nunca migres a la tecnología más punta y menos probada, ya que incrementas el riesgo de desvío del plan de implantación, además del riesgo de mayor coste de mantenimiento.
- No escojas tecnologías nuevas para un equipo de trabajo de proyecto sin tener en cuenta el soporte a dicha tecnología (acompaña al equipo con expertos). No es suficiente formar al equipo en la nueva tecnología, es importante eliminar el riesgo de la falta de experiencia con acompañamiento.
- Valora las opciones tecnológicas bajo un criterio común. No vas a evitar que la nueva tecnología acabe obsoleta, pero sí puedes evitar errores ya cometidos y evaluar las tecnologías candidatas con criterios que aseguren una mayor duración en el tiempo.
- No hagas el plan de migración sin haber hecho una prueba de concepto, proyecto piloto o beta testing. La tecnología hay que probarla. Dentro de los criterios de evaluación de la mejor solución deberían de aparecer parámetros que puedan ser obtenidos tras una pequeña implantación de la tecnología en el negocio.
Otros consejos secundarios
- Divide y vencerás. Haz un plan en donde la migración de la tecnología sea escalonada. Escoge la unidad de migración (computadora, servicio, funcionalidad, etc) y prepara un plan que haga que los subsistemas de información vayan migrando poco a poco. Esto significa que la tecnología nueva y la actual deben de poder convivir. Te aseguro que el sobrecoste en tiempo y en licencias habrá valido la pena frente al impacto que supondría en la empresa el que se materialice el riesgo de caída de los sistemas.
- Aprovecha y unifica la tecnología mientras puedas (puede que en el sistema actual no lo tengas todo unificado). No todos las áreas de un negocio funcionan igual, pero tecnológicamente puedes unificar partes del sistema de información: infraestructura común, estándares comunes, procesos de mantenimiento comunes, equipos de mantenimiento comunes, etc.
- Involucra a todo el negocio o a los departamentos impactados. Aunque sea una migración tecnológica, es importante que se entienda que los interesados son los consumidores del sistema de información. Un cambio tecnológico no tiene porque implicar cambios funcionales, pero seguramente sí habrá cambios de rendimiento (a mejor), cambios en costes asociados (a mejor), y posiblemente mejores tiempos de respuesta en los proyectos de construcción de cambios en el sistema. Los interesados tienen que saberlo.
Profundización Analítica: El error del enfoque «Big Bang»
La literatura clásica de gestión de proyectos a menudo subestima la fricción real en los proyectos de migración de sistemas. Optar por un despliegue tipo «Big Bang» (apagar el sistema antiguo y encender el nuevo de golpe) es la causa número uno de los Epic Fails modernos. La complejidad no reside en la nueva tecnología, sino en la deuda técnica indocumentada del sistema legacy. Cuando un Project Manager no audita exhaustivamente los datos históricos, el equipo técnico se encuentra con integraciones «fantasma» que rompen la ruta crítica en el momento del despliegue.
Para mitigar esto, la tendencia actual es el enfoque de migración paralela o estrangulamiento (Strangler Fig Pattern). Sin embargo, este enfoque requiere una orquestación brutal. Aquí es donde los PMs modernos utilizamos modelos de Inteligencia Artificial para analizar miles de líneas de logs del sistema antiguo, detectando cuellos de botella y dependencias que ningún humano podría mapear manualmente en un tiempo razonable. La IA no migra el sistema, pero expone las minas terrestres antes de que el equipo pise sobre ellas.
Preguntas que te podrías estar haciendo
Es la dependencia de un solo proveedor; se evita utilizando estándares abiertos o soluciones Open Source que permitan migrar datos fácilmente en el futuro.
Si el coste de mantener un código obsoleto supera el coste de desarrollar un sistema nuevo con tecnologías modernas, la migración es financieramente obligatoria.
Permiten migrar funcionalidades de forma independiente (divide y vencerás), reduciendo el riesgo de fallo total del sistema durante el proceso.
Involucrando a los departamentos impactados desde el inicio para que entiendan las mejoras en rendimiento y tiempos de respuesta.
Los riesgos más críticos incluyen la pérdida o corrupción de datos, el tiempo de inactividad operativo no planificado (downtime) y el descubrimiento tardío de dependencias ocultas en el código legacy que rompen la compatibilidad con el nuevo entorno.
El «Big Bang» reemplaza todo el sistema en una sola operación arriesgada. La migración progresiva (como el patrón Strangler) reemplaza funcionalidades gradualmente, permitiendo que ambos sistemas coexistan y reduciendo drásticamente el impacto de un posible fallo.
La IA se utiliza en la fase de auditoría para perfilar bases de datos masivas, detectar anomalías, limpiar registros duplicados y mapear automáticamente esquemas de datos antiguos hacia las nuevas estructuras, reduciendo el trabajo manual en un 60%.
Es vital establecer un plan de comunicación de crisis previo al despliegue. Los Project Managers deben reportar el estado de la migración utilizando métricas de validación de datos (data integrity) en lugar de simples porcentajes de avance de tareas.
Conclusión
Evalúa las tecnologías nuevas antes del proyecto y pruébalas, guía al equipo de trabajo con un grupo de expertos, prepara un plan con una migración basada en subsistemas y comunica lo que vas a ganar con el proyecto a los interesados. He extraído estos consejos como lecciones aprendidas de aquellos proyectos que he vivido en donde el objetivo ha sido una mejora tecnológica.
Referencias Técnicas y Bibliografía
- Fowler, M. (2004): «StranglerFigApplication». (Fundamentos sobre la migración progresiva de sistemas legacy).
- Project Management Institute (PMI): «Navigating the Complexity of IT Migrations». (Estándares de mitigación de riesgos en transiciones tecnológicas).
- IEEE Software: «Legacy System Evolution Towards Modern Cloud-Native Architecture». (Análisis empírico de fallos en migraciones).
Autor
Antonio Gutiérrez es un Jefe de Proyectos IT con una amplia trayectoria en la dirección de equipos técnicos y el desarrollo de negocios online. Especialista en optimización de procesos y gestión de proyectos con tecnología IA, destaca por su capacidad para integrar soluciones innovadoras en entornos digitales complejos. Con una fuerte vocación por la formación y la responsabilidad profesional, Antonio se dedica a transmitir su experiencia en jefatura de proyectos para ayudar a otros a evolucionar en el sector tecnológico. Actualmente, ofrece consultoría estratégica y recursos especializados para profesionales que buscan liderar con éxito la transformación digital.
