Migración de software legacy
Modernizá tu software sin detener el negocio.
Analizo qué contiene el sistema, qué riesgo representa y cuál es la transición más segura — sin empezar por un rewrite a ciegas.
En una conversación inicial de 30 minutos revisamos el contexto, la criticidad, el evento que genera urgencia y si existe encaje para un assessment. No necesitás compartir código ni información confidencial en esta etapa.
Qué es legacy (en la práctica)
Legacy no es solo “código viejo”. Es software que sostiene operación, ingresos o cumplimiento, pero que se volvió difícil de cambiar con confianza.
- Cambios lentos o riesgosos
- Conocimiento concentrado en pocas personas
- Stack fuera de soporte o sin tests confiables
- Documentación incompleta o desactualizada
- Integraciones frágiles que nadie quiere tocar
Cuándo modernizar
- El producto o la operación ya no pueden evolucionar al ritmo del negocio
- Hay un evento de inversión, venta, auditoría o cambio de proveedor
- El costo de mantener supera el costo de una transición planificada
- Necesitás incorporar integraciones o capacidades nuevas con control
Cuándo no reescribir
No empiezo reescribiendo. Primero entiendo qué lógica debe preservarse, qué puede retirarse y qué puede migrarse por oleadas.
- Si el riesgo de parar la operación es alto
- Si el conocimiento del dominio vive solo en el código
- Si no hay evidencia de comportamiento (tests, logs, contratos)
- Si el problema real es ownership, no el lenguaje
Estrategias posibles
Retain / Retire
Qué conservar y qué apagar con evidencia.
Rehost / Replatform
Mover con cambios acotados de infraestructura o plataforma.
Refactor / Rebuild
Intervenir módulos críticos o reconstruir dominios específicos.
Strangler progresivo
Convivencia, feature flags, dual run y cutover por oleadas.
Rol de la IA
IA para acelerar. Criterio experto para decidir y validar.
- Análisis y documentación
- Detección de dependencias
- Generación de tests de caracterización
- Comparación funcional y extracción de reglas
- Nunca como sustituto de arquitectura, seguridad o responsabilidad
Qué entregás al final de un assessment
- Mapa de riesgos y dependencias
- Opciones retain / retire / rehost / replatform / refactor / rebuild
- Secuencia sugerida y riesgos de cutover
- Plan de datos, pruebas y rollback
- Estimación por rangos (cuando hay evidencia suficiente)
Qué ocurre en la primera reunión
En una conversación inicial de 30 minutos revisamos el contexto, la criticidad, el evento que genera urgencia y si existe encaje para un assessment. No necesitás compartir código ni información confidencial en esta etapa.
Qué conviene preparar
- Sistema o producto
- Tecnología conocida
- Antigüedad aproximada
- Criticidad para el negocio
- Problema principal
- Equipo actual
- Evento que genera urgencia
- Fecha límite aproximada
Qué no ocurre
- — No se hace una auditoría completa gratuita
- — No se requiere acceso al repositorio
- — No se solicitan credenciales
- — No se comparten secretos
- — No se promete presupuesto sin diagnóstico
Preguntas frecuentes
- ¿Migrar es lo mismo que reescribir?
- No. Migrar puede incluir coexistencia, strangler, replatform o refactor selectivo. Reescribir todo es una opción, no el punto de partida.
- ¿Podés garantizar cero downtime?
- No. Diseño transiciones que minimizan interrupción y maximizan control (rollback, observabilidad, oleadas). La continuidad se planifica; no se promete magia.
- ¿Empezamos con código?
- La primera reunión no requiere acceso al repositorio. Si hay encaje, el siguiente paso suele ser un Legacy Risk Scan o una auditoría paga.