Modernizar sistemas críticos sin reescribir todo desde cero

Cuando una plataforma heredada empieza a frenar el negocio, la conversación en el equipo suele girar pronto hacia la misma idea: "habría que rehacer esto desde cero."

Es una reacción comprensible. Los sistemas viejos acumulan deuda técnica, dependencias no documentadas, código que solo entienden dos personas y flujos que nadie se atreve a tocar. En ese contexto, la reescritura total parece un reinicio necesario — una forma de empezar limpio, sin cargar con el peso acumulado.

El problema es que, cuando ese sistema sostiene operación crítica, rehacer todo es uno de los movimientos más arriesgados que puede hacer una organización.

Por qué el "rehacer todo" suele salir mal

No es que sea imposible. Es que casi siempre se subestima lo que se va a perder en el proceso.

Un sistema legado que lleva años en producción tiene algo que no aparece en los repositorios: reglas de negocio implícitas, lógica acumulada por excepciones reales, flujos que evolucionaron respondiendo a clientes y errores concretos. Reescribir desde cero no solo es costoso en tiempo y recursos — es también el momento en que esa lógica se pierde, se malinterpreta o se reconstruye incompleta.

A eso se suma el riesgo operativo: durante meses, o años, la organización debe sostener dos mundos en paralelo — el sistema viejo que sigue en producción y el nuevo que todavía no está listo para producción. Ese período de doble vida es frágil, caro y difícil de gestionar.

En Eximus hemos llegado a este escenario en varias organizaciones. En la mayoría de los casos, el camino inteligente no empieza con una reescritura. Empieza con orden.

Un camino más controlado: modernización por capas

La alternativa no es quedarse con el sistema actual para siempre. Es trabajar en el orden correcto:

1. Recuperar visibilidad técnica

Antes de cualquier decisión de modernización, hay que entender qué hay realmente en el sistema. Cuántas KBs activas, qué versiones, qué generadores, qué integraciones externas, qué piezas de custom code sin dueño claro. Sin ese mapa, cualquier transformación arranca sin información.

2. Estabilizar la operación

Mientras se planifica la transformación, el sistema en producción no puede seguir degradándose. Estabilizar significa identificar y resolver los puntos de mayor riesgo inmediato: flujos críticos sin monitoreo, backups que nadie ha probado en semanas, cambios que se despliegan con miedo porque no hay rollback definido.

3. Ordenar los cambios y despliegues

Muchos sistemas legados tienen un problema de proceso antes que un problema técnico: no existe un flujo claro para gestionar cambios. Los despliegues son manuales, irregulares, dependientes de una o dos personas. Antes de modernizar el stack, vale la pena modernizar el proceso — pipelines básicos, entornos separados, criterios mínimos de validación antes de ir a producción.

4. Mejorar la trazabilidad

Un sistema que nadie puede observar es un sistema que nadie puede mejorar con confianza. Agregar logging, alertas y visibilidad sobre transacciones críticas transforma la ecuación: permite detectar problemas antes de que lleguen a los usuarios, y le da al equipo evidencia técnica para argumentar cada cambio.

5. Modernizar por capas

Con visibilidad, estabilidad, proceso y trazabilidad establecidos, la modernización se puede hacer por partes — actualizando versiones de GeneXus en fases controladas, migrando módulos específicos a plataformas soportadas, moviendo cargas puntuales a Azure sin comprometer continuidad.

Cada capa agrega capacidad sin arriesgar la operación completa.

Lo que hemos visto en proyectos reales

En la migración de ITSARC — una plataforma de administración de riesgo de crédito en GeneXus — el trabajo no empezó por la reescritura del sistema. Empezó por entender qué versión corría, qué dependencias externas existían y qué partes tenían mayor exposición al riesgo de mantenimiento. Solo con ese mapa fue posible diseñar un plan de migración a GeneXus 16 que protegiera producción durante el proceso.

En el caso de SARCADAPTER — una aplicación de escritorio que alimentaba procesos ETL en SQL Server — el reto era similar: el sistema cumplía una función crítica pero no había documentación clara, ni monitoreo, ni propiedad técnica bien definida. El trabajo fue entender el sistema antes de tocarlo, y migrar hacia SQL Server Integration Services de forma controlada, sin romper los ciclos de reportes que dependían de esos flujos.

El patrón se repite: en ambos casos, la respuesta correcta no fue empezar de cero. Fue recuperar control primero.

Cuándo sí tiene sentido reescribir

Hay casos en que la reescritura total es el camino correcto:

• cuando el sistema ya no puede evolucionar por ninguna ruta razonable,
• cuando el costo de sostenerlo supera el costo de reconstruirlo,
• o cuando la deuda técnica es tan estructural que ninguna capa nueva puede construirse sobre ella.

Pero esa evaluación requiere información. Y la información viene de haber completado antes los pasos de visibilidad y diagnóstico.

La decisión de reescribir todo no debería tomarse desde el agotamiento. Debería tomarse desde el criterio.

El siguiente paso

Si tu sistema actual sostiene operación importante y sientes que empieza a pesar más de lo que aporta, el primer paso no es elegir entre "seguir igual" y "rehacer todo". Es entender qué hay exactamente, qué riesgo existe hoy y qué ruta de modernización tiene más sentido para tu operación concreta.

Agenda una llamada o revisa cómo trabajamos la Modernización GeneXus.