Cuatro números deciden cuándo reescribir software heredado

Reescribir un sistema heredado está justificado cuando el coste y el riesgo de modificarlo superan el coste y el riesgo de sustituirlo. La antigüedad, el lenguaje y las preferencias arquitectónicas no responden a esa pregunta. Sí lo hacen cuatro mediciones: la tasa de fallos de cambios, la proporción del equipo que puede tocar el código con seguridad, la parte del entorno de ejecución que carece de soporte y el coste de un solo incidente grave.

He visto a equipos aprobar reescrituras porque un framework parecía viejo y descubrir después que la aplicación anterior cambiaba dos veces al año y no causaba problemas. También he visto defender la «mejora incremental» mientras una única persona mantenía un sistema de producción sobre un entorno sin soporte. Ambas decisiones nacían de una intuición disfrazada de ingeniería. Ponga los cuatro números en una página y será mucho más difícil amañar el debate.

Las decisiones de reescritura necesitan mediciones, no un límite de edad

No existe una antigüedad a partir de la cual el software se convierta automáticamente en candidato a una reescritura. Un servicio de quince años con interfaces estables, dependencias compatibles, buenas pruebas y varios mantenedores seguros puede costar menos que conservar que uno de tres años que falla en cada entrega. La edad indica dónde revisar, pero no decide.

Lo mismo ocurre con el lenguaje. COBOL, RPG, VB6, Delphi o una versión antigua de PHP pueden crear problemas de contratación y soporte, pero el nombre de un lenguaje no cuantifica ninguno. Un proceso COBOL bien entendido que trata cada noche un archivo fijo puede merecer otra década. Un pequeño servicio JavaScript que solo entiende un contratista puede ser ya un riesgo operativo.

Empiece con un periodo que incluya la entrega normal y al menos una fase exigente del negocio. Un trimestre suele servir para equipos que despliegan con frecuencia. Un sistema que cambia despacio puede necesitar más tiempo, pero no espere eternamente unos datos perfectos. Anote la incertidumbre junto a cada cifra y mejore la medición sobre la marcha.

Use la misma unidad de análisis para las cuatro medidas. Decida si está juzgando una aplicación, un servicio desplegable o un grupo muy acoplado que debe moverse junto. Medir fallos en toda una cartera y mantenedores en un solo repositorio produce una ficha pulida pero inútil.

Los cuatro números responden a preguntas distintas:

• ¿Puede el equipo cambiar el sistema sin romper la producción?
• ¿Cuántas personas pueden realizar ese cambio sin supervisión?
• ¿Cuánto software en ejecución ha dejado de recibir correcciones de sus responsables?
• ¿Qué pierde el negocio cuando el sistema causa un incidente grave?

Ninguno tiene un umbral universal. Fije un límite acorde con su tolerancia al riesgo y escriba qué acción seguirá al cruzarlo. La ventaja está en usar la misma regla antes de una caída, cuando nadie puede doblarla para apoyar la conclusión que ya desea.

La tasa de fallos revela el impuesto de cada entrega

La tasa de fallos de cambios indica qué proporción de los cambios en producción exige una reparación porque causó degradación, una interrupción, una reversión o una corrección urgente. DORA emplea esta idea como medida del rendimiento de entrega de software. Yo mantendría una definición estrecha: cuente fallos causados por un cambio, no todos los incidentes ocurridos cerca de un despliegue.

Defina qué cuenta como cambio en producción antes de calcular. Incluya despliegues de aplicaciones, migraciones de base de datos, versiones de configuración, cambios del planificador e infraestructura si el equipo los controla como un único proceso. No cuente un reintento rutinario como otro cambio fallido ni convierta diez commits de emergencia tras una mala entrega en diez fallos independientes.

El cálculo básico es sencillo:

change_failure_rate = failed_production_changes / total_production_changes

La clasificación es la parte difícil. Para cada cambio fallido, anote el cambio desencadenante, el efecto en clientes, la acción de recuperación y si el defecto procedía de código, datos, configuración o una interacción desconocida. Una etiqueta como change-failure basta si todos la aplican igual. Revise cada mes los casos discutidos con ingeniería y operaciones en la misma sala.

No compare tasas brutas de sistemas con patrones de entrega radicalmente diferentes. Una aplicación puede publicar cien cambios pequeños y otra una única versión agrupada. Acompañe la tasa del volumen y del tiempo medio de recuperación. Un 10 % sobre diez indicadores reversibles no supone el mismo riesgo que un 10 % sobre versiones trimestrales de base de datos que tardan seis horas en restaurarse.

La tendencia importa más que una lectura aislada. Si la tasa baja después de mejorar pruebas, observación y tamaño de las entregas, los parches están devolviendo el control. Si sigue alta después de dos o tres intentos centrados, quizá la arquitectura esté derrotando al método de entrega. Busque causas repetidas: estado mutable compartido, orden de procesos por lotes sin documentar, contratos ocultos de base de datos y pasos de despliegue imposibles de ensayar. Esos patrones encarecen cada función futura.

No premie a un equipo por evitar los cambios. Un sistema sin despliegues tiene una tasa indefinida o engañosamente perfecta. Registre la demanda que se pospuso porque publicar era demasiado arriesgado. Cuando los cambios del negocio se acumulan por miedo a tocar producción, la ausencia de fallos demuestra parálisis, no salud.

La propiedad segura es menor que el acceso al repositorio

La proporción de acceso seguro es la parte del equipo relevante que puede realizar, revisar, desplegar y recuperar de forma independiente un cambio significativo. El acceso al repositorio no cuenta. Tampoco saber editar un archivo mientras el único experto dicta cada paso.

Defina un cambio significativo usando el trabajo que realmente recibe el sistema. Puede ser añadir un campo a través de base de datos, servicio e interfaz; cambiar un cálculo con consecuencias financieras; o modificar un proceso nocturno sin romper su reinicio. La tarea debe cruzar los límites donde suele desaparecer el conocimiento.

Evalúe a cada ingeniero según cuatro capacidades:

• Explicar la ruta de ejecución afectada y sus dependencias.
• Implementar y probar el cambio sin copiar un precedente que no entiende.
• Publicarlo mediante el proceso real de producción.
• Diagnosticar un fallo y restaurar el servicio sin esperar al oráculo del sistema.

Cuente a una persona solo cuando existan pruebas recientes de las cuatro. Trabajar en pareja ayuda a enseñar, pero no prueba independencia. Las revisiones, la participación en incidentes y un cambio de producción exitoso aportan mejores pruebas que una autoevaluación.

Calcule entonces:

safe_touch_share = independent_safe_maintainers / relevant_engineers

Registre también la cifra absoluta. Un 50 % parece saludable hasta que significa una persona de dos. Por el contrario, cuatro mantenedores capaces en un equipo de veinte pueden cubrir bien una aplicación interna estable, siempre que guardias y vacaciones no eliminen a los cuatro a la vez.

Esta medida expone una distinción que los equipos suelen confundir: disponer de documentación no equivale a tener conocimiento operativo. Un manual de mil páginas puede explicar pantallas y tablas, pero omitir por qué la liquidación precede a la conciliación, qué registros dañados reparan los operadores a mano o cómo reanudar un proceso sin duplicar asientos. Pruebe el documento pidiendo a una persona nueva que lo use bajo supervisión. Sus preguntas forman parte de la especificación que falta.

Una proporción decreciente suele ser la primera señal de reescritura porque esconde una fecha límite. Una jubilación, dimisión o salida del proveedor puede convertir de un día para otro un sistema difícil en uno imposible de cambiar. Si la transferencia aumenta la proporción y las personas formadas siguen haciendo cambios seis meses después, los parches conservan un argumento. Si cada intento devuelve el trabajo al mismo experto, deje de llamar formación a la situación.

La parte sin soporte mide exposición, no vergüenza

La parte del entorno sin soporte es la proporción de la pila de producción que ya no recibe correcciones de seguridad o funcionamiento del proveedor o proyecto responsable. Incluye más que el lenguaje. Cuente sistemas operativos, bases de datos, servidores de aplicaciones, entornos, frameworks principales, controladores y middleware esencial.

Inventaríe lo que se ejecuta, no lo que afirma el diagrama. Extraiga versiones de servidores, imágenes de contenedor, bloqueos de paquetes, definiciones de trabajos y consultas de base. En un mainframe o sistema intermedio incluya compiladores, monitores de transacciones, planificadores y componentes del proveedor en la ruta. Registre la fuente de cada fecha de soporte para que los rumores de compras no se conviertan en política.

Un cálculo ponderado útil es:

unsupported_runtime_share = sum(weight_of_unsupported_components) / sum(weight_of_all_components)

Asigne pesos según exposición y función. Un servidor público sin soporte merece más peso que un conversor aislado usado una vez al mes. Mantenga el sistema tan simple que otro ingeniero pueda reproducirlo. Si un comité necesita una hora para explicar por qué un componente pesa 7,3, la precisión es ficticia.

Sin soporte no significa vulnerado, y con soporte no significa seguro. Significa que el responsable ha dejado de proporcionar una vía normal de corrección. El equipo puede compensarlo con aislamiento, parcheo virtual, controles estrictos de entrada o un contrato ampliado de pago. Escriba cada control junto al componente y compruebe si cubre todas las entradas.

Busque el núcleo abandonado escondido bajo bordes actuales. Un navegador, proxy inverso y base recientes no rescatan una lógica que exige un entorno abandonado. A veces se actualiza todo alrededor del núcleo y se declara un número bajo de componentes obsoletos. Ponderar por importancia de ejecución evita ese truco contable.

Seguir parcheando es razonable cuando los componentes sin soporte están aislados, son estables, se pueden sustituir por separado y están cubiertos por controles de bajo coste. Cuesta defenderlo cuando uno acepta entradas no fiables, bloquea actualizaciones del sistema o obliga a conservar toda una cadena obsoleta. Entonces la exposición se acumula: cada actualización vecina debe adaptarse a la pieza más vieja.

El coste de un incidente convierte el riesgo técnico en límite comercial

El coste de un incidente grave es toda la pérdida del negocio desde la detección hasta la recuperación y corrección, no solo la factura de nube o las horas extra. Use un incidente real si es posible. Si no ha ocurrido, construya un escenario con finanzas, operaciones, seguridad y el responsable de negocio, y marque cada supuesto.

Calcule categorías que alguien pueda verificar:

incident_cost = lost_margin
              + staff_hours * loaded_hourly_cost
              + customer_remediation
              + contractual_or_regulatory_cost
              + data_reconciliation
              + delayed_business_events

Use margen perdido en lugar del valor bruto, salvo que las operaciones desaparezcan para siempre. Separe ingresos retrasados de perdidos. Cuente trabajo manual de operaciones, finanzas, soporte, ingeniería y dirección. Incluya los días tras restaurar el servicio dedicados a conciliar registros, corregir duplicados, responder a clientes y preparar avisos obligatorios.

No multiplique una cifra horaria aterradora por la caída más larga imaginable. Defina el incidente grave con precisión: cuatro horas sin capturar pedidos seguidas de un día de conciliación, por ejemplo, o una ejecución de precios incorrecta que llega a clientes. Documente volumen, margen, costes laborales, términos contractuales y supuestos de recuperación. Finanzas debe poder cuestionar el modelo línea por línea.

Use dos costes si hay modos de fallo distintos. Un incidente de disponibilidad y otro silencioso de integridad rara vez tienen la misma forma. El segundo puede parecer barato durante la caída porque nadie lo detecta y resultar mucho más caro al reconstruir. Los promedios ocultan esa diferencia.

El coste cambia el argumento porque fija cuánto merece la pena gastar para reducir la exposición. Un sistema frágil que soporta un flujo interno menor puede seguir parcheado racionalmente. Otro igual de frágil que registra asientos o controla movimientos de fábrica merece menos tolerancia en las otras tres medidas.

No convierta el coste en un truco de pérdida esperada sin datos fiables de frecuencia. Multiplicar una probabilidad anual adivinada por una consecuencia modelada produce una cifra monetaria limpia con dos entradas débiles. Mantenga visibles las pruebas de frecuencia, consecuencia e incertidumbre. La dirección puede decidir sin fingir ciencia actuarial.

Coloque los cuatro números en una ficha de decisión

Una ficha debe mostrar valores actuales, tendencia, confianza, un límite acordado y la acción vinculada a cruzarlo. Basta una página. Su función es obligar a explicitar los intercambios, no calcular una respuesta que la dirección deba obedecer.

Use una tabla como esta y sustituya los límites de ejemplo:

Los valores son ilustrativos, no referencias universales. Una interfaz de facturación hospitalaria, una impresora de etiquetas y un catálogo público necesitan límites distintos. Los propietarios deben elegirlos antes del próximo incidente y conservar las pruebas de cada valor.

No reduzca las cuatro medidas a una puntuación ponderada demasiado pronto. Un 62 oculta si hay fallos frecuentes y baratos o una dependencia catastrófica sin soporte. Mantenga visibles los cuatro ejes. Si la dirección pide un estado, use tres:

• Seguir parcheando mientras las medidas permanezcan dentro de límites y mejoren.
• Contener y preparar cuando una cruce su límite o varias empeoren.
• Reescribir cuando la exposición supere el límite acordado y la reparación creíble haya fallado.

Fije una fecha y nombre a quien actualiza cada dato. Los fallos pueden salir de registros de despliegue e incidentes. Las pruebas de propiedad corresponden al responsable de ingeniería. El soporte necesita revisión de plataforma o seguridad. Finanzas y negocio deben aprobar la consecuencia.

La ficha también evita que crezca el alcance. Si solo el planificador crea la exposición, sustitúyalo en vez de declarar podrido todo el sistema. Si la única debilidad es la propiedad, quizá basten rotación y documentación. Una reescritura merece aprobación cuando las medidas señalan un límite que no puede repararse económicamente donde está.

Los parches ganan cuando el riesgo está limitado y es reversible

Parchear sigue siendo correcto cuando los cambios rara vez fallan, varias personas pueden asumirlos, los componentes abandonados tienen una contención creíble y un incidente estaría dentro de la tolerancia. Una reescritura consume atención que podría mejorar productos visibles. No sustituya software estable para satisfacer un diagrama.

Hay varios casos sólidos. El sistema puede acercarse a una retirada prevista porque cierra una línea de negocio. Su comportamiento puede estar fijado por regulación o contrato, con pocos cambios esperados. Un proveedor puede ofrecer actualizaciones compatibles que eliminen el entorno expuesto sin tocar la lógica. O la aplicación puede estar detrás de una interfaz estrecha y controlada, sin entradas no fiables y con recuperación probada.

El parcheo debe tener alcance y condición de salida. Financie actualizaciones, pruebas de caracterización, automatización del despliegue, observación y transferencia de conocimiento. Vuelva a medir. Si baja la tasa y sube la propiedad segura, funciona. Si el equipo reconstruye en cada ciclo el mismo despliegue frágil o protege un entorno que bloquea todo lo demás, el programa se ha convertido en un retraso caro.

Me opongo a la regla popular de dividir primero todo monolito viejo en microservicios. Parece incremental y por eso suena más segura que una reescritura. En la práctica, extraer servicios de código cuyo comportamiento nadie puede especificar distribuye la incertidumbre por una red. Añade fallos parciales, interfaces versionadas y trabajo operativo antes de probar la paridad. Capture primero el comportamiento en el límite del sistema y elija después límites acordes con capacidades y propiedad de datos.

Otra opción válida es la sustitución selectiva. Conserve cálculos o procesos estables y cambie la interfaz sin soporte. Coloque una dependencia de base detrás de un servicio compatible. Retire informes que nadie usa antes de traducirlos. Recalcule las cuatro medidas para el límite restante tras cada retirada, porque un núcleo menor puede ser barato de contener indefinidamente.

No confunda parchear con no hacer nada. Conservar el sistema acepta trabajo concreto: contratos, pruebas de controles, simulacros de recuperación, cobertura de personal y revisión programada. Si nadie financia esos puntos, la organización no eligió parchear. Eligió un deterioro sin gestionar.

Una reescritura debe conservar el comportamiento antes de cambiar la arquitectura

Una reescritura defendible captura el comportamiento observable, ejecuta las dos versiones contra los mismos casos y cambia la arquitectura solo cuando las pruebas lo permiten. Traducir línea por línea conserva estructura accidental y puede reproducir defectos sin el contexto operativo que los hacía tolerables.

Empiece con pruebas de forma similar a producción. Registre peticiones y respuestas cuando la política lo permita, capture entradas y salidas por lotes, conserve errores representativos e identifique efectos como archivos, mensajes, escrituras y solicitudes al operador. Elimine valores sensibles, pero mantenga distribuciones, orden y casos malformados que recorren las ramas reales.

Construya un arnés de paridad que envíe un caso a ambos sistemas y compare resultados normalizados. Normalice de forma explícita marcas temporales, identificadores generados, órdenes sin significado y otros campos no deterministas. Nunca oculte una diferencia con un filtro amplio. Cada regla debe explicar por qué la diferencia no importa.

Para comportamiento con estado, compare transiciones, no pantallas finales. Prepare ambos con el mismo estado de base, ejecute la acción y compare filas cambiadas, mensajes, archivos y devoluciones. Para un proceso por lotes, pruebe final limpio, reinicio tras interrupción, entrada duplicada, entrada tardía y fallo parcial posterior. Los operadores suelen depender de esos casos más de lo que creen los desarrolladores.

Entonces la arquitectura puede cambiar con seguridad. Un sistema COBOL y JCL puede convertirse en servicios Go con Postgres, un núcleo numérico puede justificar Rust y un cliente de escritorio puede pasar a TypeScript. Son decisiones de diseño, no objetivos por sí mismas. El objetivo es comportamiento de negocio equivalente con un modelo que el equipo actual pueda mantener.

CodeHero lee todo el árbol de código y comprueba el sistema modernizado con un arnés de paridad frente a tráfico de producción grabado, en vez de traducir archivos aislados. Sus proyectos se entregan en menos de 30 días, también en entornos regulados donde los modelos suministrados pueden ejecutarse aislados dentro del perímetro del cliente.

Trate los fallos de paridad como descubrimientos de especificación. Algunos revelan defectos nuevos. Otros exponen comportamiento anterior contradictorio, lógica dependiente del entorno o datos que rompen supuestas reglas. El responsable del negocio debe decidir qué peculiaridades son contratos y cuáles son errores. Ingeniería no puede deducir la respuesta solo del código.

La aprobación exige una alternativa calculada, no entusiasmo

Una propuesta debe competir contra un plan completo de parcheo y otro de contención, ambos con costes. Si la alternativa es «seguir sufriendo», la comparación está amañada. Calcule actualizaciones, pruebas, cobertura especializada, contratos, controles, exposición a incidentes y retraso de funciones que el parcheo necesita de verdad.

Calcule la reescritura más allá de la implementación. Incluya descubrimiento, captura de comportamiento, conversión de datos, operación paralela, aceptación, cambio, preparación de reversión, formación y retirada. Asigne propietarios a decisiones y validación. Un sustituto técnicamente terminado puede fallar si finanzas no concilia saldos iniciales u operaciones no recupera un lote a medias.

Exija pruebas para el calendario. Inventaríe integraciones, almacenes de datos, trabajos, informes, roles, intercambios de archivos y procedimientos. Marque cada uno como observado, inferido o desconocido. Lo desconocido no bloquea automáticamente, pero alguien debe decidir cómo probarlo antes del cambio.

La puerta de aprobación debe responder cinco preguntas claras:

1. ¿Qué medida cruzó el límite acordado y qué lo demuestra?
2. ¿Qué reparación intentó el equipo y cómo respondió la medida?
3. ¿Qué límite se sustituirá, conservará o retirará?
4. ¿Cómo se probará la paridad y se ensayará la reversión?
5. ¿Qué responsable acepta las diferencias y el riesgo restantes?

Si las respuestas son vagas, financie una fase corta de pruebas, no una reescritura. Debe producir el inventario, la evaluación de propiedad, el modelo de incidente, el corpus de comportamiento y el límite del sistema. No debe producir diapositivas sobre modernidad.

La aprobación también necesita condiciones de parada. Si quedan brechas de paridad en un flujo de grandes consecuencias, la conversión no concilia o el sustituto incumple una exigencia de recuperación, el cambio espera. El coste hundido no vuelve seguro un sistema sin verificar.

Revise la decisión después de cada cambio material

La decisión caduca cuando cambian sistema, equipo o consecuencia. Recalcule después de una gran actualización, transferencia de propiedad, adquisición, variación de tráfico, nueva obligación o incidente grave. Una ficha abandonada un año se convierte en otro documento heredado.

Mantenga las pruebas cerca del trabajo habitual. Los registros de despliegue deben identificar cambios remediados. Las revisiones deben separar fallos causados por cambios y conservar costes reales de trabajo y conciliación. Las habilidades se prueban con entregas. El inventario debe actualizarse desde entornos en ejecución, no desde un cuestionario anual.

Observe dirección y umbrales. Cuatro medidas dentro de sus límites pero empeorando juntas justifican preparación. Una fuera del límite pero mejorando rápido puede justificar otro ciclo. Escriba la excepción, su propietario y vencimiento para que una tolerancia temporal no se convierta en política permanente.

Los casos difíciles tienen señales opuestas. Un sistema puede ser estable y barato durante incidentes mientras la propiedad se derrumba. Puede tener muchos mantenedores y depender de un entorno público sin soporte. No haga desaparecer el eje incómodo mediante un promedio. Decida si un control creíble puede moverlo antes de la fecha oculta.

La primera reunión útil no es un taller de reescritura. Es una revisión donde ingeniería, operaciones, seguridad, finanzas y negocio aportan pruebas para un número cada uno. Fije límites y financie la acción vinculada. Si los números apoyan el parcheo, parchee sin disculpas. Si muestran que cada cambio seguro depende de conocimiento menguante, software abandonado y un coste inaceptable, deje de pagar por la ilusión de que otro parche devolverá el control.