Todo sistema legado que sigue en producción es, ante todo, un sistema que funciona. Procesa pagos, emite documentos y sostiene los ingresos de la empresa. El problema es que cambiarlo se volvió caro: cada modificación tarda meses, pocas personas conocen el código y la integración con los canales digitales termina siendo un parche. La tentación es reescribirlo todo desde cero. En la experiencia con grandes bancos, medios de pago y sector público, el gran reemplazo de una sola vez suele ser el camino más riesgoso. Lo que funciona es modernizar por partes, con la operación en marcha.
Strangler fig: sustituir de a poco
El patrón strangler fig propone construir el sistema nuevo alrededor del antiguo, asumiendo una funcionalidad a la vez. Cada parte migrada pasa a ser atendida por el nuevo, y el legado se reduce hasta que puede apagarse. El riesgo queda repartido en entregas pequeñas y cada etapa ya genera valor.
APIs delante del legado
El primer paso suele ser una capa de APIs entre los canales y el sistema antiguo. Los consumidores pasan a hablar con un contrato estable, sin saber qué hay detrás. Así es posible cambiar la implementación de una ruta sin tocar aplicaciones, socios ni integraciones. Esa capa también es el lugar indicado para la observabilidad, la seguridad y el control del tráfico.
Migrar por dominios, no por capas
Migrar toda la base de datos o toda la interfaz de una vez crea dependencias enormes. Es mejor dividir por dominio de negocio: registro de clientes, cobranza, límites, atención. Cada dominio llega a producción con un responsable, métricas y un equipo a cargo de punta a punta.
Datos: la parte más difícil
El código se reescribe; los datos deben preservarse. Durante la transición, el legado y el sistema nuevo conviven, y hay que definir cuál es la fuente de verdad de cada información. La sincronización por eventos, la conciliación diaria y reglas claras de escritura evitan diferencias que solo aparecen en el cierre del mes.
Modernizar no es cambiar de tecnología. Es reducir el costo de cambiar sin aumentar el riesgo de operar.
¿Reescribir o encapsular?
- Encapsular: cuando la regla de negocio es estable, el sistema es confiable y el problema está en la integración o en la experiencia del usuario.
- Reescribir: cuando la regla cambia con frecuencia, el mantenimiento frena la evolución o la tecnología ya no tiene soporte ni profesionales disponibles.
- Primero, pruebas de regresión: antes de tocar nada, capture el comportamiento actual con pruebas automatizadas y compare los resultados del legado y del nuevo. Sin eso, no hay forma de demostrar que nada se rompió.
- Camino de vuelta: cada migración necesita un cambio gradual del tráfico y una reversión probada.
Con este método, la modernización deja de ser una apuesta de alto riesgo y se convierte en una secuencia de entregas previsibles. El negocio sigue funcionando y el legado sale de escena al ritmo que la operación soporta.
¿Quieres hablar de esto?
Cuéntanos tu desafío. La conversación es directa y sin compromiso.