Migration Strategy

Razonar sobre el trayecto, además del destino

Migration Strategy describe aquí el enfoque arquitectónico coherente para pasar de una situación actual a otra deseada, mediante estados de transición explícitos, secuencia, dependencias, compatibilidad y controles de riesgo. Es una convención de trabajo del Atlas; no se propone una definición normativa universal de migration, modernization o reengineering.

El resultado necesita explicar qué se mueve, por qué ese orden es viable, quién conserva autoridad mientras coexisten soluciones y cómo se reconocerán avance, fallo y finalización. «Reescribir Payments» o dibujar una arquitectura objetivo deja esas preguntas abiertas. Un ADR registra una decisión, pero no necesariamente explica toda la transición que requiere realizarla.

La investigación de SEI estudia alternativas combinadas de migración de código, datos y deployment, con ventajas y costos según el caso. Legacy System Modernization Strategies, 2001, secciones 5–6. No se trasladan sus opciones específicas como una secuencia obligatoria del Atlas.

Estrategia, plan, objetivo y mecanismos

Estas distinciones separan niveles de razonamiento que pueden superponerse en documentos reales:

Elemento	Pregunta que ayuda a responder
Arquitectura objetivo	¿Qué propiedades y responsabilidades se desean?
Migration Strategy	¿Qué trayecto y compromisos permiten llegar allí?
Migration Plan o project plan	¿Qué tareas, fechas, personas y coordinación detallada se organizan?
Mecanismo de transición	¿Cómo se realiza un cambio particular dentro del trayecto?
Evidencia	¿Qué observaciones permiten continuar, ajustar o detenerse?

strangler-fig, parallel-change y branch-by-abstraction pueden participar en una estrategia; utilizarlos no la completa automáticamente. También puede justificarse un cutover coordinado. La estrategia decide dónde, cuándo y por qué combinar mecanismos; no es un sinónimo de Strangler Fig ni una variante de planificación Gantt.

refactor-vs-rewrite compara enfoques de transformación para un alcance. Esta decisión influye en la transición, y la factibilidad del trayecto puede hacerla reconsiderar. La estrategia sigue siendo necesaria tanto para una reorganización significativa como para reemplazar una implementación.

Conocer la situación actual

Mapear capacidades, dependencias, contratos, datos autoritativos, runtime, unidades de deployment, consumidores y procedimientos de operación. La documentación disponible es evidencia parcial. legacy-systems recuerda que reportes, jobs y recuperación manual pueden mantener relaciones que el diagrama omite.

La discovery debe concentrarse en incertidumbres que cambian la viabilidad: quién escribe una tabla, qué contrato vence o qué población necesita continuidad. No exige reconstruir exhaustivamente todo antes del primer aprendizaje. Registros de uso y conocimiento del equipo pueden orientar una investigación, con límites de cobertura explícitos.

SMART analiza componentes existentes, entorno objetivo, factibilidad, costo y riesgo en el contexto específico de reutilización para SOA. Lewis y otros, SMART, 2008. Informa la disciplina de preguntar por ambos extremos y sus diferencias; no define una estrategia genérica que obligue a adoptar SOA.

Un objetivo guiado y revisable

architectural-drivers debe explicar las mejoras requeridas: soporte, autonomía de entrega, seguridad, capacidad o costo, por ejemplo. constraints puede imponer retención, residencia, continuidad, fecha de salida del proveedor, compatibilidad y capacidad limitada del equipo. Un destino atractivo pero incompatible con esas obligaciones no basta.

El objetivo puede permanecer parcialmente abierto al comienzo. Debe precisarse lo suficiente para evaluar el siguiente compromiso y evitar pasos que bloqueen propiedades importantes. No es necesario escoger por anticipado cada tecnología futura para decidir quién será responsable de una autorización.

Una fecha contractual puede entrar en conflicto con continuidad, retención o capacidad del equipo. La estrategia debe exponer esa tensión y las alternativas que conserva: renegociar alcance, sostener un adapter, cambiar una secuencia o aceptar un corte explícito. Un calendario optimista no demuestra que las condiciones sean compatibles. Si no hay un trayecto viable bajo las restricciones actuales, corresponde revisar compromisos antes de asumir que los mecanismos lo resolverán.

evolutionary-architecture puede guiar esa revisión incremental; no equivale a Migration Strategy ni obliga a que toda transición carezca de cutovers. Tampoco el objetivo tiene que ser Microservices, cloud o Serverless. Puede conservar un modular-monolith si responde mejor al contexto.

Arquitectura de los estados intermedios

Entre origen y destino pueden existir dos APIs, adapters, routing, implementaciones paralelas o sincronización temporal. Transitional Architecture hace explícito que algunos elementos solo facilitan el desplazamiento y después se retiran. Cartwright, Horn y Lewis.

Cada estructura temporal necesita motivo, responsable y condición de salida. No toda duplicación constituye automáticamente technical-debt; puede ser trabajo necesario de transición. Cuando genera carga futura aceptada, conviene declarar su costo esperado y retiro. Si una excepción pierde seguimiento y debilita intención vigente, puede contribuir a architecture-erosion.

Los estados necesitan conservar suficiente disponibilidad, operability e interoperability para las obligaciones acordadas. Pueden empeorar algunas qualities respecto del destino: más latencia por traducción, operación doble o diagnóstico difícil. Aceptar ese compromiso requiere alcance y duración, no afirmar que cada incremento mejora toda quality.

Secuencia y tamaño del movimiento

dependency-structure revela qué necesita cada participante. A → B no decide por sí sola migrar B primero: versiones compatibles o un adapter pueden permitir comenzar por A. Deben examinarse conjuntamente orden, compatibilidad, costo transitorio y consumidores preparados.

Valor comercial, riesgo, factibilidad, ownership, capacidad del equipo y aislamiento operacional pueden favorecer órdenes distintos. El estudio de modernización incremental de SEI muestra cómo adapters pueden desacoplar estructura anterior y destino; también advierte que seguir ciegamente las piezas heredadas puede reproducir esa arquitectura. Incremental Modernization of Legacy Systems, 2001.

granularity ayuda a elegir slices: capacidad, endpoint, workflow, tenant, región, conjunto de datos o población. Un slice pequeño puede reducir exposición y aumentar routing y duración; uno grande puede acortar coexistencia y elevar riesgo de corte. No hay algoritmo universal ni tamaño óptimo independiente del sistema.

Autoridad y compatibilidad en cada estado

data-ownership exige declarar quién es autoritativo ahora, quién lo será después y qué hecho cambia esa asignación. Dos versiones activas no deben convertirse silenciosamente en dos autoridades sobre la misma operación. Las copias necesitan propósito, frescura, reconciliación y política de acceso.

Una estrategia puede conservar escrituras antiguas mientras el reemplazo lee, y después trasladar operaciones nuevas por población identificada. Hay que definir trabajo en vuelo, correcciones tardías y antecedentes necesarios. Las escrituras independientes continúan expuestas a fallos parciales y orden; un diagrama de coexistencia no las hace atómicas.

parallel-change puede sostener contratos y schemas mientras migran consumidores. Precisar combinaciones de API, eventos, storage y versiones que deben funcionar, además de workflows de usuarios. deployability pregunta si la secuencia puede llevarse a ejecución con seguridad. Instalar v2 no demuestra que v1 entienda sus nuevos datos.

data-migration profundiza decisiones sobre semántica, validación y transferencia de autoridad; cloud-migration, cambios de entorno, dependencias y responsabilidades. Ambas pueden combinarse o aparecer separadamente. Ninguna sustituye el razonamiento general sobre estados, secuencia y transición, ni obliga a usar una taxonomía de proveedor como estrategia universal.

Coexistencia, contingencia y punto de no retorno

Decidir qué población usa cada camino, quién sostiene ambos, qué información cruza, cuánto tiempo se espera coexistencia y qué evidencia la termina. Una fecha orienta coordinación, pero no prueba retiro de consumidores. Prolongar coexistencia puede consumir recursos; reducirla demasiado puede concentrar riesgo.

Rollback puede ser viable mientras el camino anterior interpreta estado y efectos. Después de una transformación incompatible o una operación externa, puede requerirse roll-forward, reparación o compensación. Compensar no equivale a borrar la historia ni garantiza un inverso exacto.

Las contingencias deben corresponder al estado alcanzado: detener expansión de tráfico, deshabilitar exposición, volver a un camino compatible, reconciliar información u operar ambos temporalmente. Identificar quién decide y qué señales disparan revisión evita prometer «rollback disponible» sin explicar datos y efectos. No se ofrece un playbook único.

Evidencia para avanzar y para retirarse

Observar tráfico anterior y nuevo, resultados finales, errores, latencia, divergencias, consumidores, backlog y presión de recursos. fitness-functions puede evaluar expectativas seleccionadas y condiciones de salida. Monitoring por sí solo no constituye estrategia ni cubre automáticamente todos los consumidores.

testability facilita preparar escenarios y diagnosticar diferencias. Characterization evidence puede mostrar comportamiento actual sin justificar conservarlo. Comparar cálculos sin efectos puede ayudar; duplicar cobros, reservas, correos o envíos reales para observar paridad puede crear daño. Una segunda lectura también puede tener costo y carga que deben evaluarse.

Un mecanismo temporal termina cuando se cumple su condición, no porque se terminó de programar el destino. Para un adapter puede ser ausencia comprobada de usos antiguos dentro del alcance soportado; para una copia, finalización de consumidores y obligaciones que la requieren. La evidencia necesita cobertura y una ventana representativa, no solo un contador momentáneamente en cero.

Commerce: una trayectoria posible

Esta tabla es una síntesis del Atlas, no una metodología de las fuentes. Payments v1 usa un proveedor anterior; Orders, Inventory y Shipping necesitan continuidad:

Estado ilustrativo	Autoridad y condición para avanzar
Comprender y preparar la frontera	v1 conserva autoridad; se identifican refunds, escritores, lectores y comportamiento relevante.
Introducir v2 sin efectos duplicados	v1 sigue siendo autoritativo; v2 observa o compara cálculos bajo condiciones controladas.
Trasladar operaciones seleccionadas	v2 gobierna las nuevas de la población acordada; v1 conserva las restantes e históricas, con asignación inequívoca por operación.
Completar el alcance y retirar	Se resuelven consumidores, autoridad e historia exigibles antes de retirar caminos que ya no cumplen una obligación.

Dentro de esa trayectoria, branch-by-abstraction puede sustituir motores; parallel-change, evolucionar PaymentAuthorized; strangler-fig, dirigir flujos seleccionados. La composición responde a necesidades del caso, no exige emplear siempre los tres mecanismos ni mover porcentajes de tráfico en todos los pasos.

Un refund histórico puede seguir necesitando referencias y acceso al proveedor anterior. Hasta atender esas obligaciones, migrar autorizaciones nuevas no equivale a completar toda Payments. Conservar un componente de soporte puede ser deliberado, pero debe quedar visible qué parte no terminó y quién la opera.

Un reporte de BI que lee tablas antiguas puede bloquear Contract aunque los consumidores de eventos ya hayan migrado. interfaces ofrece una frontera para acordar otro acceso. Orders continúa solicitando cambios a Payments; no toma autoridad escribiendo tablas de una u otra versión.

Costo, organización y cierre efectivo

cost-efficiency incluye infraestructura y soporte dobles, sincronización, adapters, pruebas, capacitación y retirada. systems-thinking incorpora equipos, usuarios, compliance, proveedores y finanzas. Un cambio local puede fracasar globalmente si operación no puede sostener los estados intermedios o si soporte desconoce a quién pertenece una transacción.

Finalizar el alcance exige criterios explícitos: trabajo transferido, autoridad acordada, consumidores pendientes resueltos, estabilidad observada, soporte actualizado y componentes obsoletos retirados. Los artifacts de recuperación se conservan o retiran según la política acordada. Retención histórica no autoriza perder responsabilidad sobre la información.

Una jerarquía de razonamiento del Atlas conecta drivers y constraints → comprensión actual → decisión refactor/rewrite/mixta → objetivo → estrategia → mecanismos → evidencia → cierre. Puede recorrerse y revisarse con feedback; no impone un lifecycle universal ni evita reconsiderar la decisión al descubrir una dependencia.

deprecation comunica qué dependencia deja de ser preferida y cómo preparar a consumidores; sunsetting desarrolla la retirada controlada y sus obligaciones de soporte, historia y datos. Sus fechas y avisos no sustituyen estados ni criterios de salida. evolution-and-modernization mantiene esas preguntas separadas de estrategia y mecanismos: escoger un destino o instalar software nuevo no resuelve el trayecto.