Servicios de modernización de aplicaciones legacy y software heredado

El precio es de alcance cerrado y todo incluido, presupuestado en USD en tres niveles. Una auditoría más mejoras rápidas cuesta desde $2,300; la refactorización sistémica de los primeros contextos delimitados, desde $9,200; una modernización completa de principio a fin, desde $28,700. La cifra exacta depende del tamaño y el acoplamiento del sistema, del riesgo de migración de datos, del alcance de cumplimiento y de la plataforma de destino. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de escribir una sola línea de código. No hay recargo por intermediación ni sobrecostes por herramientas, y los costes de la nube corren en sus propias cuentas, de modo que conserva el control del coste.

En la mayoría de los casos, modernizar. Las reescrituras completas fracasan en una proporción muy superior al 50 % porque congelan la hoja de ruta, multiplican el alcance y obligan a un único cutover de alto riesgo. Optamos por defecto por el patrón strangler fig: mantener en marcha el sistema heredado, dirigir el tráfico nuevo a microservicios extraídos de uno en uno por contexto delimitado y retirar el código heredado solo cuando la nueva ruta se haya demostrado en producción. Una reescritura solo se justifica cuando el stack heredado es inmantenible, ya no quedan ingenieros o el cumplimiento la impone, e incluso entonces la hacemos por fases.

Strangler fig es un patrón de refactorización incremental: una capa de enrutado se sitúa delante del sistema heredado y redirige gradualmente las peticiones de capacidades concretas hacia nuevos microservicios. El código heredado sigue funcionando para todo lo que aún no se ha migrado. Cada contexto delimitado (pedidos, facturación, identidad) se extrae, se despliega, se ejecuta en dual-run para validarlo y después se pasa a producción con el cutover. La reversión es un cambio de enrutado, no un nuevo despliegue. Con los meses, el sistema nuevo «estrangula» al antiguo hasta que la aplicación heredada puede retirarse sin riesgo.

El descubrimiento y el plan de migración duran 4–6 semanas. La migración en sí depende del tamaño del sistema y de la tolerancia al riesgo: un monolito de tamaño medio de .NET Framework o PHP de 200–400 KLOC suele quedar listo en 9–18 meses de cutover incremental. Los programas de mainframe y COBOL duran varios años por naturaleza. Trabajamos en fases de 2–3 meses con un cutover demostrable al final de cada fase, de modo que el valor de negocio llega de forma continua en lugar de esperar a un lanzamiento big-bang.

Sí, ese es el objetivo de strangler fig. El sistema heredado sigue en producción durante todo el proceso. El tráfico se desplaza detrás de una capa de enrutado (API gateway, proxy inverso o feature flag) a medida que cada contexto delimitado entra en servicio. Ejecutamos en dual-run la ruta antigua y la nueva, comparamos las salidas y solo cambiamos la escritura canónica cuando se confirma la paridad. Las ventanas de mantenimiento se limitan a los cutovers de bases de datos y suelen durar menos de una hora, programadas con su equipo de operaciones.

Sí. Hemos entregado modernizaciones de .NET Framework 4.x a .NET 8, de Java 8 a Java 21 sobre Spring Boot, de PHP 5/7 a PHP 8 y Node.js, de Delphi/Pascal a C# y TypeScript, de Oracle Forms y PL/SQL a PostgreSQL con servicios en Node o Java, de ASP clásico y VB6 a stacks web modernos y de AngularJS/Knockout/jQuery a React, Vue o Next.js. Las cargas de COBOL y de mainframe se gestionan en colaboración con proveedores especializados de re-hosting cuando hace falta.

Los datos son la parte de mayor riesgo de cualquier modernización, por lo que los tratamos como un flujo de trabajo de primer orden. Empezamos con change data capture (Debezium, envío de logs nativo o CDC del proveedor) para mantener sincronizados los almacenes nuevo y antiguo. Durante el dual-run, las escrituras van a ambos sistemas y una tarea de conciliación señala cualquier divergencia en menos de una hora. Congelamos la ruta de escritura heredada solo después de una ventana de paridad, normalmente de 2–4 semanas, y mantenemos la base de datos heredada como respaldo de solo lectura durante 90 días tras el cutover.

Sí, y es lo habitual. Strangler fig permite que el equipo de funcionalidades y la línea de modernización avancen en paralelo: las funcionalidades nuevas se entregan sobre microservicios recién extraídos desde el primer día, mientras el código heredado gestiona los contextos delimitados que aún no se han migrado. Coordinamos con su responsable de ingeniería las convenciones de ramas, las reglas de límites de servicios y una lista clara de módulos heredados que no se deben tocar, para que ambas líneas no choquen. Normalmente se reserva entre un 20–30 % de la capacidad del sprint del equipo de funcionalidades para el trabajo de integración de la modernización; lo tenemos en cuenta en el plan de fases.

Las integraciones externas se catalogan en el descubrimiento y se clasifican por riesgo de migración. Las integraciones con API documentadas se envuelven primero detrás de una capa de adaptadores interna, de modo que los nuevos microservicios llamen al adaptador y no directamente al conector heredado. Las API de proveedores al final de su vida útil (por ejemplo, un endpoint SOAP obsoleto) se señalan y se sustituyen o se envuelven con una capa de compatibilidad (shim) durante la migración. Las integraciones que no se pueden sustituir durante la migración se mantienen fijadas en el sistema heredado y se migran las últimas, cuando todos los demás contextos delimitados ya están en producción.

Ocurre, y lo planificamos. Durante el dual-run ejecutamos una tarea de conciliación que compara las salidas de la ruta heredada y de la nueva para cada transacción. Las divergencias se clasifican en diferencias esperadas (cambios deliberados de comportamiento), errores heredados que ahora salen a la luz y errores nuevos introducidos en el código migrado. Los errores heredados descubiertos durante la migración se documentan y se priorizan con usted: algunos se corrigen en el servicio nuevo, otros se anotan como incidencias conocidas para corregirlas tras el cutover. No arrastramos en silencio los errores heredados.

Definimos tres capas de métricas de éxito al comienzo: técnicas (cobertura de pruebas, frecuencia de despliegue, MTTR, tasa de errores de los servicios migrados), operativas (reducción de incidentes, diferencia de coste de infraestructura, carga de guardias) y de negocio (velocidad de funcionalidades en el nuevo stack, tiempo de salida al mercado de nuevas capacidades). Se reportan en revisiones mensuales del programa. Cada fase termina con un cutover demostrable y un panel de salud que muestra el porcentaje de tráfico heredado, para que las partes interesadas vean avanzar la migración de forma concreta y no solo en un diagrama de Gantt.