Cloud Migration
Cambiar entorno y responsabilidades
Cloud Migration describe el traslado controlado de aplicaciones, datos, workloads o capacidades de soporte hacia un entorno cloud o servicios gestionados en él. Incluye decisiones sobre ejecución, dependencias y operación; no equivale solamente a iniciar una VM remota.
El destino no es homogéneo. NIST distingue modelos de servicio IaaS, PaaS y SaaS, además de modelos de deployment; esa caracterización proporciona contexto, no una estrategia de migración. NIST SP 800-145, 2011. Una transición puede combinar infraestructura, plataformas, datos y messaging gestionados, contenedores o integración SaaS, con responsabilidades diferentes.
Trasladarse a cloud no demuestra modernización. Mover una VM puede cambiar hosting, red, operación y costos manteniendo gran parte de la aplicación. También puede modernizarse on-premises. El resultado depende de qué propiedades mejoran y qué obligaciones siguen vigentes, no de la dirección del datacenter.
Lo que puede permanecer igual
Un sistema migrado puede seguir siendo monolítico, stateful, estrechamente acoplado y escalado manualmente. Cloud-native modernization supone otras decisiones; no aparece automáticamente al mover ejecución ni constituye un requisito para toda migración.
monolith y modular-monolith pueden ejecutarse en cloud; microservices puede ejecutarse fuera de cloud público. serverless-architecture es un posible conjunto de decisiones y runtime, no el significado de Cloud Migration. No hay una escala obligatoria on-prem → cloud → Microservices → Serverless.
migration-strategy conserva el razonamiento general: situación actual, destino, estados intermedios, secuencia, autoridad, contingencias y cierre. Cloud Migration incorpora preocupaciones del entorno y sus servicios. Un framework de adopción de un proveedor no redefine por ello toda estrategia arquitectónica de transición.
Vocabularios de alternativas: contexto antes que número
Stephen Orban describe seis alternativas en 2016 y atribuye su antecedente a cinco Rs de Gartner de 2011. Esa atribución histórica procede de Orban; aquí no se reconstruye una clasificación original de Gartner a partir de fuentes secundarias. AWS, 6 Strategies for Migrating Applications to the Cloud.
La guía actual de AWS enumera siete: retire, retain, rehost, relocate, repurchase, replatform y refactor/re-architect. El CAF de Microsoft enumera retire, retain, rehost, replatform, refactor, rearchitect, rebuild y replace. Son vocabularios situados, no «las Rs» universales.
Google Cloud también distingue refactor de re-architect. No se normalizan silenciosamente esas categorías. En particular, el refactor/re-architect amplio de algunos frameworks puede incluir modificaciones que no cumplen la definición precisa de refactoring de Fowler desarrollada en refactor-vs-rewrite.
Las alternativas sirven para preguntar qué cambia realmente. No sustituyen evaluar dependencias ni constituyen niveles de madurez que toda carga deba recorrer.
Rehost, replatform y decisiones sobre el portfolio
Rehost suele minimizar modificaciones de aplicación mientras cambia el hosting. Puede ser racional ante una salida de datacenter o una carga estable. Conserva parte del conocimiento operacional y también puede trasladar problemas existentes: utilización ineficiente, dependencias locales o restricciones de estado.
Replatform cambia elementos de plataforma o runtime sin rediseñar necesariamente toda la aplicación. El ejemplo de Orban incluye pasar de una base autogestionada a un servicio gestionado. Para Commerce, eso exige comprobar capacidades, compatibilidad y operación; el nombre no garantiza que el motor destino conserve todos los comportamientos requeridos.
Repurchase o replace puede significar sustituir una capacidad por un producto o SaaS. Cambia la solución adquirida, no solo el lugar de la implementación actual. Retain conserva intencionalmente ciertas cargas por latencia, hardware, contrato, riesgo o valor insuficiente del movimiento. Retire elimina trabajo de migración cuando la capacidad deja de ser necesaria, después de resolver sus obligaciones.
AWS utiliza relocate para movimientos de plataforma y otros desplazamientos con cambios mínimos de aplicación. No se obliga al Atlas a convertirlo en categoría independiente para todo caso. deprecation comunica abandono progresivo de capacidades; sunsetting desarrolla su retirada. Migrar hacia cloud no obliga a retirar infraestructura on-premises que siga cumpliendo una función deliberada en el destino híbrido.
Drivers, restricciones y evidencia del workload
architectural-drivers puede justificar salida de instalaciones, alcance geográfico, elasticidad, soporte, entrega o delegación de operación. «Cloud es moderno» no identifica una mejora verificable. Precisar alcance y resultado permite comparar mover, conservar, reemplazar o combinar por capacidad.
Inventariar runtime, dependencias, flujos de red, datos, sensibilidad a latencia, continuidad, licencias, carga y procedimientos. legacy-systems recuerda que jobs, reportes y recuperación manual pueden estar fuera del inventario inicial. Migrar un servidor sin esos usos puede producir una plataforma encendida y un proceso comercial incompleto.
constraints incluye residencia, regiones admitidas, cifrado, acuerdos con proveedores, hardware y fecha de salida. Algunas restricciones desaparecen; otras cambian o aparecen. Conservar evidencia de lo supuesto evita confundir disponibilidad comercial de un servicio con viabilidad bajo las obligaciones del workload.
Networking, identidad y acceso
Una aplicación puede asumir DNS interno, IPs estables, filesystem compartido, conectividad este-oeste amplia o latencia de una red local. Conservar código no conserva esas condiciones. Un tramo híbrido puede añadir saltos, fallos y tiempos diferentes entre un frontend trasladado y su base todavía on-premises.
Examinar resolución de nombres, rutas y autorizaciones de comunicación junto a timeouts y recuperación. La geografía y el almacenamiento también pueden cambiar performance; una VM equivalente en especificaciones no prueba comportamiento equivalente bajo el tráfico real.
Identidad de workloads, administración humana, permisos entre servicios, secretos y accesos entre cuentas pasan a ser dependencias importantes. El alcance de cada identidad necesita corresponder a su responsabilidad. Que la conectividad funcione no demuestra que un job pueda acceder a sus datos ni que deba conservar todos los permisos antiguos.
Dependencias y portabilidad
dependency-structure hace visibles APIs de proveedor, IAM, red, control planes, deployment y semántica de servicios gestionados. Delegar mantenimiento puede reducir infraestructura propia y aumentar dependencia de plataforma. Esa combinación necesita evaluación, sin presentar acoplamiento como un juicio moral binario.
portability tiene varias dimensiones: código, runtime, datos, definiciones de deployment, identidad, networking y herramientas operacionales. Conservar lenguaje o usar containers no hace transferibles permisos, garantías de un broker o convenciones de recuperación. Evaluar un traslado concreto ofrece más evidencia que declarar simplemente «sin lock-in».
data-migration puede participar al mover información hacia un servicio gestionado. Pero rehostear un web tier conservando una base remota existente puede cambiar entorno sin mover esos datos. A la inversa, una migración de datos entre stores on-premises no necesita cloud.
Ejecución, capacidad y aislamiento
deployment puede cambiar artifacts y mecanismos de instalación, sin demostrar deployability independiente. Una nueva unidad entregable puede seguir necesitando schema o consumidores coordinados. execution-model puede conservarse en un rehost o cambiar con activación, lifecycle, concurrencia y persistencia de un runtime gestionado.
scaling examina capacidad efectiva. Cloud ofrece mecanismos de provisión, pero no elimina locks, contención, serialización, cuotas ni límites de una API externa. Agregar instancias puede desplazar el cuello de botella o amplificar carga downstream.
isolation necesita un efecto concreto que contener: fallo, acceso o recursos. Cuentas, subscriptions, proyectos, redes, zonas y regiones tienen propiedades distintas según proveedor; no forman una jerarquía universal. Usar redundancia gestionada no garantiza disponibilidad de la aplicación completa ni recuperación de sus datos.
tenancy distingue sharing entre clientes del proveedor de la arquitectura de tenants del producto. El aislamiento de infraestructura no decide qué tenants comparten estado, credenciales o ciclo de actualización en Commerce.
Operación y economía durante el cambio
La responsabilidad compartida cambia según el modelo de servicio: algunas capas quedan a cargo del proveedor, mientras datos, configuración y usos siguen requiriendo decisiones del cliente. Microsoft, Shared responsibility in the cloud. Gestionado no significa ausencia de operaciones.
operability necesita diagnóstico, recuperación y responsables para cuotas, configuración, permisos y comportamiento distribuido. Logs, métricas y trazas pueden ganar capacidades y perder acceso a detalles del host. No hay mejora universal de observabilidad: deben poder reconstruirse los fallos importantes bajo el modelo nuevo.
cost-efficiency considera consumo, capacidad comprometida, servicios gestionados, transferencia de red, storage, logs, soporte e inactividad, además de ingeniería y coexistencia. Separar costo fijo y sensible al uso ayuda a explicar comportamiento; reducir contabilidad a «CapEx pasa a OpEx» no reemplaza ese análisis.
Cloud puede resultar más o menos conveniente según carga, contratos, horizonte y operación. Los costos transitorios pueden subir aunque el destino previsto sea eficiente. Una copia o logging temporal necesita también límite, responsable y retiro.
Commerce: una transición posible
Antes del traslado conviene acordar una baseline con la mezcla real de requests, datos y fallos relevantes. Después contrastar resultados bajo condiciones comparables: cuánto tarda una autorización completa, qué ocurre al perder conectividad híbrida y si los jobs siguen autenticándose cuando se renuevan sus credenciales. Es un ejemplo de evidencia del Atlas, no un benchmark universal de proveedores.
La validación debe incluir procedimientos que ahora dependen de otras capas. Poder crear una VM no demuestra recuperar una capacidad ni obtener diagnóstico suficiente durante un incidente. Si el destino limita conexiones o acceso al host, soporte necesita conocer cómo identificar y tratar esos límites dentro del servicio elegido.
También hay que distinguir el costo transitorio del costo esperado de operación estable. Apagar recursos de prueba demasiado pronto puede reducir opciones de recuperación; mantenerlos indefinidamente puede ocultar consumo sin uso. Responsable, motivo y condición de revisión permiten evaluar ese compromiso junto a los datos que ya no sean reversibles.
Esta es una síntesis del Atlas, no una estrategia obligatoria. Commerce opera on-premises con Orders, Payments, Inventory y Shipping. Una salida de datacenter motiva establecer conectividad, identidad y diagnóstico antes de trasladar el web tier compatible; Payments mantiene su base local durante un período explícito.
Después pueden moverse ciertos workers y evaluarse servicios gestionados donde exista un driver. Las llamadas a Payments cruzan ahora otra red: medir latencia y resultados completos importa más que comprobar que el frontend arranca. Si se traslada su base a un servicio relacional gestionado, se combinan Cloud Migration, Data Migration y posiblemente replatforming según el framework utilizado.
Un estado híbrido puede ser temporal o un destino deliberado por hardware, latencia o regulación. No demuestra una migración fallida. Cada vínculo que permanezca necesita operación y costo comprendidos.
Contingencia y finalización
strangler-fig puede ayudar a desplazar ciertos flujos; otros workloads pueden necesitar un cutover coordinado. Volver a dirigir tráfico no revierte automáticamente nuevas escrituras ni efectos. migration-strategy conserva contingencias según el estado alcanzado.
El cierre debe contrastar el alcance acordado: cargas trasladadas, retenidas o retiradas; autoridad de datos; destino de infraestructura anterior; soporte transferido; observación y costo aceptados. «VM iniciada» no basta. fitness-functions puede aportar evidencia de latencia, contratos, dependencias o consumo, sin ejecutar automáticamente la transición.
El cambio incremental puede apoyar evolutionary-architecture, pero Cloud Migration no equivale al enfoque. evolution-and-modernization conecta entorno, información, mecanismos y estrategia sin convertir una opción de plataforma en garantía de modernización.