La respuesta corta
Para modernizar un sistema legado sin detener la operación, cámbielo por partes: evalúe el código y los datos, elija la estrategia adecuada para cada módulo y reemplace una pieza a la vez, con el sistema antiguo funcionando en paralelo hasta que la parte nueva esté validada. Reescribir todo de una vez es el camino más riesgoso.
No todo sistema antiguo tiene que salir. Legado es el sistema del que depende la operación y que se volvió difícil de cambiar, no necesariamente el más viejo. A veces basta con integrarlo al resto y cuidar la seguridad; a veces lo correcto es reemplazarlo por una herramienta del mercado. La decisión sale de una evaluación técnica, no de la edad del código.
Señales de que el sistema legado se volvió un riesgo
Un sistema antiguo que funciona no es un problema en sí mismo. Se vuelve un riesgo cuando la operación depende de él más de lo que aguanta. Las señales más comunes:
- Solo una persona sabe modificarlo. El conocimiento está en la cabeza de quien lo construyó o de quien lo mantiene hace años, sin documentación. Si esa persona se va, la operación queda rehén.
- Cada cambio pequeño demora y rompe otra cosa. Sin pruebas automatizadas, nadie se siente seguro para modificarlo, y el equipo empieza a evitar tocarlo.
- La tecnología quedó sin soporte. Un lenguaje, una base de datos o un sistema operativo sin actualizaciones de seguridad dejan abiertas fallas conocidas.
- No se comunica con los demás sistemas. Sin API, los datos viajan por planilla, exportación manual o volviendo a digitarlos.
- No cumple las exigencias actuales. El control de acceso por perfil, el registro de quién hizo qué y las reglas de la ley brasileña de protección de datos (LGPD) sobre datos personales quedaron fuera del diseño original.
- El equipo creó un sistema paralelo a su alrededor. Planillas y controles por fuera cubren lo que el legado no hace, y la fuente de verdad deja de estar clara.
Una señal aislada pide atención. Varias al mismo tiempo indican que el costo de mantener el sistema como está ya supera el de modernizarlo, aunque ese costo no aparezca en ninguna factura.
El sistema que se volvió un cuello de botella no siempre es antiguo. En el sistema de gestión de pacientes que desarrollamos para una unidad de atención de urgencias, el punto de partida fue un sistema del mercado que no acompañaba la operación: la integración con la Tarjeta Nacional de Salud fallaba y los informes para la municipalidad terminaban en planillas.
Las cuatro estrategias de modernización, lado a lado
Modernizar no es sinónimo de reescribir. Hay al menos cuatro caminos, y un mismo sistema puede combinar más de uno, módulo a módulo.
| Estrategia | Cuándo tiene sentido | Qué gana usted | Principal riesgo |
|---|---|---|---|
| Mantener e integrar | El sistema funciona y es estable, pero vive aislado. | Los datos pasan a circular por API, sin volver a digitarlos. Vea cómo integrar sistemas. | La deuda técnica sigue ahí, y la integración depende de lo que el legado permita exponer. |
| Refactorizar por partes | El núcleo tiene valor, pero hay partes frágiles o desactualizadas. | Mejora continua, sin un cambio brusco y con el equipo ya acostumbrado al sistema. | Sin pruebas y disciplina, la refactorización se convierte en otra capa de parches. |
| Reescribir | La tecnología ya no tiene salida y el proceso cambió mucho desde el diseño original. | Arquitectura actual, seguridad y un sistema que acompaña la operación de hoy. | El mayor de todos si se hace de una vez: las reglas escondidas en el código antiguo se pierden. |
| Reemplazar por software listo | El proceso es estándar en el sector y una herramienta del mercado ya cubre la rutina. | Rapidez y mantenimiento a cargo del proveedor. Compare en software listo o a medida. | Adaptar el proceso a la herramienta y depender de la hoja de ruta y del precio del proveedor. |
Reescribir no tiene que ser todo o nada. La forma más segura es reescribir por partes: un módulo nuevo entra, asume una función del antiguo y, una vez validado, el antiguo deja de hacer esa parte. En ingeniería de software este patrón se conoce como strangler fig, en referencia a la higuera que crece alrededor de un árbol hasta ocupar su lugar.
Cómo migrar los datos sin detener la operación
Los datos son la parte más delicada de la modernización. El código puede rehacerse; el historial de años de operación, no. Una migración segura suele seguir estos pasos:
- Inventariar lo que existe. Tablas, archivos, campos que se usan de verdad y campos que nadie completa. Las bases antiguas suelen tener duplicados y reglas implícitas.
- Mapear lo antiguo a lo nuevo. Cada campo recibe destino, formato y regla de conversión, revisados con quienes conocen la operación.
- Limpiar antes de mover. Los duplicados y los registros incompletos se resuelven en el origen o en la conversión, con un criterio acordado.
- Ensayar la migración. Ejecutar la carga completa en un ambiente de homologación tantas veces como haga falta y comparar totales y muestras con el sistema antiguo.
- Migrar por módulo o por período. En lugar de un único cambio, la carga se hace por etapas, y cada etapa tiene un plan de vuelta atrás.
- Verificar después del cambio. Los informes del sistema nuevo se comparan con los del antiguo hasta que los números coincidan.
Cuando hay datos personales, la migración también es tratamiento de datos según la LGPD. Conviene aprovechar para revisar qué se guarda, por cuánto tiempo y quién accede, en lugar de solo copiar todo al lugar nuevo.
Cómo conviven el sistema antiguo y el nuevo durante el cambio
En el cambio por partes, durante un tiempo los dos sistemas funcionan juntos. Esa convivencia necesita reglas claras, o el equipo deja de saber dónde registrar cada cosa.
La primera regla es tener una única fuente de verdad para cada dato en cada momento. Si el registro de clientes ya migró, se hace solo en el sistema nuevo, y el antiguo recibe una copia por integración mientras todavía la necesite. La segunda es que el cambio llegue al equipo con capacitación y plazo, módulo a módulo, y no como una pantalla nueva un lunes por la mañana.
Así conducimos este tipo de proyecto: reemplazamos el sistema por partes, un módulo a la vez, con el antiguo funcionando en paralelo hasta que la nueva parte esté validada. Cada módulo nuevo pasa por demostración y pruebas en homologación antes de entrar en uso, como describimos en cómo trabajamos.
Los riesgos de la modernización y cómo reducir cada uno
Todo proyecto de modernización tiene riesgos conocidos. Lo que cambia el resultado es tratarlos desde el inicio, y no cuando aparecen.
- Perder reglas de negocio escondidas. Los sistemas antiguos guardan excepciones que nadie recuerda. Se reduce leyendo el código, conversando con quienes operan y escribiendo pruebas que comparan el comportamiento antiguo con el nuevo.
- Detener la operación en el cambio. Se reduce con el cambio por partes, una convivencia planificada y un plan de vuelta atrás para cada etapa.
- Un alcance que no para de crecer. Modernizar da ganas de cambiarlo todo. Separar lo que es reproducir lo que existe de lo que es una mejora nueva mantiene el proyecto bajo control.
- Resistencia del equipo. Quien usa el sistema hace años necesita participar del diseño y probar antes. La participación de quienes operan es lo que más reduce el retrabajo.
- Cambiar una dependencia por otra. El código versionado, la documentación y la propiedad definida en contrato evitan que el sistema nuevo se convierta en el próximo legado en manos de una sola persona. Más en de quién es el código del software a medida.
Por dónde empezar: la evaluación técnica del sistema actual
El primer paso no es elegir la tecnología nueva, es entender la que existe. Una evaluación técnica del código, de la infraestructura y de la documentación muestra lo que puede quedar como está, lo que necesita corrección y cuáles son los riesgos. Con ella, la estrategia de cada módulo deja de ser una suposición.
También asumimos el mantenimiento de sistemas que no hicimos nosotros, siempre después de esa evaluación. A veces la conclusión es estabilizar e integrar; a veces es planificar el cambio por partes. En desarrollo de software a medida usted encuentra cómo se organiza este trabajo, del estudio al soporte en producción.