Modernización de sistemas legacy sin reescribirlo todo

En algún lugar de tu empresa hay un sistema que nadie quiere tocar. Tiene entre 10 y 20 años, está escrito en .NET, Java o PHP, mueve pedidos, facturación o el back office, y las personas que mejor lo conocían ya se fueron. Tarde o temprano alguien va a proponer reescribirlo desde cero.

No lo hagas. Reemplázalo por partes y planea la base de datos antes que todo lo demás. (Si tu código es reciente y lo escribió sobre todo la IA, el artículo para ti es cuándo refactorizar o reconstruir.)

¿Por qué fracasan las reescrituras totales de sistemas legacy?

Porque el comportamiento del sistema viejo es la única especificación completa, y nadie la ha leído entera. Martin Fowler lo dice sin rodeos en su ensayo de 2024 sobre el patrón strangler fig: un reemplazo parece fácil de especificar, pero muchas veces cuesta descifrar los detalles del comportamiento existente. Sobre el plan de reconstruir todo de una vez, que suena tan sencillo, escribe que la mayoría de las veces lo han visto terminar en desastre.

El daño viene por dos lados. Uno es el tiempo: el negocio no puede congelarse mientras se reemplaza el sistema, y la guía prescriptiva de AWS (documentación de un proveedor) advierte que durante una migración big bang es extremadamente difícil, o incluso imposible, agregar funcionalidades nuevas. El otro es la paridad. En su serie Patterns of Legacy Displacement (2021), Ian Cartwright, Rob Horn y James Lewis, directores técnicos de Thoughtworks, describen reescrituras que prometen hacer exactamente lo mismo que el sistema anterior: los parches para errores y limitaciones del pasado terminan convertidos en requisitos obligatorios. Un equipo puede entregar el 80% de los pasos individuales de un proceso y aun así no poder completar el proceso de negocio de punta a punta.

Son ensayos basados en experiencia práctica, no estudios. Nuestra lectura: una reescritura acierta en las reglas que todos recuerdan y falla en las que nadie dejó por escrito, como el redondeo especial de un cliente o el proceso de cierre de mes que corrige en silencio los datos del día anterior.

¿Qué es el patrón strangler fig?

El patrón strangler fig reemplaza un sistema legacy pieza por pieza mientras sigue funcionando. Una fachada, por lo general un proxy o un API gateway, se ubica delante del sistema viejo y envía cada request al código legacy o a su reemplazo nuevo. A medida que mueves piezas, más tráfico va al sistema nuevo, hasta que el viejo ya no atiende nada y lo apagas. Fowler le puso el nombre por las higueras estranguladoras de la selva, que crecen alrededor de un árbol huésped y terminan reemplazándolo.

La guía del patrón en el Azure Architecture Center de Microsoft, documentación de un proveedor actualizada en 2026, agrega tres condiciones. La fachada no puede convertirse en un punto único de falla ni en un cuello de botella. Donde el código viejo y el nuevo todavía se llaman entre sí, una capa anticorrupción (anti-corruption layer) traduce entre ambos para que las convenciones legacy no se filtren al diseño nuevo. Y el patrón quizá no sirva si no puedes interceptar los requests o modificar el código fuente legacy.

La mayoría de las guías se queda en la fachada. Esa es la parte fácil.

¿Por qué la base de datos es lo más difícil de modernizar un sistema legacy?

Porque en un sistema de 15 años, la base de datos es la capa de integración. Las reglas de negocio viven en stored procedures, los reportes consultan las tablas directamente y alguien en finanzas tiene una hoja de cálculo conectada a producción. Puedes mover el código de facturación a un servicio nuevo y la facturación seguirá en el mismo lugar: todo lo demás sigue leyendo y escribiendo en las tablas de facturas.

La guía de Microsoft coincide: los sistemas legacy suelen depender de una base de datos monolítica centralizada que atiende varios dominios. Su ejemplo de base de datos mueve un dominio a la vez. Aquí va, con lo que nosotros le sumamos.

¿Cómo mover los datos de un dominio sin detener el negocio?

1. Primero, haz un inventario de quién lee y quién escribe. Antes de enrutar nada, lista todo lo que toca las tablas del dominio: código, stored procedures, triggers, reportes, extracciones de BI, integraciones, hojas de cálculo. Los logs de consultas y la auditoría de la base de datos encuentran lo que una búsqueda en el código no ve. Esa lista es tu checklist para el corte.
2. Enruta primero, mueve los datos después. El servicio nuevo atiende los requests del dominio, pero sigue leyendo y escribiendo en las tablas legacy. Si algo se rompe, devuelves el tráfico al sistema viejo.
3. Copia y luego sincroniza. Carga el histórico en una base de datos nueva para el dominio con un ETL que corres una sola vez y mantenla al día con change data capture (CDC), que lee los cambios desde el log de transacciones de la base legacy. La base legacy sigue siendo la fuente de verdad.
4. Concilia, por escrito. Microsoft indica validar la consistencia antes del corte; conviértelo en un reporte diario: conteo de filas, totales por cuenta y por día, y una comparación campo por campo de una muestra. Acuerda con finanzas qué significa "cuadrar", y no hagas el corte hasta que el reporte se mantenga limpio durante al menos un cierre de mes.
5. Haz el corte con camino de regreso. La nueva base del dominio pasa a ser el sistema de registro, y los lectores legacy que todavía no migraste se alimentan con una sincronización en sentido contrario. AWS advierte que este tipo de sincronización deja ambas bases con consistencia eventual y recomienda tratarla como una solución táctica, así que ponle fecha de fin.
6. Define el punto de no retorno. Borrar las tablas y los stored procedures legacy es difícil de revertir: volver atrás implica restaurar esos objetos y volver a aplicar los cambios de datos, lo que según Microsoft aumenta de forma significativa el esfuerzo y el riesgo. Su recomendación: tratar la eliminación de los objetos legacy como un paso final deliberado para cada dominio. Ponle fecha, define quién firma y confirma en el inventario del paso 1 que ya nadie lee esas tablas.

Luego repite, dominio por dominio. Ese ciclo es el proyecto.

¿Qué dominio conviene mover primero?

Uno con fronteras claras, pocos procesos que escriban en sus tablas y una funcionalidad que el negocio está esperando: prueba el método y justifica la siguiente ronda. No empieces por la contabilidad general ni por la tabla de catálogo que no te enseña nada. AWS advierte que descomponer antes de tiempo puede salir caro cuando el dominio no está claro, porque puedes trazar mal las fronteras. Si no puedes dibujar esa frontera en una pizarra, no muevas ese dominio todavía.

¿Cambia el plan con el fin de soporte de .NET 8?

Si tu sistema corre en .NET 8 o 9, cambia el orden. La política de soporte de .NET de Microsoft, consultada en octubre de 2026, marca el 10 de noviembre de 2026 como fin de soporte tanto para .NET 8 (LTS) como para .NET 9 (STS), y .NET 10 (LTS) tiene soporte hasta el 14 de noviembre de 2028. A partir del 10 de noviembre, Microsoft dejará de publicar correcciones y actualizaciones para ambas. Esa fecha no afecta a .NET Framework 4.8.1, que sigue con soporte mientras corra en una versión de Windows que también lo tenga.

El Data Breach Investigations Report 2026 de Verizon, investigación de un proveedor, revisó más de 22,000 brechas confirmadas en todo el mundo entre noviembre de 2024 y octubre de 2025. El 31% empezó por una vulnerabilidad de software, por delante de las contraseñas robadas. La cifra abarca todo tipo de software, no solo .NET, pero el software que no puedes parchear es una puerta abierta.

Nuestra lectura: actualizar el runtime es mantenimiento, no modernización, y no debería esperar a que empiece una. Pasa primero a una versión con soporte y después reemplaza el sistema por partes, a tu ritmo. Una reescritura que arranca presionada por una fecha de fin de soporte es otra vez el big bang, con menos tiempo.

¿Quién se encarga de cada parte de una migración strangler fig?

Es un solo proyecto multipráctica, con cuatro prácticas involucradas. Build construye la fachada, los servicios nuevos y los adaptadores entre ambos sistemas. Data lleva la parte más difícil: el CDC, los reportes de conciliación que prueban que ambos sistemas coinciden y los reportes de finanzas y operaciones, que tienen que seguir funcionando mientras las tablas se mueven, idealmente desde un data warehouse y no desde producción, con una sola definición para cada número. Secure tiene algo en juego porque un runtime sin soporte se queda sin parches. Advisory arma el caso de negocio y define en qué orden se mueven los dominios.

Si repartes esas partes entre varios proveedores, el reporte de conciliación es lo primero que se queda sin dueño.

Relacionados: La factura del código generado por IA → · El modern data stack → · Arquitectura multi-tenant →