Cloud Modernization and Migration Strategies

Resumen

Migrar y modernizar son dos decisiones distintas que se confunden con frecuencia en las conversaciones de dirección, y de esa confusión nacen programas que entregan una factura nueva sin entregar un negocio distinto. La migración cambia dónde se ejecuta el software: lo traslada desde el datacenter propio, desde una infraestructura dedicada o desde otra nube hacia una plataforma cloud. La modernización cambia cómo se construye y cómo se opera ese software: elimina configuración manual, introduce infraestructura como código, separa componentes, adopta contenedores y servicios gestionados y reduce el acoplamiento que hace caro cada cambio futuro. Un programa maduro hace las dos cosas, pero con ritmos, métricas y expectativas diferentes para cada una.

Este tema del dominio de infrastructure modernization establece por qué esos dos pasos son importantes en una transformación digital, qué beneficios concretos aporta modernizar la infraestructura y qué beneficios distintos aporta modernizar las aplicaciones, y después fija el vocabulario que la guía del examen espera con exactitud: workload, retire, retain, rehost (lift and shift), replatform, move and improve, refactor y reimagine. Cada una de esas rutas tiene un esfuerzo, un riesgo, una ventana temporal y un tipo de valor distinto, y la habilidad que se evalúa no es repetir la lista, sino justificar la ruta correcta para una carga concreta con un criterio técnico, uno operativo y uno de negocio.

También se trata aquí el punto que más programas hace estancarse: la modernización no es un estado al que se llega al final de la migración, es una secuencia de olas (waves) en las que cada carga recibe la intervención que su negocio justifica, ni más ni menos. Llevar todo a la ruta más avanzada consume el presupuesto sin repartir valor; llevar todo a la ruta más barata consolida la deuda técnica dentro de la nube. El arte del Digital Leader consiste en asignar cada carga a su ruta y en defender con indicadores qué cambió para el negocio en cada wave.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Explicar por qué la modernización y la migración son pasos importantes de una transformación digital, y diferenciar qué problema resuelve cada una.
Argumentar los beneficios de negocio de la modernización de infraestructura: menos operación manual, mayor resiliencia, escalado elástico, coste variable por consumo y despliegue reproducible.
Argumentar los beneficios de negocio de la modernización de aplicaciones: time-to-market, escalado granular, mayor disponibilidad, menor coste por transacción y menor riesgo en cada release.
Definir con precisión qué es un workload como unidad de análisis de un programa de migración.
Distinguir las decisiones de portafolio retire y retain de las rutas de movimiento, e indicar cuándo corresponde cada una.
Describir rehost (lift and shift) y señalar su valor real y sus límites.
Comparar replatform y move and improve como rutas intermedias que ganan operación gestionada sin reescribir el código.
Explicar qué implica refactor y qué implica reimagine en términos de esfuerzo, riesgo y horizonte de valor.
Asignar cada ruta a una carga concreta combinando compatibilidad técnica, ventana de parada, habilidades del equipo, coste operativo resultante y valor esperado.
Distinguir los indicadores que miden el éxito de una migración de los que miden el éxito de una modernización.

Contenido Principal

Subtema 1: Por qué migrar y modernizar son pasos importantes

Una organización puede estar en la nube y seguir operando como si estuviera en su datacenter: las mismas máquinas, los mismos scripts, los mismos calendarios de parcheo, la misma esperas de semanas para atender un pico. Ese estado —cloud-hosted pero no modernizado— es el resultado previsible de tratar la migración como un proyecto de infraestructura. La migración por sí sola traslada el software a otra ubicación; si no se acompaña de modernización, traslada también la deuda técnica, el acoplamiento y el coste operativo heredado, y se paga el programa sin cosechar el beneficio que lo justificaba.

El argumento de negocio de tratar migración y modernización como pasos importantes se sostiene en cuatro razones. Primera: la nube solo entrega sus beneficios cuando la carga puede aprovecharlos —la elasticidad no hace nada por una aplicación que no escala ni se recupera sola—, y aprovecharlos requiere cambios en la aplicación y en su forma de desplegarse. Segunda: el coste de cambiar de arquitectura crece con el tiempo, porque cada mes en la configuración anterior se añade dependencia nueva; mover primero y reescribir después suele ser más caro que decidir la ruta correcta en el assessment. Tercera: la velocidad de respuesta del negocio depende de la capacidad de desplegar cambios frecuentes y pequeños, y esa capacidad no se compra con servidores: se diseña. Cuarta: los riesgos de no actuar —obsolescencia, coste de oportunidad, escasez de talento especializado en plataformas envejecidas— se acumulan de forma silenciosa mientras el programa discute el alcance.

La distinción operativa que conviene fijar es esta: la migración se mide con métricas de movimiento (cuántas cargas, cuánto tiempo de inactividad, cuánto riesgo en el corte), mientras que la modernización se mide con métricas de resultado (lead time de despliegue, disponibilidad, coste por transacción, número de incidentes operativos). Un programa que solo reporta el primer conjunto puede estar al 100% de cumplimiento y al 0% de transformación. Ambos conjuntos son necesarios: sin movimiento no hay plataforma donde innovar, y sin modernización no hay cambio de resultados.

Pregunta de negocio	Migración	Modernización	Sin ninguno de los dos
¿Dónde se ejecuta el software?	Se traslada a la nube	Se rediseña para la nube	Sigue en el datacenter
¿Qué se elimina?	Coste y riesgo de hardware propio	Configuración manual, acoplamiento, operación repetitiva	Nada
Métrica principal de éxito	Cargas movidas, ventana de corte, riesgo	Lead time, disponibilidad, coste por transacción	Coste de infraestructura por unidad de tiempo
Valor para el negocio	Resiliencia, salida del datacenter, coste variable	Velocidad, escalado granular, menor coste de cambio	Capacidad estática comprada upfront
Riesgo dominante	Deuda técnica consolidada en la nube	Alcance infinito si no se prioriza por valor	Obsolescencia y pérdida de agilidad

Subtema 2: Beneficios de la modernización de infraestructura

La modernización de infraestructura atiende al entorno en el que corre el software: servidores, imágenes, redes, discos, configuración de alta disponibilidad, políticas de parcheo y mecanismos de despliegue. Su promesa de negocio es reducir el trabajo operativo manual y convertir la infraestructura en algo reproducible, versionado y automático, de modo que el coste de mantener un entorno deje de crecer en línea con el número de componentes.

Los beneficios se materializan en formas concretas. Infraestructura como código y plantillas reproducibles: un entorno completo se describe en un archivo versionado (Terraform o Configuration Manager de Google Cloud), de modo que un entorno de pruebas se crea igual que el de producción y la diferencia entre ambos deja de ser una causa de incidentes. Automatización de parches y de imágenes base: imágenes gestionadas y políticas de actualización programada sustituyen al trabajo manual de fin de semana, y el equipo recupera horas que antes consumía el mantenimiento correctivo. Resiliencia por diseño: multi-zona, replicación, balanceo de carga y grupos de instancias gestionadas convierten un fallo de hardware en un evento que la plataforma absorbe sin intervención. Escalado automático: la capacidad sigue a la demanda en lugar de a la última previsión de compra, lo que elimina el coste de capacidad ociosa y el riesgo de no atender un pico. Coste variable y atribuible: cada recurso se apaga, se redimensiona o se etiqueta, y el gasto se asigna a un producto o centro de coste. Observabilidad y seguridad gestionadas: logs, métricas, alertas y controles de red pasan a ser servicios de la plataforma y no software propio que hay que mantener.

El orden importa para el negocio: casi todos estos beneficios son verificables antes de tocar una línea de aplicación, y por eso la modernización de infraestructura suele ser la primera wave de un programa. También es la que produce el ahorro más visible —recursos apagados, discos eliminados, máquinas redimensionadas—, y ese ahorro es lo que financia las waves siguientes, que son las más caras.

Beneficio	Manifestación técnica	Indicador de negocio
Entornos reproducibles	Infraestructura como código, plantillas, imágenes gestionadas	Tiempo de creación de un entorno completo
Menos operación manual	Parcheo automatizado, políticas, despliegues programados	Horas hombre de operación por mes
Resiliencia	Multi-zona, grupos de instancias gestionadas, balanceo	Disponibilidad, tiempo de recuperación ante fallo
Escalado elástico	Autoscaling por métrica de carga	Picos atendidos sin aprovisionamiento previo
Coste variable atribuible	Etiquetas, apagado programado, dimensionado	Coste por producto y capacidad ociosa
Seguridad y observabilidad	Logs, métricas, firewalls gestionados, revisión continua	Hallazgos abiertos y tiempo de detección

La secuencia de trabajo habitual dentro de esta modernización tiene un orden que refleja el riesgo y el retorno de cada paso. Primero se inventarían los recursos y se les asigna un dueño, porque sin dueño no hay decisión posible. Después se eliminan los restos —discos sin instancia, máquinas apagadas que siguen reservadas, direcciones IP huérfanas—, que es el ahorro más rápido y el menos discutible. A continuación se estandarizan imágenes base y plantillas, de modo que la configuración que se cree a partir de ese momento sea reproducible. En paralelo se activan los controles de escalado y de alta disponibilidad sobre las cargas que ya están en la nube. Y solo al final se rediseñan los flujos de despliegue y de actualización, que son los que cambian la práctica del equipo y no solo la configuración del entorno.

Las señales de que una infraestructura no está modernizada suelen aparecer en la revisión de inventario antes que en cualquier informe de arquitectura:

Despliegues que requieren acceso manual a la máquina, con ejecución de scripts y ventanas de cambio fijadas en el calendario.
Imágenes personalizadas sin familia mantenida, creadas una a una y distintas entre desarrollo y producción.
Falto de etiquetado consistente, con lo que el gasto no se puede atribuir a un producto ni a un responsable.
Alta disponibilidad ausente o declarada pero sin prueba de recuperación documentada.
Escalado negociado por anticipado con compras, en lugar de automático y ligado a una métrica de carga.

Ejemplo Práctico

Un caso típico de modernización de infraestructura empieza con evidencia de inventario, no con una decisión de arquitectura. Este bloque de comandos permite dimensionar qué hay que modernizar y cuánto cuesta mantenerlo tal como está:

gcloud compute instances list \
  --format="table(name, zone, machineType, status, creationTimestamp)"
gcloud compute disks list \
  --format="table(name, sizeGb, status, users)"
gcloud asset search-all-resources \
  --scope=projects/PROJECT_ID \
  --format="table(assetType, name, location)"

La primera tabla muestra el inventario de máquinas y su estado: instancias RUNNING creadas hace años con tipos de máquina grandes y sin etiqueta de propietario son candidatas a redimensionado o a apagado en horario no laboral. La segunda expone un hallazgo frecuente y rentable: discos READY sin campo en users, es decir, almacenamiento que se está pagando y que ninguna instancia usa; esa partida se corrige sin tocar la aplicación y suele aparecer tras cada prueba o migración parcial. El tercero entrega el mapa completo de recursos por tipo y ubicación, la base con la que se define el alcance de la primera wave y se atribuye el gasto.

Para dimensionar la automatización pendiente, el siguiente paso es comprobar qué imágenes base se usan y si reciben soporte:

gcloud compute images list \
  --filter="status=READY" \
  --format="table(name, family, deprecated.state, diskSizeGb)"

Las imágenes marcadas como obsoletas son la señal de que un plan de rehost arrancaría sobre una base sin parches: modernizar infraestructura empieza por actualizar la imagen base, no por copiar la antigua. La lectura de negocio es directa: cada imagen obsoleta en producción es una ventana de seguridad abierta y un coste de remediación futuro que se puede evitar migrando con la imagen actual.

Subtema 3: Beneficios de la modernización de aplicaciones

La modernización de aplicaciones cambia la estructura del software: cómo se divide, cómo se despliega, cómo escala y cómo se comunica con el resto de los sistemas. Es una inversión más profunda y más lenta que la de infraestructura, y su valor no aparece en la factura de la nube, sino en la velocidad con la que el negocio puede cambiar.

Los beneficios principales, en el orden en que suelen defenderse ante un comité: time-to-market, porque un componente pequeño se despliega por separado, con pruebas propias y sin ventanas de cambio compartidas; escalado granular, porque cada componente escala según su propia carga —el catálogo aguanta el pico de campaña sin que el módulo de informes pague por él—; resiliencia, porque el fallo de un componente no cae entero la aplicación si los límites entre ellos están bien definidos y los timeouts están bien puestos; menor coste de cambio, porque la proba se automatiza y el despliegue es repetible, lo que reduce el coste de cada release y el miedo a desplegar; mejor aprovechamiento de la plataforma, porque una aplicación stateless que expone HTTP puede correr sobre Cloud Run o GKE y beneficiarse del escalado a cero y del balanceo gestionado; y atractivo para el talento, porque los equipos quieren trabajar con arquitecturas y herramientas actuales, no con monolitos que solo una persona entiende.

Conviene subrayar la diferencia de horizonte frente a la modernización de infraestructura. Infraestructura rinde en meses y se demuestra con coste y disponibilidad; aplicaciones rinden en trimestres y se demuestra con lead time, frecuencia de despliegue y coste por transacción. Un programa que promete agilidad en el primer trimestre mediante rehost está prometiendo lo que su ruta no puede entregar, y esa incompatibilidad debería detectarse en el assessment.

Cambio en la aplicación	Qué desbloquea técnicamente	Resultado de negocio
De monolito a componentes desacoplados	Despliegue independiente por componente	Releases frecuentes sin ventana de cambio global
De estado en el servidor a stateless	Autoscaling horizontal y balanceo	Picos atendidos sin sobreaprovisionar
De binarios propios a contenedores	Imagen única entre desarrollo y producción	Menos diferencias entre entornos, despliegues rápidos
De integración por acoplamiento a APIs	Contratos versionados entre equipos y terceros	Nuevos canales y socios sin reescribir el núcleo
De ejecución fija a serverless	Escalado a cero y pago por invocación	Coste alineado al uso real de la función

También conviene delimitar lo que no es modernización de aplicaciones, porque el exceso de alcance es la causa más frecuente de fracaso de estas iniciativas. Mover el monolito a un clúster de contenedores sin cambiar su estructura es un rehost con imagen de contenedor; el despliegue continúa siendo global, el escalado continúa siendo del conjunto y la ventaja se reduce a la portabilidad del artefacto. Sustituir el servidor de aplicaciones por un servicio gestionado sin externalizar la configuración ni el estado solo cambia el proveedor del mismo problema. Y trocear el monolito en microservicios que se despliegan a la vez, en la misma versión y con la misma base de datos, produce la complejidad de la arquitectura sin la agilidad que la justificaba: se ha copiado la topología de red pero no el modelo de operación. La modernización de aplicaciones se reconoce porque cambia el ciclo de entrega y la forma de escalar, no porque haya más componentes en el diagrama.

Temas relacionados: Estrategia de migración de negocio, Cómputo, contenedores y serverless en Google Cloud, Modelos de nube y responsabilidad compartida.

Subtema 4: Vocabulario de migración: workload, retire, retain y las rutas de movimiento

El vocabulario de la guía del examen tiene un significado exacto, y usarlo mal cambia el sentido de una recomendación. El punto de partida es el workload: una carga de trabajo es la unidad de análisis del programa, es decir, un conjunto de componentes que juntos entregan una capacidad de negocio —el motor de precios, el canal de cobro, el servicio de facturación—, con su aplicación, sus datos, su infraestructura y sus dependencias. Un workload se evalúa completo; migrar la aplicación sin su base de datos o sin su integración de colas no es una migración, es dejar un sistema partido.

Antes de decidir cómo se mueve algo, se decide qué ocurre con cada carga. Retire significa que el workload se retira: se elimina porque ya no tiene uso, porque ha sido sustituido por un producto de mercado o porque su coste de mantenimiento supera el valor que aporta. Es una decisión de portafolio con valor real —cada carga retirada es gasto y riesgo que desaparecen—, y la costumbre de descartarla porque "no es innovación" mantiene en producción sistemas que nadie usaría si fueran nuevos. Retain significa que el workload se queda donde está, sin moverse: se justifica por una restricción real (residencia de datos, dependencia de hardware específico, ventana de cambio bloqueada, contrato todavía vigente) o por una decisión explícita de que migrar no aporta valor. Retain es legítimo como decisión documentada y temporalmente acotada; deja de serlo cuando se convierte en la categoría donde cae todo lo que nadie ha querido analizar.

Las rutas de movimiento, de menor a mayor esfuerzo:

Rehost (lift and shift): la carga se traslada tal cual, con el mismo sistema operativo, la misma configuración y la misma forma de funcionar, normalmente a Compute Engine como máquina virtual. Es la ruta más rápida de salida del datacenter y la única viable cuando la aplicación depende de un kernel, de un middleware propietario o de un sistema de ficheros concreto. Su valor es real pero acotado: elimina el coste y el riesgo de hardware y aporta resiliencia de plataforma; no aporta agilidad, ni escalado elástico, ni menor coste unitario, y mantiene íntegro el coste de parcheo y de operación.
Replatform: la carga se traslada y cambia de plataforma gestionada sin reescribir la lógica de negocio —por ejemplo, de una base de datos instalada a Cloud SQL, o de un servidor de aplicaciones propio a un servicio gestionado—. Gana alta disponibilidad, backups automáticos y administración del motor por parte del proveedor, con un esfuerzo de migración controlado.
Move and improve: es un rehost con mejoras de operación aplicadas en el camino, sin tocar el código: plantillas de instancia, grupos de instancias con autoscaling, balanceo de carga, health checks, discos SSD y etiquetado para la atribución de costes. Es el movimiento típico de la primera wave porque gana elasticidad y gobernanza con poco riesgo.
Refactor: se cambia el código para aprovechar la plataforma —descomponer en componentes, externalizar configuración, hacer la aplicación stateless, moverla a contenedores o a Cloud Run—. Requiere equipo de desarrollo, pruebas y un calendario propio; es la única ruta que entrega time-to-market y escalado granular, y por eso su valor grande llega tarde.
Reimagine: se rediseña el servicio, no la aplicación. No se conserva la funcionalidad existente como base, sino que se define de nuevo la capacidad de negocio que se quiere ofrecer —un portal nuevo, un modelo de autoservicio, una integración con socios— apoyándose en la nube como posibilidad, no como destino. Es la ruta de mayor valor potencial y de mayor incertidumbre, y conviene separarla del programa de migración para que su alcance no arrastre al resto.

Término	Significado exacto	Qué se conserva	Qué cambia	Valor esperado
Workload	Unidad de análisis: app + datos + infraestructura + dependencias	Todo el conjunto funcional	Nada, es la unidad de planificación	Alcance y coste medibles
Retire	La carga se elimina	Nada	La capacidad desaparece o se sustituye	Gasto y riesgo eliminados
Retain	La carga se queda donde está	Todo, sin mover	La ubicación	Evita un coste sin retorno
Rehost (lift and shift)	Traslado sin cambios de código ni de plataforma lógica	Sistema operativo, configuración, arquitectura	Ubicación física y responsable del hardware	Salida rápida del datacenter, resiliencia
Replatform	Traslado a un servicio gestionado equivalente	Lógica de negocio y modelo de datos	Plataforma de ejecución o de datos	Menos operación, alta disponibilidad
Move and improve	Rehost más mejoras operativas	Código	Ubicación, plantillas, escalado, red	Elasticidad y atribución de coste
Refactor	Reescritura para aprovechar la plataforma	Requisitos funcionales	Arquitectura y forma de despliegue	Time-to-market, escalado granular
Reimagine	Rediseño del servicio de negocio	Intención de negocio	Producto, experiencia y arquitectura	Nuevos ingresos o canales

Subtema 5: Cómo se elige la ruta y en qué orden se ejecuta

Elegir ruta es una decisión que combina cinco criterios, y ninguna decisión defensible se apoya en uno solo. Compatibilidad técnica: dependencias de hardware, de sistema operativo o de middleware propietario empujan hacia rehost; una aplicación stateless que expone HTTP es candidata a refactor. Ventana de parada admisible: hay cargas que toleran minutos y cargas que no toleran segundos, y la ventana determina el método de corte, no la ruta. Habilidades disponibles: una ruta que exige competencias que la organización no tiene ni puede contratar en el horizonte del programa se convierte en rehost de hecho por presión de calendario. Coste operativo resultante: rehost mantiene el parcheo y la monitorización dentro del equipo; replatform y refactor los desplazan al proveedor, y esa diferencia es una partida de TCO concreta. Valor esperado: qué cambia para el negocio si esta carga se moderniza —llegar a un SLA, habilitar un canal, reducir el coste de una transacción—.

El segundo eje de la decisión es el orden. Un programa de migración y modernización se ejecuta en waves, y el criterio de priorización habitual es combinar valor con reversibilidad: una wave temprana de cargas estables y de bajo riesgo genera ahorro y experiencia, y ese ahorro financia las waves siguientes, que son las que atacan las cargas complejas. Empezar por la carga más compleja pone el programa completo en un solo punto de fallo; empezar por la más sencilla y quedarse ahí produce una migración barata sin transformación. La secuencia sana usa rehost como opción de reversibilidad —da un activo movible y una línea base de coste— y no como destino final: una rehost que sigue en rehost cinco años después no es un éxito del programa, es la señal de que el programa terminó en la fase de ejecución.

Un error habitual de decisión es asignar rutas por esfuerzo en lugar de por valor: rehost para todo porque es rápido, y luego ninguna oportunidad de mejorar porque "la migración ya está hecha". El enfoque inverso —refactor para todo— fracasa por alcance y por calendario. La práctica consiste en aceptar que el portafolio es mixto, en declarar qué carga recibe qué ruta y en asignar a cada ruta los indicadores que le corresponden: coste y disponibilidad para rehost y move and improve, lead time y coste por transacción para refactor, ingresos o canales nuevos para reimagine.

Cada wave que llega a un comité debería poder describirse en una sola página: cargas incluidas con su ruta asignada, dueño de negocio de cada una, criterio de éxito con su línea base, ventana de corte y criterio de reversión, y fecha del primer resultado verificable. Cuando ese formato no es posible —porque la ruta de alguna carga es "se verá sobre la marcha"—, la wave no está planificada: está siendo un experimento con presupuesto de programa. Del mismo modo, la revisión posterior a cada wave no debería limitarse a confirmar que los recursos se movieron, sino a contrastar la línea base con el resultado medido y a corregir la ruta de las cargas pendientes si lo aprendido cambia la prioridad. Ese bucle de revisión es lo que convierte una sucesión de migraciones en un programa de modernización.

Las habilidades son el cuarto freno que conviene gestionar de forma explícita. Rutas como replatform sobre servicios gestionados o refactor hacia contenedores exigen competencias que un equipo de operaciones tradicional no tiene por sí solo; la respuesta no es cambiar toda la ruta por falta de talento, sino planificar la capacitación, incorporar perfiles con experiencia en la primera wave piloto o apoyarse en partners de migración mientras el equipo interno se forma sobre cargas de riesgo controlado. Lo que no funciona es descubrir la brecha de habilidades durante el corte de la carga más crítica.

Para defender la decisión ante un comité, el orden de evidencia es: inventario de cargas con su ruta propuesta, línea base medida antes de mover (coste, disponibilidad, lead time), criterio de éxito por wave y fecha en que se espera el primer resultado verificable. Esa presentación evita las dos trampas más frecuentes: prometer todos los beneficios con una sola métrica, y reportar como avance el número de cargas movidas cuando el negocio pregunta qué ha cambiado.

Ejemplo Práctico

La selección de candidatas a cada ruta empieza por leer el estado real de las cargas candidatas, y la primera separación se hace entre lo que se puede mover con mejoras y lo que exige reescritura:

gcloud container clusters list \
  --format="table(name, location, status, currentNodeCount)"
gcloud run services list --region=us-central1 \
  --format="table(metadata.name, status.url, status.latestReadyRevisionName)"
gcloud compute instances list --filter="labels.workload!=''" \
  --format="table(name, zone, machineType, labels)"

Presencia de servicios en Cloud Run con revisiones sucesivas indica que el componente ya está modernizado y que el siguiente paso es de aplicación, no de infraestructura; instancias con etiqueta de workload sin servicio equivalente son candidatas naturales a move and improve, porque tienen dueño identificable y por tanto se les puede atribuir coste y medir su línea base. La ausencia de etiquetas es, en sí misma, un hallazgo: sin dueño no hay atribución de gasto, y cualquier ahorro que se prometa después será una afirmación sin base.

Para decidir entre rehost y replatform en la base de datos de una carga, la lectura relevante es la configuración actual de la instancia y su modo de alta disponibilidad:

gcloud sql instances list \
  --format="table(name, databaseVersion, settings.availabilityType, settings.tier)"

Un valor de ZONAL señala una decisión de coste heredada del datacenter: la base de datos no sobrevive a un fallo de zona. Ese hallazgo no requiere reescribir la aplicación y convierte la migración en replatform con alta disponibilidad activada, es decir, en un salto de valor alto y de riesgo controlado. El tier comparado con la CPU realmente consumida revela sobreaprovisionamiento, que es el tipo de ahorro que financia la wave sin tocar una línea de código.

Por último, conviene fijar la línea base de coste antes de mover, porque sin ella la comparación después de la migración no prueba nada:

gcloud billing accounts list
gcloud compute instances list --format="table(name, machineType, status)" | wc -l

El primer comando identifica la cuenta de facturación sobre la que se atribuirá el gasto antes y después; el segundo da el denominador de movimientos por wave. Con ambas cifras y la fecha de corte de cada carga, la revisión de un comité deja de ser una opinión sobre la migración y pasa a ser una comparación de dos líneas base.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Workload	Unidad de planificación de la migración: aplicación, datos, infraestructura y dependencias	Para definir alcance, coste y responsables de cada movimiento
Retire	Decisión de eliminar una carga que ya no aporta valor o ha sido sustituida	En la revisión de portafolio, antes de presupuestar su migración
Retain	Decisión de mantener una carga en su ubicación actual	Con restricción documentada y revisión temporal definida
Rehost	Traslado sin cambios de código (lift and shift), normalmente a Compute Engine	Salidas urgentes del datacenter y cargas con dependencias propietarias
Replatform	Traslado a un servicio gestionado equivalente conservando la lógica	Cuando el cuello de botella es la operación de la plataforma
Move and improve	Rehost con mejoras de plantillas, escalado y balanceo	Primera wave, para ganar elasticidad sin riesgo de código
Refactor	Reescritura de la arquitectura para aprovechar la plataforma	Sobre cargas que bloquean un resultado de negocio concreto
Reimagine	Rediseño del servicio de negocio apoyándose en la nube	Cuando la oportunidad no es mejorar la app, sino reinventar el servicio
Wave	Fase de ejecución que agrupa cargas por prioridad y riesgo	Para repartir valor, financiar fases siguientes y limitar el alcance
Línea base	Medición de coste, disponibilidad y lead time antes de mover	Obligatoria para demostrar el resultado de cada wave
Deuda técnica	Coste futuro acumulado por decisiones de diseño pospuestas	Como riesgo explícito al comparar rehost con refactor
Modernización	Cambio de cómo se construye y se opera el software	Distinguiéndola siempre de la mera migración

Comparaciones

Dimensión	Migrar sin modernizar	Modernizar infraestructura	Modernizar aplicaciones
Qué cambia	Ubicación del software	Entorno de ejecución y operación	Estructura y despliegue del software
Ruta habitual	Rehost	Move and improve, replatform	Refactor, reimagine
Esfuerzo	Bajo	Medio	Alto
Horizonte de resultado	Inmediato	Meses	Trimestres
Métrica de éxito	Cargas movidas, ventana de corte	Coste, disponibilidad, horas de operación	Lead time, coste por transacción, frecuencia de despliegue
Beneficio de negocio	Salida del datacenter, resiliencia	Menos operación, escalado elástico	Velocidad de cambio, nuevos canales
Riesgo dominante	Deuda técnica en la nube	Cambio de procesos y herramientas del equipo	Alcance, dependencia de habilidades escasas

Dimensión	Retire / Retain	Rehost / Move and improve	Replatform / Refactor / Reimagine
Se mueve la carga	No	Sí, conservando la lógica	Sí, con cambios de plataforma o de producto
Esfuerzo de equipo	De análisis, no de ejecución	Operativo	Operativo y de desarrollo
Aporta agilidad	No	Solo con move and improve	Sí
Aporta ahorro	Retire sí; retain no	Coste de hardware y, en move and improve, ociosidad	Coste operativo y coste por transacción
Justificación típica	Falta de uso, contrato, restricción real	Compatibilidad técnica o presión de calendario	Bloqueo de un resultado de negocio

Errores Comunes

Error: Usar migración y modernización como sinónimos y presentar un rehost como un proyecto de transformación digital. → Solución: Declarar explícitamente qué se consigue con cada una y con qué métrica se demuestra; el rehost se defiende con coste y disponibilidad, la modernización con lead time y coste por transacción. Si el caso de negocio promete agilidad, la ruta asignada debe incluir move and improve o refactor.
Error: Tratar lift and shift como el destino final de la carga y no como una opción de transición. → Solución: Fijar en el assessment qué carga queda temporalmente en rehost y qué condición la saca de ahí; sin ese compromiso, la deuda técnica se consolida dentro de la nube y el coste de reescribir después crece con cada dependencia nueva.
Error: Usar retain como categoría permanente para cargas que nadie ha analizado. → Solución: Exigir para cada retain una restricción documentada —residencia de datos, hardware específico, contrato vigente— y una fecha de revisión; los cargas sin restricción identificada entran en el portafolio de movimiento o en retire.
Error: Priorizar las waves por facilidad técnica y dejar siempre el valor de negocio para después. → Solución: Ordenar cada wave por valor esperado y reversibilidad combinados, y programar al menos una carga visible para el negocio en las primeras fases; sin un resultado temprano verificable, el programa pierde patrocinio antes de llegar a las cargas complejas.
Error: Medir el avance solo con el recuento de cargas migradas. → Solución: Complementar siempre el recuento con la línea base de coste, disponibilidad y lead time tomada antes del movimiento, y reportar por wave qué cambió para el negocio, no solo cuánto se movió.

Puntos para el Examen

🎯 Punto clave 1: Migrar y modernizar son pasos distintos y ambos importan. La migración cambia dónde corre el software y se demuestra con coste y resiliencia; la modernización cambia cómo se construye y opera y se demuestra con velocidad de cambio, escalado y coste por transacción. Las preguntas de escenario suelen presentar una aplicación heredada que se quiere mover a Cloud Run y esperan la respuesta "modernización de aplicaciones", no "rehost".

🎯 Punto clave 2: El vocabulario tiene un significado exacto: workload es la unidad de análisis; retire elimina la carga; retain la deja donde está; rehost (lift and shift) la traslada sin cambiar código; replatform la traslada a una plataforma gestionada; move and improve la traslada con mejoras operativas; refactor cambia el código; reimagine rediseña el servicio de negocio.

🎯 Punto clave 3: Cada ruta tiene un coste, un riesgo y un horizonte de valor distintos: rehost entrega ahorro de hardware rápido pero no agilidad; refactor entrega agilidad y escalado pero tarde y con más riesgo; las rutas intermedias concentran el mejor equilibrio para la mayoría del portafolio. La pregunta tipo es "qué ruta recomienda y por qué", y la respuesta esperada combina criterio técnico, operativo y de valor de negocio.

🎯 Punto clave 4: Los beneficios de la modernización de infraestructura (entornos reproducibles, menos operación manual, resiliencia, escalado, coste atribuible) son verificables sin tocar la aplicación y suelen financiar las waves siguientes. Los de la modernización de aplicaciones (time-to-market, escalado granular, menor coste por transacción, mejor uso de la plataforma) requieren equipo de desarrollo y rinden en trimestres.

🎯 Punto clave 5: Retire y retain son decisiones de portafolio, no rutas de movimiento, y ambas aportan valor cuando están documentadas: retire elimina gasto y riesgo, retain evita un gasto sin retorno. Sin una restricción explícita y una fecha de revisión, retain se convierte en la forma elegante de no decidir.

Recursos Externos

Google Cloud Migration Center — Punto de entrada de la evaluación de carteras de aplicaciones, descubrimiento de cargas y planificación de migración.
Migrate to Virtual Machines: documentación del producto — Alcance del servicio de rehost, informes de evaluación y flujos de copia y corte.
Migration Center: documentación — Conceptos, fuentes de datos y pasos para descubrir y clasificar cargas antes de decidir su ruta.
Google Cloud Architecture Framework — Marco de referencia para evaluar workloads, operación, fiabilidad, seguridad y coste, y para conectar la ruta elegida con el resultado esperado.
Desplegar una aplicación en Google Kubernetes Engine — Documentación práctica de la ruta de modernización de aplicaciones sobre clústeres gestionados.

Autoevaluación Rápida

Pregunta: Un responsable de negocio afirma que "ya hemos migrado, así que ahora somos cloud-native". ¿Qué hay que corregir en esa afirmación? Respuesta: La afirmación confunde ubicación con arquitectura. Haber migrado (probablemente en rehost) significa que el software corre en la nube; ser cloud-native significa que está construido para aprovecharla —contenedores, componentes desacoplados, estado externo, despliegue automatizado y escalado por demanda—. Corregir implica separar los dos programas y sus métricas: coste y disponibilidad para la migración, lead time, frecuencia de despliegue y coste por transacción para la modernización.
Pregunta: ¿En qué se diferencian modernizar infraestructura y modernizar aplicaciones en beneficio de negocio y en horizonte? Respuesta: La modernización de infraestructura sustituye operación manual por plantillas versionadas, imágenes gestionadas, autoscaling y alta disponibilidad, y rinde en meses con métricas de coste, disponibilidad y horas de operación; no exige tocar la aplicación. La de aplicaciones cambia la estructura del software —componentes, stateless, contenedores, APIs— y rinde en trimestres con métricas de velocidad y de coste por transacción. La primera suele ir primero porque produce ahorro verificable que financia la segunda.
Pregunta: Una carga depende de un middleware propietario y de un sistema de ficheros concreto, y debe salir del datacenter en el trimestre. ¿Qué ruta corresponde y qué no prometer? Respuesta: Rehost (lift and shift), porque la compatibilidad técnica no admite replatform ni refactor en el plazo, y su ventana de corte es manejable con copia y corte. Lo que no se debe prometer es agilidad, escalado elástico ni menor coste unitario: el rehost elimina el coste y el riesgo de hardware y aporta resiliencia de plataforma, pero mantiene el parcheo, la monitorización y el acoplamiento dentro del equipo. El compromiso correcto es documentar la carga como candidata futura a move and improve o refactor con una condición de salida explícita.
Pregunta: Dos cargas tienen el mismo coste de infraestructura; una genera ingresos directos y la otra es interna y estable. ¿Cuál abre el programa y por qué? Respuesta: La carga con impacto de negocio directo, aunque su ruta sea más compleja, porque el primer resultado verificable sostiene el patrocinio del programa; la carga interna y estable entra en una wave temprana con move and improve si se quiere ahorro rápido, o en rehost si solo se necesita salida del datacenter. El criterio no es el coste de infraestructura —que es similar—, sino el valor desbloqueado y la reversibilidad de la decisión: el orden de las waves es una decisión de negocio, no de facilidad técnica.
Pregunta: Un portafolio tiene 40 cargas, de las cuales 12 no tienen dueño identificado ni uso registrado desde hace más de un año. ¿Qué decisiones corresponden y con qué precaución? Respuesta: Las cargas sin uso registrado son candidatas a retire tras validar con el negocio que nadie las consume, porque cada una es gasto y riesgo que se pueden eliminar; las que sí se usan pero tienen restricción documentada van a retain con fecha de revisión, y el resto entra en el portafolio de movimiento con una ruta asignada. La precaución es que retire y retain son decisiones que deben tomarse con evidencia de uso y de restricción: sin esa evidencia, retire elimina algo que alguien sigue necesitando y retain mantiene indefinidamente lo que nadie ha querido analizar.