Para modernizar una aplicación legacy sin parar el negocio, la vía más segura es sustituirla por partes. Pones una capa delante que decide qué peticiones atiende el sistema antiguo y cuáles el nuevo, migras módulo a módulo y activas cada cambio para un porcentaje pequeño de usuarios antes de extenderlo. El sistema viejo sigue funcionando hasta que ya no tiene nada que hacer.
La alternativa tentadora es reescribirlo todo y cambiar de un día para otro. Parece más limpio, pero durante meses el equipo trabaja en una versión que nadie usa, el negocio sigue pidiendo cambios en la antigua y el día del salto concentra todo el riesgo. Mientras tanto, la aplicación actual acumula dependencias sin soporte y, si factura, tiene un plazo legal que no espera.
Al terminar sabrás cómo decidir entre reescribir o modernizar por partes, qué pasos seguir y qué fechas de tu stack deberían marcar el calendario.
Qué significa modernizar una aplicación legacy
Modernizar una aplicación legacy es sustituir o actualizar el software antiguo que sostiene un proceso de negocio sin perder lo que hace bien: sus reglas, sus datos y los casos raros que se han ido resolviendo durante años. El objetivo es recuperar la capacidad de cambiarla con seguridad, no estrenar tecnología.
Una aplicación se vuelve legacy cuando cada cambio da miedo. Suele coincidir con un framework sin soporte, pocas pruebas automáticas y una sola persona que la entiende. Es uno de los proyectos de rediseño y modernización de software a medida que más nos llegan, casi siempre con la misma condición: la empresa no puede dejar de facturar ni de servir pedidos mientras dura.
Reescribir desde cero o modernizar por partes
En el año 2000, Joel Spolsky llamó a la reescritura completa desde cero el peor error estratégico que puede cometer una empresa de software, a partir del caso de Netscape: al tirar el código se tiran también años de correcciones que nadie documentó. Martin Fowler, que describió el patrón strangler fig, cuenta que su equipo ha visto fracasar la mayoría de esas reescrituras porque sustituir un sistema serio lleva mucho tiempo y los usuarios no pueden esperar a las funciones nuevas.
Eso no convierte la reescritura en tabú. Cuándo sí puede tener sentido:
- La aplicación es pequeña y sus reglas se pueden describir en pocas páginas.
- El proceso de negocio va a cambiar tanto que la lógica antigua ya no sirve.
- La tecnología no permite convivir con otra, por ejemplo un programa de escritorio sin forma de interceptar sus operaciones.
Cuándo no: si el sistema es crítico, lleva años acumulando reglas y el negocio no puede congelar cambios durante meses. Ahí compensa modernizar por partes. Si dudas entre desarrollar o pasar a una herramienta comercial, la comparativa entre software propio y herramientas SaaS ayuda a plantearlo.
El patrón strangler fig paso a paso
El nombre viene de una higuera que crece alrededor de un árbol hasta sustituirlo. En software, el sistema nuevo rodea al antiguo y lo va reemplazando sin un día de corte único.
1. Congela el comportamiento actual con pruebas
Antes de tocar nada, escribe pruebas de caracterización: registran lo que la aplicación hace hoy con entradas reales, aunque parezca raro. Así sabrás si el sistema nuevo se comporta igual, incluidos los redondeos y las excepciones que nadie recuerda por qué existen.
2. Pon una fachada delante
Un proxy o una pasarela recibe todas las peticiones y decide a qué sistema enviarlas. Al principio todo va al antiguo. Es el punto que te permite migrar sin que los usuarios cambien de dirección ni de forma de trabajar.
3. Extrae primero el módulo que más duele
Elige por impacto y riesgo: el módulo que más incidencias genera, el que bloquea una obligación legal o el que más cambios pide el negocio. Construye su versión nueva con una arquitectura que aísle las reglas de negocio de la tecnología; en separar las reglas de negocio de la tecnología con arquitectura hexagonal explicamos cómo hacerlo.
4. Activa el cambio de forma gradual
Envía al sistema nuevo un porcentaje pequeño de usuarios, mide errores y tiempos, y amplía. Si algo falla, vuelves atrás en segundos cambiando la configuración, sin desplegar.
CodeZone Pro Tip: enruta por ruta y por porcentaje de usuarios para migrar sin día de corte
import { createHash } from "node:crypto";
// Rutas ya migradas y % de usuarios que pasan al sistema nuevo (canary)
const migradas: { prefijo: string; porcentaje: number }[] = [
{ prefijo: "/facturas", porcentaje: 100 }, // migrada y estable
{ prefijo: "/pedidos", porcentaje: 10 }, // en prueba con el 10 %
];
const LEGACY = "http://app-antigua.interna";
const NUEVO = "http://app-nueva.interna";
// El mismo usuario cae siempre en el mismo grupo: no salta entre versiones
function bucket(usuarioId: string): number {
return parseInt(createHash("sha256").update(usuarioId).digest("hex").slice(0, 8), 16) % 100;
}
export function destino(ruta: string, usuarioId: string): string {
const regla = migradas.find((r) => ruta === r.prefijo || ruta.startsWith(r.prefijo + "/"));
if (!regla) return LEGACY; // todo lo no migrado sigue en la aplicación antigua
return bucket(usuarioId) < regla.porcentaje ? NUEVO : LEGACY;
}
// Marcha atrás en segundos: poner porcentaje a 0 devuelve a todos al sistema antiguoEsta función vive en la fachada y decide, petición a petición, qué sistema responde. El reparto por hash mantiene a cada usuario siempre en la misma versión, así que nadie ve pantallas distintas al recargar. Para el negocio significa que cada módulo nuevo se prueba con usuarios reales y un riesgo acotado, y que un fallo afecta a una fracción pequeña durante minutos, no a toda la empresa durante días.
5. Mantén los datos coherentes mientras conviven
Durante la convivencia, los dos sistemas trabajan con los mismos clientes, pedidos o facturas. Hay que decidir cuál es el dueño de cada dato en cada fase y cómo se sincroniza con el otro, normalmente con eventos o con procesos periódicos que copian los cambios. Una regla que evita muchos problemas: un dato solo se escribe en un sistema a la vez. Si los dos pueden modificarlo, antes o después aparecen dos versiones distintas del mismo pedido y nadie sabe cuál es la buena.
6. Retira el sistema antiguo
Cuando un módulo lleva semanas al 100 % sin incidencias, se retira su parte en la aplicación antigua. El último paso es apagarla, con sus datos migrados y verificados.
Las fechas que deberían marcar tu calendario
Algunas piezas de una aplicación antigua tienen fecha de caducidad oficial: a partir de ella dejan de recibir parches de seguridad.
- .NET 8 y .NET 9: la política de soporte de .NET fija su fin el 10 de noviembre de 2026. .NET 10 tiene soporte hasta noviembre de 2028.
- PHP: según las versiones con soporte publicadas por php.net, PHP 8.1 dejó de recibir parches el 31 de diciembre de 2025 y PHP 8.2 solo recibe correcciones de seguridad hasta el 31 de diciembre de 2026. Sobre el lenguaje en sí, en el estado real del desarrollo con PHP en 2026 tienes nuestra visión.
- VeriFactu: si la aplicación emite facturas, la nota de la Agencia Tributaria sobre la ampliación del plazo, actualizada el 26 de marzo de 2026, recoge que tras el Real Decreto-ley 15/2025 los contribuyentes del Impuesto sobre Sociedades deben estar adaptados antes del 1 de enero de 2027, y el resto antes del 1 de julio de 2027.
Si tu facturación vive en un sistema antiguo que no puede cumplir, ese es tu primer módulo a extraer. En la guía sobre cómo desarrollar un ERP a medida explicamos qué exige VeriFactu a un sistema de facturación.
Cuánto tarda y cómo se presupuesta
Modernizar por partes permite presupuestar por módulos y parar entre uno y otro para medir. El primer módulo suele ser el más caro, porque incluye la fachada, las pruebas de caracterización y el despliegue gradual. Los siguientes aprovechan esa base. Para calibrar plazos con honestidad, en los tiempos reales de un desarrollo a medida desglosamos cada fase.
Dos situaciones cambian el plan. Si la aplicación antigua es en realidad un conjunto de hojas de cálculo con macros, empieza por llevar esos procesos de Excel a una aplicación web. Si es una app móvil antigua, el enfoque tiene particularidades propias que tratamos en la migración de apps legacy a una arquitectura móvil moderna.
La modernización también es el momento de ordenar lo que rodea al sistema. Muchas aplicaciones antiguas sobreviven gracias a un panel interno improvisado; revisa qué debe incluir un panel de administración para crecer antes de replicarlo tal cual. Y si la aplicación atiende a clientes externos, puede ser la ocasión de darles un portal propio conectado con tu ERP.
El Coste de Seguir Aplazando la Modernización
Cada mes que una aplicación crítica sigue sin pruebas, sin soporte y en manos de una sola persona, el riesgo crece y las opciones se reducen. Cuando llega una fecha como el fin de soporte de un framework o el plazo de VeriFactu, lo que podía hacerse por partes y con calma se convierte en una migración urgente.
En Codezone modernizamos aplicaciones existentes sin detener la operativa, y seguimos a tu lado después con mantenimiento y soporte continuo. Si tienes una aplicación que nadie se atreve a tocar, cuéntanos qué hace y en qué tecnología está y te proponemos por dónde empezar.
