Moderniza Sin Romper el Negocio

Las reescrituras suelen fracasar en software crítico de producción porque (1) el sistema viejo codifica años de reglas de negocio edge-case que nadie recuerda, (2) la reescritura congela funcionalidades nuevas durante 12+ meses mientras los competidores siguen avanzando, y (3) todo el riesgo se concentra en un solo cutover big-bang. El patrón strangler-fig te permite reemplazar el sistema una capacidad a la vez, con cutovers reversibles — más lento pero dramáticamente más seguro.

Sí. Nuestro equipo ha entregado migraciones de producción desde COBOL, Delphi 7, classic ASP, VB6, PowerBuilder, .NET Framework 2/3.5 y PHP 5. Normalmente no escribimos código nuevo en esos lenguajes — los leemos para extraer reglas de negocio, luego construimos el reemplazo en stacks modernos (.NET 8, Java 21, Node.js, Python).

Es el escenario más común. La Fase 1 (Auditoría) es en parte arqueología de código — leemos el SQL, las stored procedures, los datos, y reconstruimos las reglas de negocio. Lo combinamos con entrevistas estructuradas a los usuarios actuales (que a menudo saben más de lo que creen). El entregable de la auditoría es en parte esa documentación que falta.

Compliance es una restricción desde el primer día, no un checkpoint al final. Mapeamos los controles actuales (audit logs, RBAC, cifrado, políticas de retención) y nos aseguramos de que cada uno se traslada. Donde el sistema legacy ya no era compliant (sin audit log, criptografía débil), la modernización es el fix más barato — añadimos controles en el código nuevo mientras el viejo se desmonta.

Para la mayoría de proyectos: minutos, no horas. El patrón strangler-fig significa que el cutover es incremental — movemos 1% del tráfico, luego 10%, luego 100%. Nunca hay un momento en que 'el sistema está caído por la reescritura'. Incluso los cutovers de capa de datos usan técnicas (dual write, swap progresivo tabla-a-tabla) que mantienen la aplicación disponible todo el tiempo.

Ambas, siempre. El código de la aplicación no tiene sentido sin los datos. Nuestras migraciones incluyen: diseño de esquema para la nueva BD, scripts ETL (idempotentes, reanudables), herramientas de reconciliación que comparan número de filas y checksums, y un plan de archivado de 90 días para que la BD vieja siga accesible para auditoría incluso después de retirar la aplicación.