Migrar el legado
sin caos
— y sin apagar el negocio
El 70% de las migraciones de sistemas fallan o superan presupuesto y tiempo. El 70% del presupuesto de TI se gasta en mantener lo que ya existe, no en crecer. Y la IA, mal usada, puede colapsar exactamente lo que prometía mejorar. No es un problema técnico. Es un problema de método, de negocio y de orden. Aquí está el método que funciona.
Son las 11 de la noche del viernes. Un equipo de TI acaba de completar la "migración del fin de semana". El plan era simple: apagar el sistema viejo el sábado a medianoche, encender el nuevo el lunes a las 8am. El lunes a las 8:05, el director de operaciones llama. El sistema de facturación no procesa órdenes. El director de finanzas llama. El ERP no tiene los saldos correctos. El director general llama. Nadie puede explicar qué pasó porque el sistema viejo ya no existe y el nuevo no tiene los datos que el negocio necesita para operar. Esta escena tiene un nombre: migración big bang. Y se repite en organizaciones de todo tamaño y sector con una frecuencia que los números hacen indefendible.
El problema no es la tecnología. No es el equipo. Es el enfoque: creer que un sistema que tardó 15 años en acumular lógica de negocio puede reemplazarse en un fin de semana. Que el dato migra igual que el proceso. Que la nueva plataforma entiende el negocio igual que la vieja. Y que la urgencia — esa urgencia que lleva años de "hay que migrar pronto" y de repente se convierte en "hay que migrar este fin de semana" — es un buen criterio de diseño.
Este artículo no habla de tecnología. Habla de negocio. De cómo una organización puede modernizar sus sistemas mientras sigue operando, sin apagar lo que funciona, sin perder la lógica que tomó años construir, y sin convertir un proceso de mejora en una crisis que cuesta más de lo que costaba quedarse quieto.
El problemaLo que el legado le cuesta al negocio — en lenguaje de negocio
La conversación sobre sistemas legados suele ocurrir en lenguaje técnico: versiones deprecadas, librerías sin soporte, deuda técnica, arquitectura monolítica. Ese lenguaje garantiza que el consejo directivo desconecte a los tres minutos. Traduzcan esos términos al idioma que importa, y la conversación cambia.
Un sistema legado que consume el 70% del presupuesto de TI en mantenimiento no está solo siendo ineficiente — está financiando la razón por la que la empresa no puede crecer. Cada peso gastado en parchar el sistema viejo es un peso que no fue a desarrollar la nueva capacidad que el negocio necesita. BCG documentó en 2024 que el 83% de las empresas considera la innovación una prioridad estratégica, pero solo el 3% está realmente preparada para ejecutarla — en muchos casos porque el sistema que debería habilitarla está atado a infraestructura que no lo permite.
El costo del legado no es solo el mantenimiento. Es la suma de cuatro componentes que raramente aparecen juntos en el mismo tablero directivo:
Las organizaciones subestiman el costo real de sus sistemas legacy entre el 70% y el 80% según Deloitte. No porque sean negligentes — sino porque los costos están distribuidos en múltiples centros de costo, equipos y líneas presupuestales que nadie ha sumado en el mismo ejercicio. El costo de oportunidad de no poder lanzar una funcionalidad nueva en 3 semanas —porque el sistema central tarda 6 meses en integrarse con cualquier cosa nueva— nunca aparece en ningún reporte. Y sin embargo, puede ser el número más grande de todos.
Las organizaciones descubren que el costo real de mantener sus sistemas legacy es 3.4 veces mayor que el presupuesto declarado cuando se incluyen todos los factores: ineficiencia operativa, talento especializado escaso y caro, fricción de integración con nuevas herramientas, velocidad de desarrollo reducida y el "impuesto a la innovación" — el costo de las cosas que no puedes hacer porque el sistema no lo permite. Ese último factor raramente aparece en un análisis de TCO estándar y es frecuentemente el más grande.
Deloitte Banking Survey 2024 · McKinsey "Breaking Technical Debt's Vicious Cycle" · Accenture Banking Technology Outlook 2025El métodoLa higuera estranguladora — y por qué es la metáfora más honesta de la migración
En la naturaleza tropical existe un árbol llamado higuera estranguladora. Sus semillas germinan en las ramas de otros árboles. La planta crece hacia afuera y hacia abajo, envolviendo gradualmente al árbol huésped. Décadas después, el árbol original ha desaparecido — no porque alguien lo talara, sino porque la nueva estructura creció lo suficiente para reemplazarlo sin que el proceso fuera disruptivo para el ecosistema.
En 2004, Martin Fowler describió este patrón como metáfora de la migración de software: el Strangler Fig. La idea es conceptualmente simple y operacionalmente precisa. No se apaga el sistema viejo el viernes para encender el nuevo el lunes. Se construye la nueva capacidad encima y alrededor del sistema existente, dominio por dominio, proceso por proceso. El sistema viejo sigue operando. La nueva arquitectura absorbe funcionalidad de forma gradual. Y el sistema original se retira cuando ya no sostiene nada que el nuevo sistema no cubra mejor.
Este patrón aplica con la misma precisión a cuatro contextos distintos que frecuentemente se gestionan como si fueran problemas separados — y no lo son:
Contexto 1 — El sistema core (ERP, CRM, sistemas propietarios)
El sistema que gestiona las operaciones centrales del negocio — facturación, inventario, clientes, logística — no puede apagarse. Pero puede envuelta. La nueva plataforma se instala como capa de orquestación: los procesos nuevos viven ahí desde el inicio. Los procesos existentes migran uno a uno, validados en producción antes de que el sistema viejo los ceda. La migración puede tomar meses o años. La operación no se interrumpe en ningún momento.
Contexto 2 — El monolito que se rompe en microservicios
Una aplicación monolítica — donde todo el código vive junto y cualquier cambio puede afectar cualquier función — se moderniza exactamente con el mismo patrón. No se reescribe el monolito completo. Se extrae un dominio funcional, se construye como servicio independiente, se valida en producción paralela, y el monolito cede esa funcionalidad cuando el servicio está estable. El resultado final es una arquitectura de microservicios construida de forma incremental, sin el riesgo de la reescritura completa.
Contexto 3 — Los datos: la migración más ignorada y la más costosa cuando falla
El 83% de los proyectos de migración de datos fallan o superan presupuesto y tiempo, según Gartner. La razón más frecuente no es técnica: es que nadie modeló la calidad, estructura y semántica de los datos origen antes de comenzar a moverlos. Los datos migran con sus defectos. El nuevo sistema hereda la suciedad del viejo. El mismo principio aplica: los datos se migran dominio por dominio, con contratos de calidad definidos antes del movimiento, con validación en producción paralela, y con el sistema origen disponible como respaldo hasta que los datos migrados demuestren confiabilidad operativa.
Contexto 4 — La operación híbrida: una etapa, no un destino
Muchas organizaciones operan en modo híbrido durante años — parte en el sistema viejo, parte en el nuevo — no por elección estratégica, sino porque la migración se detuvo sin completarse. El modo híbrido controlado es una herramienta de transición válida. El modo híbrido indefinido es el síntoma de una migración que no tiene criterios de avance ni responsable ejecutivo claro. La diferencia entre los dos está en si hay un plan con fechas y criterios de cierre, o si "lo resolveremos después" es la respuesta cada vez que alguien pregunta cuándo se migra la siguiente parte.
El mecanismoLas cuatro olas que reemplazan el big bang
La migración por olas no es solo una preferencia metodológica — es la respuesta a la pregunta que ninguna organización debería ignorar: ¿qué pasa si esta etapa falla? En la migración big bang, la respuesta es catastrófica. En la migración por olas, la respuesta es: activamos el rollback de esta ola, el negocio sigue operando con la arquitectura anterior para ese dominio, y resolvemos antes de avanzar.
Meses 1–3
Meses 4–9
Meses 10–18
Mes 18+
La IA en este contextoPuede acelerar todo. O puede colapsar exactamente lo que prometía mejorar.
La inteligencia artificial llegó a la conversación de migración de sistemas con dos promesas contradictorias. La primera, documentada y real: la IA puede acelerar el análisis de código legacy, detectar dependencias ocultas, generar pruebas automáticas, identificar patrones en datos históricos y asistir en la documentación de lógica de negocio que vive implícita en código de 20 años. McKinsey documenta que las empresas que combinan reducción de deuda técnica con IA en sus migraciones reportan reducciones de 30-50% en carga operativa y ciclos de desarrollo significativamente más rápidos.
La segunda promesa, peligrosa e irresponsable: que la IA puede migrar un sistema sin que nadie entienda el negocio que ese sistema soporta. Que el modelo puede leer el código viejo, entender qué hace y reproducirlo en la nueva arquitectura sin intervención humana experta. Esta promesa no solo es falsa — es activamente dañina. Un sistema legacy de 15 años no solo tiene código. Tiene lógica de negocio acumulada en comentarios, en convenciones de nomenclatura, en excepciones que alguien codificó una tarde de 2009 para resolver un caso específico del cliente más grande de la empresa, y en la memoria de las personas que lo operan. Ningún modelo de IA actual puede leer eso solo.
McKinsey reporta que las empresas con sistemas fragmentados o legados son 30% más propensas a sufrir retrasos en la implementación de IA — porque la IA requiere datos limpios, procesos definidos y arquitecturas que permitan la integración. La deuda técnica no acumulada es la barrera de entrada más frecuente para aprovechar la IA de forma real. El orden correcto no cambia: primero el modelo de negocio, luego el proceso, luego los datos, luego la arquitectura, y al final la IA que multiplica el valor de todo lo anterior.
"El mayor error que cometemos en proyectos de modernización es tratar el sistema como el problema. El sistema es el síntoma. El problema es que nadie modeló el negocio antes de construirlo, y nadie lo modeló antes de migrarlo."— Jorge Mercado · #JMCoach · Experiencia directa en migraciones en sectores regulados
El elefante en la salaParchear, ignorar y operar en versiones deprecadas — lo que las organizaciones prefieren no discutir
Existe una tercera opción que no aparece en ninguna presentación de transformación digital, pero que es la que más organizaciones eligen en la práctica: no hacer nada. Parchear el sistema viejo. Actualizar versiones cuando es absolutamente inevitable. Y esperar que el problema se resuelva solo — o que el siguiente CIO lo herede.
Esta opción tiene consecuencias documentadas y predecibles. Los sistemas operan sobre versiones de librerías, frameworks y lenguajes que tienen ciclos de vida definidos. Cuando una versión llega al final de su soporte, el proveedor deja de publicar parches de seguridad. El sistema sigue funcionando — pero cada vulnerabilidad que se descubre después de esa fecha queda sin corrección oficial. El banco que fue comprometido por Midnight Blizzard en enero de 2024 — el grupo ruso que accedió a correos del liderazgo senior de Microsoft — lo fue a través de un componente legacy de test que tenía credenciales válidas pero sin los estándares de seguridad actuales. Microsoft lo reconoció públicamente y calificó la situación como urgencia de "mover más rápido" en la modernización de sus propios sistemas legacy.
Deloitte documenta que el departamento de TI promedio invierte solo el 19% de su presupuesto en construir nuevas capacidades. El 81% restante va a operar, mantener e integrar lo que ya existe. Esa proporción no es sostenible en un mercado donde el competidor nativo digital puede lanzar una nueva funcionalidad en días y la empresa con el sistema legacy tarda meses o años. IDC advierte que para 2026, más del 90% de las organizaciones sufrirán consecuencias adversas por escasez de talento en TI — en gran parte porque el talento disponible no quiere trabajar en tecnologías obsoletas. Los programadores de COBOL tienen en promedio 70 años. Los de RPG, similar. Cuando esa generación se retire, el conocimiento de esos sistemas se va con ellos.
El valor que más cuesta entenderSimplicidad y flexibilidad — los dos atributos que las urgencias siempre sacrifican primero
Hay un patrón que se repite en cada proyecto de migración que termina en caos: en algún momento del proceso, la urgencia tomó el control del diseño. Las fechas de entrega se fijaron antes de que los requerimientos estuvieran claros. Los compromisos con el proveedor se firmaron antes de que el negocio modelara sus procesos. Y la solución que finalmente se construyó — bajo presión, en tiempo reducido, con el equipo dividido entre operar el sistema viejo y construir el nuevo — fue todo lo contrario de simple y flexible.
La simplicidad en arquitectura no es pobreza técnica. Es la evidencia de que quien diseñó el sistema entendió el problema con suficiente profundidad como para resolverlo sin complejidad innecesaria. El vacío entre producto, negocio y tecnología — ese espacio donde nadie tiene la autoridad ni el lenguaje para hacer las preguntas que conectan las tres perspectivas — es el origen del 90% de los sistemas que terminan siendo demasiado complejos para operar, demasiado rígidos para evolucionar y demasiado costosos para mantener.
El sistema bien diseñado no es el más sofisticado. Es el que puede ser entendido por cualquier persona del equipo en su primer día. El que puede modificarse sin generar efectos inesperados en otros módulos. El que puede conectarse con una nueva herramienta sin requerir un proyecto de seis meses. Esa flexibilidad no es accidental — es la consecuencia de haber tomado las decisiones de diseño correctas antes de escribir la primera línea de código, no después de que el sistema lleva diez años en producción y nadie sabe exactamente cómo funciona.
La urgencia no es un criterio de diseño. Es el antídoto del diseño. Cada vez que la urgencia define la arquitectura — en lugar de definir el ritmo dentro de una arquitectura bien pensada — el resultado es un sistema que soluciona el problema de hoy y crea el problema del siguiente ciclo. El método correcto es gradual, estructurado y aburrido. Los resultados son extraordinarios precisamente porque nadie tuvo que apagar nada para obtenerlos.
Para el directivoLas preguntas que valen más que cualquier propuesta técnica
Si estás frente a una propuesta de migración de sistemas, frente a un CTO que explica por qué "hay que migrar ya", o frente a un proveedor que promete que su plataforma resuelve todo en seis meses, estas son las preguntas que debes poder responder antes de firmar cualquier cosa:
La conclusiónEl negocio no puede esperar. Y tampoco puede dejar de operar mientras migra.
La tensión entre urgencia y método no tiene una resolución simple. El negocio necesita modernizarse y lo necesita ya. Pero "ya" definido como "apagar el viernes y encender el lunes" es la receta documentada del fracaso. La respuesta correcta no es más lenta que el big bang — es más confiable. Y la confiabilidad no tiene precio cuando lo que está en juego es la operación de una empresa.
Las organizaciones que migran bien no son las que tienen más presupuesto ni las que tienen los mejores proveedores. Son las que hicieron la pregunta correcta antes de empezar: ¿qué le puede pasar a esta etapa, y si pasa, cómo seguimos operando? Esa pregunta, respondida con honestidad y con un plan de rollback probado para cada ola, es lo que separa a una migración que el negocio no nota de una que aparece en las noticias.
Los sistemas no son eternos. Las herramientas se deprecan, las versiones llegan a su fin de vida, los proveedores discontinúan soporte. Ignorar ese ciclo no lo cancela — lo encarece. Cada año de postergación suma interés a la deuda técnica. Y la deuda técnica, como la financiera, llega un momento en que su servicio consume más energía que el negocio que financia.
La simplicidad, la flexibilidad y el gradualismo no son limitaciones del método. Son su ventaja competitiva más duradera. El sistema que puede evolucionar sin caos es el sistema que permite que el negocio que lo usa también evolucione. Y eso, al final, es el único resultado que importa.
Fuentes: Gartner IT Research 2024 · McKinsey "Breaking Technical Debt's Vicious Cycle" 2024 · McKinsey Digital Transformation Report 2024 · IDC Enterprise IT Forecast 2024 · BCG Innovation Report 2024 · Panorama Consulting ERP Report 2025 · Deloitte Banking Survey 2024 · Accenture Banking Technology Outlook 2025 · Schneider Electric Technical Debt Report 2025 · Martin Fowler "Strangler Fig Application" (pattern) · IT Convergence Technical Debt Report 2025 · DataFlowMapper Migration Cost Analysis 2025.
Arquitectura empresarial en sectores regulados · CNBV · COFEPRIS · ASEA
Migraciones de sistemas legados en producción · IA aplicada con criterio de negocio
Legado · Migración · Strangler Fig · Arquitectura · Monolito · Microservicios · Datos · IA · Deuda Técnica · Negocio · Gartner · McKinsey · #JMCoach
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.