Plataformas y flujos
Modernización de sistemas heredados
El sistema antiguo pierde responsabilidades por etapas, y cada función migrada queda respaldada por pruebas que muestran si su resultado cambia.
Un sistema heredado suele seguir funcionando precisamente porque la empresa depende de él. El problema aparece cuando nadie se atreve a tocarlo, la tecnología ya no tiene soporte, cuesta encontrar a quien lo mantenga o impide conectar herramientas nuevas. Reescribirlo de golpe es tentador y arriesgado: buena parte de sus reglas no están documentadas y solo se descubren al romperlas. Por eso planteamos la modernización por etapas. Primero se audita el código, los datos y el uso real; después se rodean las partes críticas de pruebas y se sustituyen módulos uno a uno, haciendo convivir lo antiguo con lo nuevo hasta que el sistema original puede retirarse.
- Entrada de datos
- Código y esquema heredados
- Registros de uso real
- Entrevistas con usuarios clave
- Validación
- Pruebas de caracterización
- Conteos y sumas de control
- Procesamiento
- Fachada y enrutamiento por función
- Sincronización temporal de datos
- Control humano
- Validación por usuarios clave
- Decisión de corte por etapa
- Trazas
- Resultados comparados antiguo y nuevo
- Discrepancias de migración resueltas
- Sistemas de salida
- Módulo nuevo en producción
- Plan de vuelta atrás
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: una correduría con una aplicación de escritorio antigua que calcula comisiones y que solo sabe mantener una persona.
01 · Antes
Cualquier cambio en el cálculo de comisiones se retrasa por miedo a romper algo, no hay pruebas automáticas y las reglas solo están escritas en el código.
02 · Sistema propuesto
Se registran entradas y salidas reales del cálculo como pruebas de caracterización, se coloca una API delante y el módulo nuevo se ejecuta en paralelo con el antiguo.
03 · Después
Durante el periodo en paralelo se comparan los resultados de ambos sistemas comisión a comisión y se decide con datos cuándo retirar el módulo antiguo.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Inventariar qué hace realmente el sistema actual: funciones, usuarios, integraciones, procesos programados y datos.
- Exponer los datos o funciones del sistema antiguo mediante APIs para que otras aplicaciones dejen de depender de su interior.
- Sustituir módulos de forma progresiva, redirigiendo cada función al componente nuevo cuando está listo.
- Migrar datos con validaciones, conteos y comparaciones que demuestren que no se ha perdido información.
- Reducir la dependencia de una tecnología sin soporte o de una única persona que conoce el sistema.
Qué no resuelve
- No asegura una migración sin interrupción del servicio: eso solo puede valorarse tras estudiar el sistema, los datos y las ventanas disponibles.
- No recupera reglas de negocio que ya nadie conoce sin un trabajo de análisis, pruebas y validación con los usuarios.
- No hace que modernizar sea siempre rentable; a veces lo razonable es mantener el sistema y aislarlo.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Auditoría e inventario inicial
- Entrada
- Código fuente si existe, esquema de base de datos, tareas programadas, registros de uso y entrevistas con usuarios.
- Procesamiento
- Se identifican módulos, dependencias, integraciones y funciones que ya no se usan, y se señalan las zonas más arriesgadas o con más cambios pendientes.
- Salida
- Mapa del sistema, lista priorizada de módulos a modernizar y propuesta de etapas con sus riesgos.
02
Sustitución gradual por estrangulamiento
- Entrada
- Una aplicación monolítica con varias funciones en uso, por ejemplo pedidos, facturación e informes.
- Procesamiento
- Se coloca una capa de enrutamiento delante del sistema y cada función se reimplementa en un componente nuevo, al que se desvía el tráfico solo cuando supera las pruebas.
- Salida
- Sistema híbrido que va perdiendo responsabilidades hasta que el monolito puede apagarse.
03
Pruebas de caracterización antes de refactorizar
- Entrada
- Funciones críticas sin documentación ni pruebas, como un cálculo de precios o de liquidaciones.
- Procesamiento
- Se registran entradas y salidas reales del sistema actual y se convierten en pruebas automáticas que fijan su comportamiento, incluidos sus defectos conocidos.
- Salida
- Batería de pruebas que permite refactorizar o reescribir sabiendo si el resultado cambia.
04
Migración de datos con verificación
- Entrada
- Base de datos antigua con formatos obsoletos, campos reutilizados y registros incompletos.
- Procesamiento
- Extracción, limpieza y transformación ensayadas varias veces sobre copias, con conteos, sumas de control y muestreos revisados por los usuarios.
- Salida
- Datos cargados en el sistema nuevo, informe de discrepancias resueltas y plan de vuelta atrás si la carga final falla.
Integración
Cómo se conecta con lo que ya existe
Durante la modernización conviven dos sistemas, y eso es lo que más hay que diseñar. Se decide cuál es la fuente de verdad de cada dato en cada etapa, cómo se sincronizan mientras ambos están activos y qué integraciones externas se redirigen y cuándo. Una API delante del sistema antiguo suele ser el primer paso, porque permite cambiar lo que hay detrás sin afectar a quien lo consume.
- Capa de API o fachada delante del sistema heredado
- Enrutamiento por función entre el componente antiguo y el nuevo
- Sincronización temporal de datos mientras ambos sistemas están activos
- Redirección progresiva de integraciones con terceros
- Monitorización comparada de resultados entre sistema antiguo y nuevo
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Acceso al código fuente, a la base de datos y a un entorno donde pueda ejecutarse el sistema sin afectar a producción.
- Usuarios clave disponibles para explicar procesos y validar que el sistema nuevo se comporta como esperan.
- Ventanas de mantenimiento y tolerancia a paradas acordadas con operación antes de planificar cortes.
- Copias de seguridad verificadas y procedimiento de vuelta atrás para cada etapa.
- Decisión explícita sobre qué funciones se migran tal cual, cuáles se rediseñan y cuáles se abandonan.
Supervisión
Riesgos, límites y mantenimiento
- Las reglas implícitas del sistema antiguo aparecen tarde; las pruebas de caracterización reducen ese riesgo, pero no lo eliminan.
- Mantener dos sistemas en paralelo tiene un coste temporal que hay que asumir y limitar con un calendario.
- Una migración de datos mal ensayada puede causar pérdidas difíciles de detectar; se ensaya tantas veces como haga falta.
- Si el proyecto se detiene a mitad, la empresa puede quedar con un sistema híbrido más complejo que el original; cada etapa debe dejar algo estable.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Preguntas frecuentes
¿Es mejor reescribir desde cero o modernizar por partes?
Reescribir desde cero solo suele compensar cuando el sistema es pequeño o sus reglas están bien documentadas. En sistemas grandes y críticos, sustituir por partes permite entregar valor antes, detectar errores pronto y no apostarlo todo a un único corte.
¿Se puede modernizar sin el código fuente original?
A veces sí, trabajando sobre la base de datos, las interfaces y el comportamiento observable del sistema. Es más lento y arriesgado, y se valora tras una auditoría inicial que indique qué se puede reconstruir con fiabilidad.
¿Habrá que parar la operación durante la migración?
Depende del sistema, del volumen de datos y de las ventanas disponibles. En muchos casos se puede reducir la parada a un corte breve, pero no lo afirmamos hasta haber estudiado el caso y ensayado la migración.
Cuéntanos qué sistema te preocupa y qué depende de él
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.