Auditoría técnica
Mapeamos la deuda existente, los riesgos reales y las mejoras rápidas que se pueden atacar primero sin tocar nada crítico.
// MODERNIZACIÓN
Sistemas modernos sin tirar lo que ya funciona.
Transformamos plataformas legacy en sistemas actuales, de a partes y en producción. Sin cortes, sin pérdida de datos y sin el riesgo de una reescritura total que tarda un año en mostrar algo.
// DEFINICIÓN
¿Qué es modernizar un sistema legacy?
Modernizar un sistema legacy es reemplazar por partes la tecnología de un software que sigue en producción, sin interrumpir la operación. En lugar de reescribirlo entero, se pone el sistema nuevo delante del viejo y se le van pasando funcionalidades de a una, con cada paso funcionando y reversible.
Ese patrón tiene nombre —strangler fig, por la higuera que envuelve al árbol hasta reemplazarlo— y es la diferencia entre un proyecto que entrega valor desde la tercera semana y uno que pide un año de fe. En la migración progresiva siempre hay una versión estable en producción; si un paso sale mal, se vuelve atrás ese paso y nada más.
El escenario más habitual, y el que más asusta, es el sistema sin documentación y sin nadie que lo haya escrito. Se resuelve reconstruyendo el comportamiento desde afuera: qué entra, qué sale, qué queda en la base. Antes de reemplazar una parte se la cubre con pruebas que fijan cómo se comporta hoy, incluidos los errores que el negocio ya asumió como normales y de los que alguien depende sin saberlo.
// NUESTRO PROCESO
Modernización sin interrumpir la operación.
Migración progresiva
Reemplazo de componentes uno por uno mientras el sistema sigue operando, con la posibilidad de volver atrás en cada paso.
Migración de datos validada
Los datos se comparan en las dos puntas antes de dar por buena cada tabla, y lo que ya no encaja en el modelo nuevo se conserva consultable.
// COMPARATIVA
Migración progresiva o reescritura total.
La reescritura desde cero es tentadora y a veces correcta. Conviene saber qué se está firmando.
| Criterio | Migración progresiva | Reescritura total |
|---|---|---|
| Primer resultado visible | Semanas: cada etapa deja algo mejor en producción. | Al final del proyecto, cuando ya no hay margen para corregir. |
| Riesgo | Repartido en pasos chicos y reversibles. | Concentrado en un único día de cambio. |
| El sistema viejo mientras tanto | Sigue operando y se le siguen haciendo cambios. | Hay que congelarlo o mantener dos sistemas en paralelo. |
| Conocimiento del negocio | Se rescata función por función, con pruebas que lo fijan. | Se pierde lo que nadie recordó documentar. |
| Cuándo conviene | Sistemas grandes, críticos o que no pueden dejar de operar. | Sistemas chicos, o cuando la tecnología base ya no tiene soporte. |
// DATOS CONCRETOS
Cómo trabajamos, en números.
- Auditoría inicial
- 2 a 3 semanas Deja el mapa de riesgos, la deuda priorizada y el plan por etapas, con las mejoras rápidas separadas del trabajo de fondo.
- Migración completa
- Meses, por entregas Depende del tamaño, pero cada etapa deja algo funcionando mejor en producción. No hay una entrega única al final.
- Downtime
- Cero en una migración planificada El entorno nuevo corre en paralelo, se prueba con tráfico controlado y el viejo queda disponible por si hay que volver.
- Método
- Strangler fig: reemplazo función por función Siempre hay una versión estable en producción. Si un paso sale mal, se revierte ese paso y nada más.
- Datos históricos
- Migrados con validación en las dos puntas Se compara el resultado en el sistema viejo y en el nuevo antes de dar por buena cada tabla.
- Sin documentación
- Se reconstruye desde el comportamiento Pruebas que fijan cómo funciona hoy antes de tocar nada, incluidos los errores que alguien ya usa como si fueran funcionalidades.
//PREGUNTAS FRECUENTES
Lo que nos preguntanantes de empezar.
¿Se puede modernizar un sistema sin frenar la operación?
Sí, con migración progresiva. El sistema nuevo se pone delante del viejo y se le van pasando funcionalidades de a una, mientras el resto sigue funcionando igual. Es el patrón conocido como strangler fig: en cada paso hay una versión estable en producción y siempre existe la posibilidad de volver atrás.
¿Conviene reescribir de cero o migrar por partes?
Por partes, salvo que el sistema sea muy chico. La reescritura total exige congelar el sistema viejo durante meses —o mantener dos— y recién muestra resultados al final, cuando ya no hay margen. La migración progresiva entrega valor desde las primeras semanas y reparte el riesgo en pasos reversibles.
¿Cuánto tarda modernizar un sistema legacy?
La auditoría inicial lleva de 2 a 3 semanas y deja el mapa de riesgos y el plan por etapas. La migración completa depende del tamaño y se mide en meses, pero se trabaja por entregas: cada etapa deja algo funcionando mejor en producción, no un avance que solo se ve al final.
¿Qué pasa con los datos históricos?
Se migran con validación en las dos puntas: se compara el resultado en el sistema viejo y en el nuevo antes de dar por buena cada tabla. Cuando hay datos que ya no encajan en el modelo nuevo, se conservan en un archivo consultable en vez de forzarlos a una estructura que no los representa.
¿Y si no hay documentación ni queda nadie que lo haya escrito?
Es el escenario más habitual. Se reconstruye el comportamiento desde afuera: qué entra, qué sale, qué hace la base de datos. Antes de reemplazar una parte se la cubre con pruebas que fijan cómo se comporta hoy, incluidos los errores que el negocio ya asumió como normales y de los que alguien depende.
Cuánto cuesta modernizar un sistema legacy.
Menos de lo que cuesta no hacerlo. Cada mes que un sistema legacy sigue en producción suma deuda, hace más lento cada cambio nuevo y aumenta la probabilidad del incidente que nadie quiere. La migración progresiva recupera velocidad sin apostar todo a un solo día.