Sustituir software antiguo sin parar la operación no significa prometer cero interrupciones. Significa entender dependencias, reducir el cambio simultáneo, mantener una salida probada y decidir el corte con criterios visibles.
Algunos sistemas admiten convivencia gradual. Otros exigen congelar escrituras o abrir una ventana controlada. El plan debe decir cuál es tu caso y qué ocurrirá si la validación falla.
Confirma qué merece sustituirse
“Es antiguo” no basta. Separa problemas concretos:
- el sistema ya no recibe soporte;
- impide integrar un proceso necesario;
- depende de una persona o tecnología difícil de mantener;
- no permite permisos, trazabilidad o recuperación suficientes;
- limita cambios que el negocio necesita;
- su coste o riesgo operativo ya no es aceptable.
Después decide por componente: mantener, encapsular, integrar, reemplazar o retirar. La guía sobre software a medida frente a SaaS y no-code ayuda a decidir la vía; C06 empieza cuando ya existe un legado que condiciona la transición.
Inventaría procesos y dependencias
No migres solo aplicaciones y tablas. Para cada capacidad crítica registra:
| Campo | Pregunta |
|---|---|
| Proceso | ¿Qué trabajo no puede quedar sin salida? |
| Usuarios | ¿Quién opera, consulta o aprueba? |
| Datos | ¿Qué fuente gobierna y quién escribe? |
| Integraciones | ¿Qué sistemas llaman o reciben información? |
| Regla oculta | ¿Qué decisión vive en código, informe o práctica manual? |
| Ventana | ¿Cuándo puede cambiarse o congelarse? |
| Recuperación | ¿Qué salida existe si falla? |
GOV.UK recomienda entender sistemas dependientes y restricciones antes de alejarse de tecnología heredada (GOV.UK, observada el 29/08/2026). Su contexto es público británico; el inventario es el mecanismo transferible.
Incluye tareas que el equipo realiza fuera del sistema. Un informe manual o una exportación nocturna puede ser una dependencia real aunque no aparezca en la arquitectura.
Elige una estrategia proporcional
Sustitución gradual
Mueve una capacidad o grupo de usuarios cada vez. Una fachada o capa de integración puede dirigir algunas operaciones al sistema nuevo y mantener otras en el legado.
El patrón Strangler Fig de Azure describe esta coexistencia y la retirada progresiva del sistema anterior (Microsoft Learn, observada el 29/08/2026). No sirve por defecto: requiere poder interceptar flujos, sincronizar datos y mantener ambas partes.
Ejecución paralela
Los dos sistemas calculan o procesan temporalmente el mismo trabajo y sus resultados se comparan. Puede ayudar a validar, pero duplica operación y necesita una regla clara sobre cuál es autoritativo.
Corte completo
Todo cambia en una ventana. Puede ser necesario por licencias, arquitectura o identidad de datos. Exige preparación más estricta, responsables presentes, validación rápida y rollback realista.
No elijas una estrategia por etiqueta. Decide según dependencias, escrituras, compatibilidad, tolerancia a interrupción y capacidad operativa.
Define la fuente de verdad durante la convivencia
Cuando legado y nuevo coexisten, responde antes de abrir tráfico:
- ¿qué sistema puede crear o modificar cada dato?
- ¿cómo se identifican entidades?
- ¿qué cambio se sincroniza y con qué retraso?
- ¿cómo se detecta un conflicto?
- ¿quién reconcilia estados dudosos?
- ¿qué historial debe preservarse?
Evita doble escritura sin mecanismo de idempotencia y reconciliación. La guía de idempotencia, reintentos y reconciliación desarrolla esos controles cuando una operación puede repetirse o quedar incierta.
Si vienes de hojas y tareas manuales, ordena antes dato, regla, excepción y parche con la guía para pasar de Excel a un sistema.
Prepara el cutover como una decisión
Un plan de corte puede incluir:
- comprobar replicación y dependencias;
- congelar entradas si es necesario;
- crear backup o punto de recuperación;
- completar sincronización;
- cambiar routing o acceso;
- ejecutar pruebas funcionales y operativas;
- decidir continuar, corregir o volver atrás;
- comunicar estado y siguiente acción.
AWS documenta freeze, backup, sincronización, routing, pruebas y rollback en su guía de cutover (AWS, observada el 29/08/2026). Es orientación cloud específica; no garantiza que esos pasos basten para tu sistema.
Define owner por acción y un responsable final de la decisión. “El equipo técnico revisará” no aclara quién acepta el riesgo operativo.
Fija aceptación y criterios de parada
Antes de cambiar usuarios o tráfico, define:
- flujos críticos que deben pasar;
- integraciones y datos que deben cuadrar;
- permisos y accesos esperados;
- señales operativas que vigilar;
- defectos tolerables y no tolerables;
- checkpoint de decisión;
- gatillo de rollback o fix-forward.
Prepara el alcance y los criterios de aceptación sobre procesos reales, no solo sobre pantallas.
Diseña un rollback que contemple los datos nuevos
Volver atrás es sencillo solo si nada cambió. Si el sistema nuevo ya recibió pedidos, citas, cobros o decisiones, el legado puede estar desactualizado.
El plan debe responder:
- qué escrituras pueden ocurrir después del corte;
- cómo se preservarán;
- si se puede replicar de vuelta;
- qué se congelará durante la decisión;
- quién reconcilia divergencias;
- cuándo el rollback deja de ser seguro.
Por eso “tenemos backup” no equivale a “podemos volver”. Prueba restauración, routing y reconciliación antes de necesitarlos.
Retira el legado al final, no al primer éxito
Mantenerlo para siempre también tiene coste y riesgo, pero retirarlo demasiado pronto elimina la salida.
Antes de apagarlo comprueba:
- usuarios y procesos migrados;
- dependencias sin tráfico;
- datos e historial accesibles;
- integraciones apuntando al destino correcto;
- documentación y owners actualizados;
- periodo de observación acordado;
- archivo o borrado conforme a las obligaciones aplicables.
La operación posterior queda fuera de esta guía: cómo operar una automatización después del lanzamiento cubre owner, señales, runbook, cambios e incidentes.
Checklist del plan de sustitución
- La razón de sustituir está ligada a un problema concreto.
- Procesos, usuarios, datos e integraciones están inventariados.
- Cada componente tiene decisión mantener/integrar/reemplazar/retirar.
- La estrategia de convivencia es compatible con la arquitectura.
- Existe una fuente de verdad por dato y fase.
- El cutover tiene responsables y pruebas.
- Aceptación, parada y rollback están definidos.
- El rollback contempla escrituras posteriores al corte.
- La retirada espera a que no queden dependencias activas.
Al comparar propuestas de software a medida, exige que cada una haga visibles estas decisiones. “Migración incluida” no describe un plan.