Tu WebForms sigue vivo, y no pasa nada
Cada pocos años alguien decreta que hay que reescribir la aplicación entera porque WebForms está muerto o porque .NET Framework es antiguo. Casi siempre esa reescritura ni empieza, o empieza y se abandona a mitad. Mientras tanto, la aplicación de siempre sigue facturando.
El mito de la reescritura total
Reescribir desde cero un sistema que lleva años en producción es el proyecto más caro y arriesgado que puede acometer una empresa: tarda el doble de lo previsto, reintroduce bugs ya resueltos y, durante meses, no aporta ninguna funcionalidad nueva. La mayoría de esas migraciones de golpe fracasan.
La vía pragmática: mantener y modernizar por partes
- Estabilizar primero: asegurar que lo que hay funciona, tiene copias de seguridad y no depende de una sola persona.
- Modernizar donde duele: aislar los módulos con más problemas y llevarlos a .NET moderno de forma incremental, con la aplicación funcionando en todo momento.
- Integrar en vez de reemplazar: muchas veces lo que hace falta no es tirar el legacy, sino conectarlo con algo nuevo (una API, un panel, una integración).
Cuándo sí conviene migrar de verdad
Migrar tiene sentido cuando el framework deja de recibir parches de seguridad, cuando el coste de mantenerlo supera al de modernizarlo, o cuando bloquea una capacidad de negocio concreta. Pero esa decisión se toma con datos, no por moda. Y casi siempre se ejecuta por fases, no de golpe.
Mantener bien un .NET Framework o un WebForms en 2026 no es rendirse: es la opción sensata mientras la modernización se hace cuando toca y como toca.