En el mundo de la transformación digital, pocas frases son tan engañosas como 'la migración está al 80%'. Esta afirmación, repetida en innumerables presentaciones ejecutivas, esconde una realidad mucho más compleja: el verdadero éxito de un proceso de migración no se mide por cuántos sistemas nuevos se han puesto en marcha, sino por cuántos sistemas antiguos se han apagado definitivamente. La experiencia de más de dos décadas trabajando con empresas de todos los tamaños nos ha enseñado que el último 20% de cualquier migración concentra los mayores riesgos, costes ocultos y decisiones organizativas que determinan si el proyecto será un éxito o un lastre financiero a largo plazo.
Cuando una organización declara que ha migrado el 80% de sus cargas de trabajo, lo que suele significar en la práctica es que el 80% de las aplicaciones ya tiene un nuevo hogar: contenedores funcionando, pipelines verdes, dashboards impecables. Sin embargo, el entorno legacy sigue operativo porque un puñado de procesos críticos —un batch nocturno que nadie recuerda quién creó, un extracto de reporting que finanzas necesita el tercer día de cada mes, dos integraciones con un socio cuyo contrato se renueva el año que viene— todavía dependen de la infraestructura antigua. El resultado es que la empresa paga dos veces: por la nueva plataforma y por la vieja. No solo en infraestructura, sino en dos equipos de guardia, dos conjuntos de parches de seguridad, dos pistas de auditoría y un costoso trabajo de sincronización entre ambos mundos. Esa capa de doble ejecución, que rara vez aparece en el caso de negocio original, se convierte en el código más frágil de todo el programa y en uno de los mayores generadores de deuda técnica oculta.
Este fenómeno, que podríamos llamar el 'impuesto de doble ejecución', es especialmente peligroso porque nadie lo presupuesta. El caso de negocio se construyó sobre los ahorros que se obtendrían una vez que el sistema antiguo desapareciera. Si el sistema antiguo nunca desaparece, el caso de negocio era ficción. Y aun así, el programa se declara discretamente como un éxito porque se movió el 80% de algo. Para evitarlo, la métrica correcta no es 'porcentaje migrado', sino 'sistemas legacy apagados'. Cada mes que ambos entornos coexisten, la empresa acumula un coste operativo que erosiona el retorno de la inversión previsto. Por eso, en Q2BSTUDIO defendemos que una migración solo está completa cuando el último servidor antiguo se desconecta, no cuando el nuevo empieza a funcionar.
El obstáculo real del último 20% no es técnico, sino arqueológico. Las aplicaciones que quedan atrás comparten un rasgo común: nadie sabe exactamente qué hacen. Quienes las escribieron ya no están en la empresa; la documentación, si existe, describe una intención de hace diez años que el código dejó de respetar hace siete. Hay lógica de negocio oculta en procedimientos almacenados, en programadores a los que nadie se conecta, en ficheros de configuración con comentarios como 'no tocar, preguntar a Raj'... y Raj se jubiló. No se puede reescribir lo que no se puede describir. La respuesta estándar —asignar a un ingeniero senior para que haga 'descubrimiento'— suele convertirse en una tarea de seis semanas por sistema, lo que alarga la cola durante años y acaba por abandonarse, manteniendo ambas plataformas para siempre.
Aquí es donde la inteligencia artificial generativa está demostrando un valor real, pero no donde la mayoría espera. No se trata de usar un modelo para reescribir un monolito en microservicios —eso sigue siendo una quimera—, sino de leer. Un modelo de lenguaje bien orientado puede procesar un código legacy y entregar, en una tarde en lugar de seis semanas, un inventario de todos los sistemas externos con los que se comunica, una relación de todos los trabajos programados, una descripción en lenguaje natural de lo que parece hacer cada procedimiento almacenado, y —lo más valioso— una lista de cada lugar donde el comportamiento real contradice la documentación. Ese mapa, no el código reescrito, es el verdadero activo. Sin embargo, el modelo también describirá con seguridad comportamientos que no existen, lo que en una migración es peor que no tener descripción, porque alguien construirá contra eso. Por eso, en nuestros proyectos imponemos una regla: el modelo no puede afirmar nada. Produce afirmaciones con citas: fichero, línea, nivel de confianza, y un estado de verificación pendiente. Cada afirmación que toca dinero, cumplimiento normativo o estado del cliente se verifica contra tráfico de producción reproducido antes de convertirse en requisito. Así, la arqueología deja de ser la razón por la que el programa muere.
Una vez que se sabe lo que hace el sistema legacy, hay que abandonarlo. El enfoque clásico —el 'big bang'— tiene mala fama con razón: todo el mundo sabe que es una mala idea, pero todo el mundo lo hace porque la alternativa parece más difícil de planificar. La alternativa es poner una costura. Hacer que el sistema legacy emita un evento por cada cambio de estado relevante, y que el nuevo servicio lo consuma. Durante un tiempo, ambos sistemas están vivos: el legacy sigue siendo la fuente de verdad para las escrituras, y el nuevo construye su propio estado a partir del flujo de eventos, comparando los resultados en silencio, en producción, con tráfico real, hasta que se dejan de encontrar diferencias. Entonces se invierte la escritura: el legacy se convierte en consumidor en lugar de productor. Luego se apaga también. Esta estrategia, más lenta sobre el papel, es dramáticamente más rápida que el big bang si se cuentan los cortes fallidos y las reversiones. Permite equivocarse de forma segura, descubriendo que el legacy redondea de una manera que nadie documentó, o que aplica una regla de descuento que solo se dispara para cuentas creadas antes de cierta fecha. Es mejor encontrar eso mientras el sistema antiguo sigue siendo autoritativo, no durante un fin de semana de migración con el CFO en la línea.
El último paso, y quizás el más descuidado, es el desmantelamiento. No genera demos, no entrega funcionalidades, no tiene visibilidad. Cuando los presupuestos se aprietan en el mes nueve, la corriente de retirada siempre es la primera en posponerse, porque retrasarla no tiene un coste visible en el trimestre. Por eso, en nuestra metodología, el desmantelamiento no puede ser una fase al final: debe ser un flujo de trabajo financiado, con un responsable nombrado desde el día uno y una función de presión externa al equipo de ingeniería. Un contrato de hardware que no se renueva, una licencia que expira, un soporte técnico con fecha de caducidad. Algo que el programa no pueda extender silenciosamente tres meses en un comité de dirección.
En Q2BSTUDIO, especialistas en desarrollo de aplicaciones a medida y servicios cloud, sabemos que las métricas que realmente importan son: número de sistemas legacy completamente retirados, meses totales de doble ejecución acumulados (y si esa cifra está bajando), porcentaje del tráfico de producción servido todavía por la ruta legacy, y el coste recurrente del entorno antiguo comparado con el caso de negocio que financió el programa. Ninguna de estas métricas es halagüeña en el primer año. Precisamente por eso son útiles: la métrica halagüeña es la que permite que un programa dure tres años y termine con dos plataformas en lugar de una.
Después de más de veinte años en el sector, hemos llegado a una conclusión clara: la parte difícil de la modernización ya no es la arquitectura. Los patrones están resueltos, las plataformas maduras, y podemos montar un equipo que construya un ecosistema Kubernetes limpio con pipelines adecuados y límites de servicio sensatos. Lo que no ha visto facilitarse es apagar lo viejo. Eso es un problema organizativo disfrazado de problema técnico, y no se resuelve con mejor arquitectura, sino con alguien que sea dueño de la fecha de eliminación y esté dispuesto a no ser popular en el mes nueve. La migración no termina cuando la nueva plataforma se pone en funcionamiento. Termina cuando alguien desmonta el rack del sistema antiguo. Y para lograrlo, cada empresa necesita un socio tecnológico que entienda tanto la parte técnica como la humana, que sepa aplicar IA para desentrañar sistemas heredados, que integre servicios cloud en AWS y Azure con ciberseguridad y business intelligence, y que construya agentes de IA que automaticen la verificación de eventos. Porque al final, la tecnología es el medio; el objetivo es liberar a la organización del peso del pasado.
