3.6 Modernización de sistemas heredados

Visión general y motivación

Los sistemas heredados son los sistemas que sostienen el mundo. Los libros mayores de banca, los motores de tributación y prestaciones, los sistemas de control aéreo y de defensa, la administración de pólizas de seguro y los registros públicos en los que depende toda una sociedad son, con frecuencia, décadas antiguos. Muchos están escritos en COBOL (Lenguaje Común Orientado a Negocios) u otras tecnologías envejecidas, y aun hoy procesan la gran mayoría de las transacciones críticas. «Heredado» no es un insulto: significa que el sistema es lo suficientemente valioso como para haber sobrevivido, lo bastante crítico como para que su caída sea catastrófica, y lo bastante antiguo como para que modificarlo con seguridad resulte difícil. La modernización de sistemas heredados es la disciplina de mejorar, migrar o sustituir esos sistemas sin romper los servicios esenciales que prestan.

Se trata de un problema desproporcionadamente vinculado a la empresa y a la administración pública, y es precisamente donde ocurren los fracasos de TI más graves y públicos. Una enorme proporción de las transacciones más importantes del mundo sigue tocando sistemas mainframe. Una parte muy significativa del código en producción de las grandes instituciones está escrita en lenguajes antiguos, mantenida por un colectivo de especialistas que envejece y se reduce. Los gobiernos soportan la carga más pesada: obligaciones estatutarias codificadas a lo largo de décadas, ciclos de contratación y presupuesto que trascienden a los gobiernos que los inician, y servicios al ciudadano que no pueden interrumpirse. El riesgo dominante no es que esos sistemas sean viejos, porque muchos funcionan a la perfección. El riesgo es que el conocimiento para mantenerlos se retira con cada jubilación, que las plataformas se vuelven cada vez más caras y limitadas, y que la tentación de «simply reescribirlo todo» conduce a algunos de los fracasos más costosos en la historia de esta disciplina.

Este capítulo abarca los patrones de modernización incremental que de verdad funcionan (la figuera estranguladora y la rama por abstracción), cómo evaluar y priorizar el riesgo de un sistema heredado, la custodia de los parques de mainframe y COBOL, la disciplina de la migración de datos y la ejecución en paralelo, y, sobre todo, cómo resistir la tentación de la reescritura total. La convicción central es que la modernización exitosa es, casi siempre, incremental, guiada por la evidencia y capaz de generar valor de forma continua. Nunca es un salto a gran escala que lo cambie todo de una vez.

Principios clave

Heredado significa valioso y fundamental, no simplemente antiguo. Respeta lo que el sistema hace antes de tocarlo: codifica décadas de reglas de negocio forjadas con gran esfuerzo.
Lo incremental supera a lo radical, casi siempre. Sustituye pieza por pieza detrás de una interfaz estable; genera valor de forma continua y mantiene el riesgo reducido.
La reescritura total es el modo de fracaso por defecto. Las reescrituras completas se retrasan con asiduidad, entregan menos de lo previsto y terminan canceladas; trata esa urgencia con profunda sospecha.
No se puede modernizar lo que no se comprende. Reverse-engineer y documenta el comportamiento (incluidas las reglas no documentadas) antes de reemplazarlo.
La migración de datos es donde mueren los proyectos. Los datos son más antiguos, más sucios y más enredados de lo que cualquiera espera; planifícalos como un esfuerzo de primera categoría.
Ejecuta el sistema antiguo y el nuevo en paralelo para construir confianza. La ejecución en paralelo y la comparación de resultados detectan divergencias antes del corte definitivo.
Prioriza por riesgo y valor, no por antigüedad. Moderniza lo que sea más arriesgado y más valioso primero, no lo que simplemente sea el más viejo.
Mantén la luz encendida mientras cambias el motor. El servicio debe seguir funcionando durante todo el proceso; no existe una interrupción aceptable para sistemas financieros ni para servicios al ciudadano.

Recomendaciones

Moderniza de forma incremental con el patrón de la figuera estranguladora

La figuera estranguladora (así llamada por la trepadora que crece alrededor de un árbol y va sustituyéndolo gradualmente) es la herramienta fundamental de la modernización segura. Coloca una capa de enrutamiento (una pasarela de API, una fachada o un proxy) frente al sistema heredado. A continuación, capacidad por capacidad, construye el reemplazo en un sistema moderno y desvía esa porción de tráfico hacia él, dejando el resto en el sistema heredado. Con el tiempo, el sistema nuevo crece y el antiguo se encoge, hasta que puede retirarse. Este enfoque genera valor de forma continua, mantiene cada cambio pequeño y reversible, evita un corte arriesgado y permite detenerse o repriorizar en cualquier momento. Es lo opuesto al salto a gran escala: el sistema heredado sigue funcionando y sigue justificado mientras se lo sustituye en su entorno.

Utiliza la rama por abstracción para costuras internas

Cuando necesites reemplazar un componente del que dependen muchas partes del sistema, aplica la rama por abstracción: introduce una capa de abstracción (una interfaz) sobre la implementación existente, migra a los llamantes para que dependan de esa abstracción, construye la nueva implementación tras la misma interfaz, realiza el conmutado (a menudo tras un interruptor de funcionalidad, de forma gradual) y, por último, elimina la implementación antigua. Así se sustituye un componente de gran alcance de manera incremental en la rama principal de desarrollo, sin una rama de larga duración, manteniendo el sistema siempre publicable. Se combina de forma natural con la figuera estranguladora: la fachada maneja las costuras externas y la rama por abstracción, las internas.

Evalúa y prioriza el riesgo del sistema heredado con deliberación

Antes de modernizar, elabora un inventario claro y una evaluación de riesgo del parque de sistemas. Para cada sistema, puntuarlo en criticidad de negocio, riesgo técnico (obsolescencia, plataformas sin soporte, exposición de seguridad), frecuencia de cambio y, sobre todo, riesgo de conocimiento (cuántas personas pueden aún mantenerlo y cuántos pasos de su retiro se encuentran). Ubica los sistemas en una cuadrícula de riesgo versus valor. Prioriza la modernización de lo que sea a la vez de alto riesgo y alto valor. Considera dejar intactos los sistemas estables, de bajo cambio y bien comprendidos aunque sean antiguos, porque un sistema que funciona y del que nadie necesita cambiar nada no es una emergencia. Esta evaluación convierte «todo es viejo y da miedo» en una hoja de ruta defendible y secuencia.

Custodia el parque de mainframe y COBOL; no lo sustituyas por inercia

No todo sistema mainframe o COBOL debe, ni puede con seguridad, sustituirse a corto plazo. La prioridad a corto plazo suele ser la custodia: capturar el conocimiento antes de que se jubile. Documenta las reglas de negocio que el código encierra (mucho de ello no está documentado y es irreemplazable), invierte en pruebas automatizadas que fijen el comportamiento actual para que cualquier cambio futuro sea seguro, recluta y forma cruzadamente a los mantenedores, y moderniza las prácticas de entrega circundantes (control de versiones, integración continua (CI), pruebas automatizadas) aunque el núcleo permanezca. Donde sí se modernice, se prefiera exponer las capacidades del sistema heredado a través de APIs modernas (encapsulamiento) como primer paso. Trata la traducción automática de COBOL a un lenguaje moderno con cautela, porque produce código que funciona, pero que con frecuencia reproduce fielmente una lógica incomprensible. El recurso más escaso es la comprensión, no el cómputo.

Trata la migración de datos y la ejecución en paralelo como el núcleo del proyecto

La parte más difícil y arriesgada de la mayoría de los esfuerzos de modernización son los datos: voluminosos, de calidad deficiente e inconsistente, y repletos de significado no documentado acumulado a lo largo de décadas. Profílalos y limpíalos, mapea los esquemas antiguos a los nuevos de forma explícita, y construye una migración automatizada y repetible con conciliación completa (conteos, sumas de verificación, totales de negocio) para demostrar que nada se ha perdido ni alterado. Desactiva el riesgo del corte definitivo con la ejecución en paralelo: opera el sistema antiguo y el nuevo lado a lado con los mismos inputs y compara sus outputs hasta que el nuevo coincida con el antiguo según tu umbral de confianza. Solo entonces conmuta, y conserva la capacidad de revertir. Para los sistemas verdaderamente críticos, migra y conmuta en porciones, no de una sola vez.

Domina la tentación de la reescritura total

El instinto de desechar el sistema antiguo, caótico, y construir uno nuevo desde cero es poderoso, y para sistemas grandes y críticos casi siempre es el camino equivocado. Las reescrituras completas subestiman el valor oculto en el código «feo» (casos límite, reglas regulatorias, comportamientos compatibles con bugs de los que dependen usuarios reales), toman mucho más tiempo del proyectado, no entregan valor hasta el final y, con frecuencia, se cancelan tras un enorme gasto. Como norma, moderniza de forma incremental. Reserva las reescrituras para los casos en que la plataforma sea genuinamente insostenible y los caminos incrementales se hayan agotado. Incluso entonces, descompón la reescritura en piezas independientemente entregables mediante el patrón de la figuera, no en un lanzamiento único y monolítico. Cuando la dirección presione por una reescritura total, exige la siguiente pregunta: ¿qué valor se entrega en los primeros tres meses y qué ocurre si el programa se detiene a mitad de camino?

Contrapartidas: ventajas y desventajas

Enfoque	Ventajas	Desventajas
Figuera estranguladora (incremental)	Valor continuo, riesgo bajo, reversible, mantiene el servicio activo	Plazo global más largo, exige ejecutar dos sistemas en paralelo, sobrecarga de integración
Reescritura a gran escala	Hoja en blanco, sin restricciones del sistema heredado en el nuevo código	Tasa de fracaso muy elevada, no hay valor hasta el final, costo enorme, pérdida de reglas de negocio
Encapsular (envolver con APIs)	Rápido, de bajo riesgo, moderniza el acceso sin tocar el núcleo	El núcleo sigue siendo heredado; aplaza, no resuelve, el riesgo de fondo
Dejar como está (custodia)	Sin riesgo de proyecto; el costo a corto plazo es el menor	El riesgo de conocimiento y de plataforma sigue acumulándose; acción forzada futura

La contrapartida fundamental es la velocidad de transformación frente al riesgo de fracaso, y la modernización de sistemas heredados es el dominio donde esa balanza se inclina de forma más marcada. La reescritura a gran escala, rápida y limpia, es un espejismo que produce repetidamente el resultado más lento y más costoso de todos: un programa cancelado y un sistema que sigue sin modernizar. Los enfoques incrementales se sienten más lentos y exigen ejecutar dos sistemas en paralelo, pero entregan valor a lo largo de todo el proceso, mantienen el riesgo reducido y reversible, y son el camino empíricamente fiable. La verdadera decisión de juicio es entre custodiar un sistema heredado estable un tiempo más y comenzar ahora la sustitución incremental. Que sea la trayectoria del riesgo quien decida, en particular el riesgo de conocimiento, y no la incomodidad con una tecnología antigua.

Preguntas para debatir con tu equipo

¿Dispones de un punto donde colocar una capa de enrutamiento frente a tu sistema heredado, y si no, qué se necesitaría para crearlo? La figuera estranguladora depende de una costura: una pasarela de API, una fachada o un proxy por donde puedas desviar una capacidad a la vez hacia una nueva implementación. Muchos sistemas antiguos carecen de esa costura, y el primer incremento de modernización suele ser simplemente la construcción del punto de interceptación, un trabajo fácil de subestimar. Trae el mapa de integraciones actual y pregunta dónde podría interceptarse el tráfico por capacidad, sin un corte a gran escala. Si no hay ningún punto, la rama por abstracción sobre una costura interna puede ser el movimiento inicial. Sin una capa de enrutamiento no hay camino incremental, que es exactamente como las organizaciones acaban empujadas hacia la reescritura que, de ordinario, fracasa.
¿Has trazado de verdad tu parque de sistemas en una cuadrícula de riesgo versus valor, o tu hoja de ruta la dicta qué sistema se siente más antiguo? El capítulo exige modernizar primero lo de alto riesgo y alto valor y dejar deliberadamente de lado los sistemas estables, de bajo cambio y bien comprendidos, aunque sean de gran antigüedad. Sin una cuadrícula explícita, la atención fluye hacia la queja más sonora o la tecnología menos de moda, y las verdaderas bombas de relojería (un sistema crítico con dos mantenedores cerca de jubilarse) quedan esperando. Puntúa cada sistema en criticidad de negocio, riesgo técnico, frecuencia de cambio y riesgo de conocimiento, y secuencia desde la esquina superior derecha. Lleva esa cuadrícula a la reunión como el mapa compartido. El riesgo de conocimiento merece el mayor peso, porque es el único dato que solo empeora y no puede recuperarse una vez que las personas se van.
Cuando se realice el corte definitivo, ¿cómo demostrarás que ni un solo registro se ha perdido ni alterado, y quién avalará esa evidencia? La migración de datos es donde mueren estos proyectos, y la confianza nace de la conciliación: conteos de filas, sumas de verificación y totales de negocio que cuadren entre el sistema antiguo y el nuevo, junto con la ejecución en paralelo que compara outputs ante los mismos inputs hasta que coincidan con un umbral muy alto. En un sistema de prestaciones o un libro mayor, una divergencia es un ciudadano que recibe menos de lo que le corresponde o un céntimo perdido, y la evidencia ha de satisfacer a un auditor, no solo a un ingeniero. Decide ahora qué totales se conciliarán, qué umbral de confianza dispara el corte y cuánto tiempo se ejecutarán ambos sistemas en paralelo. Mantén la capacidad de revertir en todo momento y conmuta en porciones, no de una vez. Las divergencias que se descubran durante la ejecución en paralelo suelen ser reglas heredadas no documentadas que hay que preservar, así que trátalas como un hallazgo, no como un simple defecto.
¿Qué sistemas heredados estás custodiando y cuáles estás reemplazando activamente, y quién decidió cada caso? El capítulo traza una línea deliberada entre los sistemas que vale la pena estabilizar en su sitio (documentar reglas, añadir pruebas de caracterización, formación cruzada de mantenedores) y los que merece la pena reemplazar de forma incremental, y ambos demandan financiación y personal muy distintos. En una gran organización, el peligro es la deriva: un sistema etiquetado «custodia por ahora» se convierte calladamente en «custodia para siempre» hasta que el último mantenedor se jubila y la decisión se toma por ti, en medio de una crisis. Las consideraciones en tensión son, por un lado, el costo de custodia y la obsolescencia de la plataforma, y por el otro, el riesgo y la disrupción del reemplazo, y el riesgo de conocimiento debería inclinar la balanza, porque solo empeora. Lleva la cuadrícula de riesgo versus valor, el número de mantenedores y el horizonte de jubilación de cada sistema, y un responsable explícito para la decisión de custodiar o reemplazar. En parques empresariales y públicos, establece un ritmo de revisión y un oficial responsable por cada sistema, porque una clasificación que nadie revisa es una decisión que nadie está tomando.
Cuando la dirección pide una reescritura completa, ¿cuál es tu respuesta preparada y puedes mostrar qué valor entrega un camino incremental en los primeros tres meses? La reescritura a gran escala es el modo de fracaso por defecto, y sin embargo sigue recibiendo financiación porque una hoja en blanco es fácil de vender y una figuera estranguladora no lo es. Un equipo grande necesita una respuesta ensayada para que el debate se gane con evidencia y no con quién ocupa el puesto más alto en la sala. La tensión genuina es que algunas plataformas son de verdad insostenibles y una reescritura está justificada, así que la respuesta no puede ser una negativa absoluta: debe ponderar si todavía existen costuras incrementales frente al costo real de mantener la plataforma antigua en marcha. Lleva el valor que un primer incremento incremental entregaría, la tasa histórica de fracaso de reescrituras comparables y una descomposición de cualquier reescritura propuesta en piezas que puedan entregarse de forma independiente. En el sector público, donde un programa plurianual cancelado quema dinero de todos ante la mirada de todos, exige que cualquier reescritura entregue valor temprano y que, si se detiene a mitad de camino, no suponga una pérdida total.
¿Cómo capturarás las reglas de negocio encerradas en tu código más antiguo antes de que se vayan las personas que las comprenden? Gran parte del valor de un sistema heredado reside en comportamientos no documentados que décadas de casos límite, regulaciones y correcciones compatibles con errores han ido acumulando, y ese valor vive en un colectivo en reducción de especialistas que se jubila, no en ningún documento escrito. En una gran organización, ese es el único riesgo que no puede recuperarse una vez que las personas se van, y merece financiación por delante del trabajo de plataforma más visible. La contracción opuesta es que la captura de conocimiento (documentación, pruebas de caracterización, ingeniería inversa, formación cruzada) se percibe como un sobrecoste que no entrega nada, que es exactamente la razón por la que se difiere. Lleva un inventario de quién detenta el conocimiento crítico, cuánto falta para que se vayan y qué cobertura de pruebas fija el comportamiento actual hoy. En entornos regulados y públicos, trata las reglas estatutarias codificadas en código antiguo como un activo de cumplimiento: perderlas en silencio no es una deuda técnica, es una exposición legal.

Perspectiva sectorial

Start-up. Tu sistema heredado no es un mainframe, sino tu propio MVP apresurado: un prototipo que ahora soporta ingresos y que todos temen tocar. No lo reescribas. Envuelve el módulo más delicado detrás de una interfaz limpia, añade pruebas de caracterización que fijen su comportamiento actual y extrae funcionalidad de él por trozos a lo largo de unos meses. Cada pequeño lanzamiento entrega valor y encoge la parte que da miedo, así que la start-up obtiene un sistema mantenible sin arriesgar la compañía a una reconstrucción desde cero que no puede permitirse.

Pequeña empresa. No tienes equipo de modernización y el presupuesto es ajustado, así que la jugada práctica suele ser mantener funcionando lo que ya funciona: captura lo que la única persona que lo entiende sabe, mételo en control de versiones con unas pocas pruebas automatizadas y confía en un proveedor o en un producto empaquetado antes que en un desarrollo a medida. Enmarca la decisión como compra o desarrollo propio, y prefiere comprar cuando la capacidad es una mercancía. Dedicar tu esfuerzo limitado al único sistema cuya caída paralizaría el negocio, no al que simplemente parezca más antiguo.

Gran empresa. El problema es la escala del parque: decenas de sistemas, muchos equipos y un riesgo de conocimiento a nivel de organización. Realiza una evaluación compartida de riesgo versus valor, estandariza los patrones incrementales (figuera estranguladora y rama por abstracción) y trata la migración de datos y la ejecución en paralelo como disciplinas de primera categoría, con conciliaciones que todos confían. Goberna la modernización como un portafolio continuo contra la trayectoria del riesgo, no como una dispersión de proyectos heroicos, y presupuesta la custodia y la captura de conocimiento de forma explícita, para que ningún sistema crítico dependa de un único mantenedor que se jubila.

Sector público. Las obligaciones estatutarias codificadas a lo largo de décadas, las normas de contratación pública y los servicios al ciudadano que no pueden interrumpirse ni calcularse con error hacen especialmente peligroso el reemplazo a gran escala. Se prefiera la migración incremental con la figuera estranguladora, el corte por porciones y la demostración, mediante conciliación y ejecución en paralelo prolongada, de que ni un solo registro ciudadano se ha perdido ni calculado de forma incorrecta, manteniendo la capacidad de revertir en todo momento. La contratación pública debe exigir portabilidad de datos y divulgación de reglas de negocio, no traducciones opacas, y cualquier programa plurianual debe entregar valor auditable desde temprano y sobrevivir al escrutinio público si se detiene a mitad de camino.

Ejemplos

Start-up. El MVP original de una start-up de tres años ha convertido en su propio sistema heredado: un prototipo apresurado que ahora maneja ingresos reales y que todos temen tocar. En lugar de reescribirlo, el equipo envuelve el módulo más delicado detrás de una interfaz limpia, añade pruebas de caracterización que fijen su comportamiento actual y extrae funcionalidad de él por piezas a lo largo de unos meses. Cada pequeño lanzamiento entrega valor y reduce la parte que da miedo, de modo que la start-up obtiene un sistema mantenible sin arriesgar la empresa a una reconstrucción desde cero que no puede permitirse.

Gran empresa. Un gran asegurador gestiona la administración de pólizas en un sistema mainframe COBOL fiable pero costoso de modificar y mantenido por un puñado de ingenieros cercanos a su jubilación. En lugar de reescribir, el asegurador envuelve el mainframe con APIs modernas y aplica la figuera estranguladora: las capacidades de presupuesto y compra y los servicios de autogestión se construyen en una plataforma moderna y se enrutan a través de una fachada, mientras que los registros de póliza de núcleo permanecen en el mainframe. En paralelo, el equipo documenta las reglas de negocio y añade pruebas de caracterización alrededor del COBOL. A lo largo de varios años, capacidad tras capacidad se desplaza del mainframe, cada lanzamiento entregando valor, hasta que el núcleo que queda puede retirarse bajo los términos del asegurador, no bajo una crisis.

Sector público. Una agencia de seguridad social debe modernizar un sistema de cálculo de prestaciones de décadas de antigüedad que abona a millones de ciudadanos y no puede interrumpirse ni pagar de forma incorrecta. Rechaza un reemplazo a gran escala tras estudiar programas comparables fracasados. En su lugar, profila y limpia los datos, construye una migración automatizada con conciliación completa contra totales de control y ejecuta el nuevo motor de prestaciones en paralelo con el antiguo durante muchos meses, alimentando ambos con las mismas solicitudes y comparando cada cálculo, investigando cada divergencia (a menudo descubriendo reglas heredadas no documentadas que hay que preservar). Solo cuando el nuevo sistema coincide con el antiguo con una confianza muy alta, conmuta tipo de prestación a tipo de prestación, conservando la reversibilidad en todo momento. La fachada de la figuera permite que los ciudadanos perciban un servicio continuo a lo largo de toda la transición.

Caso de negocio: motivaciones, retorno de inversión y costo total de propiedad

La modernización de sistemas heredados tiene un caso de negocio inusual, porque el mayor costo suele ser el de la inacción y el mayor riesgo, el propio proyecto de modernización. Los crecientes costos de no modernizar son concretos: mantenimiento y licencias en ascenso sobre plataformas obsoletas, una mano de obra especializada cada vez más escasa y cara, la incapacidad de responder con rapidez a nuevas demandas regulatorias o de servicio, y una exposición creciente a un fallo catastrófico sin nadie que comprenda el sistema. Frente a ello, el costo de la modernización es alto y, si se aborda a gran escala, arrastra una probabilidad genuinamente elevada de fracaso. Es precisamente por eso que el enfoque incremental importa para el retorno de inversión: convierte una única apuesta grande en una serie de apuestas pequeñas, cada una de las cuales retorna valor y puede detenerse.

Presenta el caso a la dirección reencuadrando la elección. La pregunta no es «modernizar o no». Es «modernizar de forma incremental ahora o asumir costos de custodia crecientes y enfrentar más adelante una modernización forzada, de mayor riesgo, en medio de una crisis». Cuantifica el costo total de propiedad del status quo (costos de plataforma y licencia, el sobreprecio por la escasez de competencias, el costo ponderado por riesgo de un fallo sin recuperación) y compáralo con un programa por fases que reduce riesgo y costo con cada incremento y mantiene el servicio en marcha. De forma crítica, exige que cualquier reescritura propuesta se estructure para entregar valor de forma temprana y frecuente. Un programa que no entrega nada durante tres años y puede cancelarse con pérdida total no es una inversión: es una apuesta. El argumento de retorno de inversión más sólido a favor del enfoque de la figuera es la opcionalidad: el valor se entrega de forma continua y la organización puede corregir el rumbo en cualquier momento.

Antipatrón y trampas

La reescritura a gran escala. Reemplazo plurianual, todo o nada, que no entrega valor hasta el final y que con frecuencia se cancela a gran costo.
Reescribir sin comprender. Sustituir código cuyas reglas de negocio nunca se documentaron, perdiendo en silencio los casos límite de los que dependen usuarios reales y leyes.
Subestimar los datos. Tratar la migración de datos como un añadido cuando es la parte más difícil y arriesgada del proyecto.
Omitir la ejecución en paralelo. Conmutar al sistema nuevo sin comparación paralela y descubrir las divergencias solo cuando ya afectan a personas reales.
La traducción automática como solución. Traducir COBOL a un lenguaje moderno por máquina y creer que el trabajo está hecho, produciendo código incomprensible que reproduce la lógica antigua al pie de la letra.
Modernizar por antigüedad, no por riesgo. Dedicar esfuerzos a sistemas viejos pero estables mientras sistemas de alto riesgo y alto cambio esperan.
Perder el conocimiento. Dejar que los últimos mantenedores se jubilen sin capturar las reglas de negocio ni añadir pruebas de caracterización.
Sin reversibilidad. Conmutar sin posibilidad de volver atrás cuando el sistema nuevo se comporta mal bajo carga y datos reales.

Modelo de madurez

Nivel 1: Iniciar. Los sistemas heredados se temen y se congelan; el cambio se evita. No existe inventario ni evaluación de riesgo. La modernización, cuando se intenta, es una reescritura ad hoc, todo o nada, impulsada por la frustración. El conocimiento vive en la cabeza de unos pocos que se jubilan, y no hay nada escrito.
Nivel 2: Desarrollar. Algunos equipos disponen de un inventario y de una aproximación del riesgo, y unos pocos sistemas heredados se han envolvido con APIs para el acceso. Los patrones incrementales se conocen pero se aplican de forma desigual, y el pensamiento aún tiende hacia la reescritura a gran escala. La migración de datos se intenta, pero se subestima, y la práctica varía enormemente de un equipo a otro.
Nivel 3: Estandarizar. Los sistemas se priorizan por riesgo y valor según un método documentado a nivel de organización. Los patrones incrementales (figuera estranguladora, rama por abstracción) son el enfoque por defecto, y toda modernización sigue un protocolo estándar. La migración de datos es un esfuerzo planificado y conciliado, con ejecución en paralelo antes del corte, y la captura de conocimiento y las pruebas de caracterización son práctica obligatoria, no opcional.
Nivel 4: Gestionar. La modernización se mide y controla con datos. El parque lleva líneas base: número de mantenedores y horizonte de jubilación por sistema, cobertura de pruebas de caracterización, tasas de conciliación de la migración, conteos de divergencias en la ejecución en paralelo y valor entregado por incremento, todo ello trazado contra objetivos. Las decisiones de custodiar o reemplazar y los veredictos de corte se toman sobre esa evidencia, y un sistema que supera su umbral de riesgo de conocimiento dispara una acción, en lugar de esperar a una crisis.
Nivel 5: Orquestar. La modernización es continua, integrada con la planificación de negocio y de riesgo, y adaptable. El portafolio se reequilibra contra la trayectoria del riesgo (sobre todo el de conocimiento) a medida que esta se desplaza, la sustitución incremental es rutinaria y de bajo impacto, cada incremento entrega valor y es reversible, y la organización dirige el ritmo de forma deliberada. Las lecciones de cada migración se retroalimentan en el protocolo compartido, de modo que el parque completo mejora con el tiempo.

Ideas para debatir

Para tu sistema heredado más crítico, ¿cuántas personas pueden aún mantenerlo y cuánto falta para que se vayan?
¿Dónde sientes la tentación de la reescritura a gran escala, y qué valor podría entregar un enfoque incremental en los primeros tres meses?
¿Qué tan bien documentadas están las reglas de negocio de tus sistemas más antiguos, y qué ocurre con ellas si el código se reemplaza?
¿Has perfilado los datos que necesitarías migrar y sabes cuán sucios y enredados son de verdad?
¿Qué sistemas viejos pero estables están recibiendo energía de modernización que podrías dejar en paz con seguridad?
¿Podrías ejecutar tu sistema nuevo en paralelo con el antiguo y demostrar que coinciden antes del corte?

Ideas clave

Heredado significa valioso y fundamental; respeta y comprende un sistema antes de cambiarlo.
Moderniza de forma incremental con la figuera estranguladora y la rama por abstracción, generando valor de forma continua y manteniendo cada cambio pequeño y reversible.
Trata la reescritura a gran escala como el modo de fracaso por defecto; resérvala para plataformas genuinamente insostenibles y, aun así, descomponla.
Prioriza por riesgo y valor (sobre todo el riesgo de conocimiento), no por antigüedad; algunos sistemas antiguos es mejor custodiarlos que reemplazarlos.
La migración de datos y la ejecución en paralelo son el corazón del esfuerzo: perfilar, conciliar, ejecutar en paralelo y conservar la reversibilidad.
El caso de negocio más sólido es la opcionalidad: la modernización incremental convierte una única apuesta grande y arriesgada en muchas pequeñas, cada una retornando valor.

Referencias y lectura adicional

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, «StranglerFigApplication» y «BranchByAbstraction»
Sam Newman, Monolith to Microservices
Nicholas Carr / estudios de la industria sobre la dependencia del mainframe y el COBOL (contexto sobre la escala de los parques heredados)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (capa anticorrupción)
Gregor Hohpe, Enterprise Integration Patterns y The Software Architect Elevator
Standish Group, CHAOS Report (evidencia sobre las tasas de fracaso de grandes proyectos y reescrituras)