Cloud Migration Business Strategy and Value Realization
Resumen
Migrar a Google Cloud no es un proyecto de tecnología: es una decisión de cartera de negocio con consecuencias durante años. Un Digital Leader tiene que ser capaz de explicar por qué se migra, en qué orden, qué cargas se tocan, cuáles se dejan atrás, qué valor se espera y cómo se demuestra que el valor llegó. Eso exige un vocabulario compartido, un método de fases y, sobre todo, la capacidad de traducir evidencia técnica en una conversación de comité de dirección.
El tema arranca con la distinción que más se malinterpreta en las reuniones de migración: modernizar la infraestructura no es lo mismo que modernizar las aplicaciones. Modernizar la infraestructura significa cambiar dónde y sobre qué se ejecuta el software sin alterar el código: mover una máquina virtual a Compute Engine, trabajar con discos y copias de seguridad gestionados, aprovechar la red global y la resiliencia por zonas. Modernizar aplicaciones es reescribir o re-encapsular el software para aprovechar servicios gestionados, escalado elástico y despliegue continuo. Ambas cosas tienen valor, pero valores distintos, con costes distintos y con riesgos distintos, y confundirlas es la causa más frecuente de programas de migración que se eternizan.
El segundo bloque construye el vocabulario de migración: qué es un workload, cuándo una carga se retira (retire), cuándo se conserva (retain), y qué significa cada una de las siete rutas —rehost, replatform, move and improve, refactor, reimagine—, más el caso particular de workloads que no se migran sino que se sustituyen por una alternativa de mercado. Cada ruta tiene un coste, un riesgo y un horizonte de valor distintos; saber elegir ruta es la habilidad operativa central del tema. A continuación se abordan los riesgos de no modernizar: deuda técnica acumulada, exposición de seguridad, imposibilidad de escalar, coste estructural, pérdida de talento y oportunidades de negocio que se pierden por no poder cambiar. Un programa de migración no se defiende con el ahorro en licencias, sino con esa lista de riesgos.
El bloque central es el método por fases: assessment y construcción del portafolio de aplicaciones, planificación por olas (wave planning), ejecución, validación y optimización continua. Cada fase tiene una entrada, un entregable y una decisión de salida, y es un error clásico saltarse la primera porque es la única que cuesta poco y evita las demás. El cierre del tema conecta todo con la realización de valor (value realization): los indicadores que convierten una migración en un negocio mejor, la relación entre la ruta elegida y el valor esperado, el coste de oportunidad de un programa lento y el mecanismo de gobierno que mantiene lo prometido después de la última wave.
Objetivos de Aprendizaje
Al terminar este contenido, serás capaz de:
- Distinguir la modernización de infraestructura de la modernización de aplicaciones, explicar los beneficios de cada una y saber en qué situación de negocio aplica cada enfoque.
- Explicar el vocabulario de migración que usa la guía del examen: workload, retire, retain, rehost, replatform, move and improve, refactor y reimagine, incluyendo las implicaciones de esfuerzo, plazo, riesgo y valor de cada ruta.
- Recomendar una ruta de migración para un caso concreto justificando la decisión con criterios observables —compatibilidad técnica, ventana de parada admisible, habilidades del equipo, coste operativo resultante— y no con preferencias.
- Enumerar los riesgos de no modernizar y traducirlos a impacto de negocio cuantificable: deuda técnica, seguridad, escalabilidad, coste, talento y pérdida de oportunidades.
- Describir las fases de una migración —assessment y portafolio, wave planning, ejecución, validación y optimización— con sus entregables y sus criterios de salida.
- Relacionar la estrategia de migración con la realización de valor, definiendo los indicadores que permiten a un comité distinguir una migración que funciona de una que solo movió servidores.
- Obtener la evidencia real de la situación con comandos
gcloud—inventario de recursos, políticas operativas, recomendaciones de optimización y gasto por etiqueta— e interpretarla en términos de negocio.
Contenido Principal
Subtema 1: Modernizar infraestructura frente a modernizar aplicaciones
Modernizar la infraestructura es cambiar la plataforma de ejecución manteniendo el software. Un servidor que vive en un datacenter propio pasa a vivir en Compute Engine; sus discos pasan a ser Persistent Disk con instantáneas programadas; el acceso pasa a usar Identity-Aware Proxy o un balanceador global; el backup deja de depender de una cinta y pasa a ser una política. El código no cambia, el equipo de desarrollo no cambia, el riesgo de la migración es acotado y medible, y el beneficio es real aunque modesto: menos operaciones manuales de hardware, más resiliencia por zonas, un modelo de coste por consumo y acceso global a la plataforma.
Modernizar las aplicaciones es cambiar la forma del software para que aproveche las capacidades nativas de la nube: migrar un backend monolítico a Cloud Run o a GKE, pasar una base de datos de motor propietario a Cloud SQL o AlloyDB, sustituir un servidor de aplicaciones por funciones, encadenar servicios con Pub/Sub y Eventarc, o mover el reporting a BigQuery. El cambio es de mayor riesgo, de mayor plazo y de mayor retorno: la ganancia llega en velocidad de despliegue, escalado elástico, coste unitario por transacción y capacidad de extraer del dato decisiones de negocio.
La distinción importa porque los dos proyectos se financian, se miden y se gestionan de forma distinta. Un proyecto de infraestructura tiene un caso de negocio que se sostiene en la comparación de coste operativo, en la reducción de incidencias de hardware y en el riesgo evitado. Un proyecto de aplicaciones tiene un caso de negocio que se sostiene en el time-to-market, en la eliminación de capacidad ociosa, en la latencia de las decisiones y en la capacidad de atender picos. Presentarlos en el mismo saco y prometer ambos a la vez con la misma evidencia es lo que hace que un comité rechace el programa.
También existe una vía intermedia que conviene nombrar: modernizar la infraestructura como palanca para modernizar las aplicaciones. Al mover un ERP a Compute Engine se habilita el siguiente paso —rodearlo de un balanceador, exponer sus APIs, mover su reporting a BigQuery, migrar su base de datos con Database Migration Service— sin bloquearse. Esta secuencia reduce el riesgo de una reescritura total y es, en la práctica, el orden que recomendaría la mayoría de organizaciones con un legado grande. Compute Engine, Cloud SQL, Cloud Storage y el networking de Google Cloud son la base sobre la que después se construyen Cloud Run, GKE y las funciones serverless.
| Dimensión | Modernización de infraestructura | Modernización de aplicaciones |
|---|---|---|
| Qué cambia | Dónde y sobre qué se ejecuta el software | La arquitectura y el modelo de ejecución del software |
| Esfuerzo típico | Semanas a pocos meses por carga | Meses a años por familia de aplicaciones |
| Riesgo principal | Interrupción durante la copia y el cambio de tráfico | Regresión funcional y de rendimiento en lógica de negocio |
| Beneficio dominante | Operativa: resiliencia, backup, seguridad de base, coste por consumo | Time-to-market, escalado elástico, coste por transacción, capacidad de innovar |
| Indicadores que lo prueban | Incidencias de hardware, cobertura de backup verificado, coste por instancia | Frecuencia de despliegue, lead time, coste por transacción, tasa de escalado automático |
| Equipo necesario | Sistemas, redes, automatización | Desarrollo, arquitectura de software, plataforma, datos |
| Relación con la nube | Es el punto de entrada habitual | Es donde aparece el valor diferencial de la nube |
| Error frecuente | Prometer ahorro de infraestructura y esperar time-to-market | Prometer ahorro de infraestructura y no modernizar el software |
Temas relacionados: Transformación con tecnología cloud, Agilidad de negocio e innovación, Modernización y migración en infraestructura.
Ejemplo Práctico
El primer paso de una conversación sobre modernización es saber qué hay realmente desplegado. Empiece por el inventario de máquinas virtuales del proyecto, con la zona, el tipo de máquina y el modelo de aprovisionamiento:
gcloud compute instances list \
--format="table(name, zone.basename(), machineType.basename(), status, scheduling.provisioningModel)"
Lectura de negocio: la columna scheduling.provisioningModel distingue entre instancias PROVISIONED (reserva dedicada, capacidad garantizada, coste fijo) y SPOT (precio interrumpible, capacidad no garantizada). Una organización con un porcentaje alto de instancias SPOT en cargas que deben tolerar interrupción está usando un mecanismo de precio sin un modelo de reintento, y esa es una conversación de riesgo, no de ahorro. La columna status permite separar cargas realmente activas de las que están detenidas y posiblemente olvidadas: cada instancia detenida sigue pagando disco y, si tiene IP estática reservada, sigue pagando esa IP. Esa es una partida de coste fácil de identificar y fácil de explicar a un comité.
Para saber qué se ha movido ya y qué queda fuera del proyecto, el inventario de recursos da la foto completa, incluyendo lo que vive en folders y organizaciones:
gcloud asset search-all-resources \
--scope=organization \
--asset-types=compute.googleapis.com/Instance \
--format="table(assetType, project, location, name)" \
--limit=200
Lectura de negocio: cada fila es una carga de trabajo candidata. La columna project revela la fragmentación del portafolio, y esa fragmentación es en sí misma un hallazgo: indica que no existe un portafolio de aplicaciones gestionado, sino un conjunto de proyectos creados por separado. La fragmentación multiplica los costes de operación y hace imposible responder preguntas básicas como cuántas cargas hay o cuánto costaron las cargas de CRM el año pasado. Si el inventario devuelve pocas filas, no significa que el portafolio sea pequeño: puede significar que parte de la infraestructura sigue fuera de Google Cloud, y esa parte es exactamente el material de la primera wave.
Comprobar el nivel de madurez del software ya desplegado en la nube cierra el diagnóstico de punto de partida:
gcloud run services list --platform=managed \
--format="table(name, region, ingress, status.latestReadyRevision)"
gcloud container clusters list \
--format="table(name, location, status, currentMasterVersion, networking.subnetwork)"
Lectura de negocio: si el entorno de Google Cloud solo contiene pocos servicios en Cloud Run y ningún clúster de GKE, la organización está en la fase de rehost, y su caso de negocio debe hablar de resiliencia y de coste operativo, no de agilidad. Si ya hay servicios en Cloud Run con revisiones sucesivas y clústeres de GKE, la conversación puede subir un nivel: ya existe capacidad de despliegue elástico y la oportunidad está en descomprimir la deuda de las cargas que siguen en máquinas virtuales.
Subtema 2: Vocabulario de migración: workloads, retire, retain y las siete rutas
El portafolio de una organización no es una lista de servidores: es una lista de workloads, entendidos como conjuntos de componentes —código, base de datos, configuración, integraciones— que en conjunto producen una capacidad de negocio. Un workload es "procesar la nómina", "cobrar las suscripciones", "servir el portal de clientes". Esta distinción importa porque una migración que traslada máquinas sin trasladar capacidades de negocio produce un resultado sin valor, y porque dos workloads distintos pueden acabar en la misma máquina por la razón equivocada: ese acoplamiento es la causa de que una modernización posterior sea inviable.
Antes de elegir una ruta para cada workload hay que decidir si el workload se migra siquiera. Retire significa que el workload desaparece: la capacidad se sustituye por un producto de mercado —un SaaS de CRM, una suite de RR. HH., una herramienta de facturación—, por un proceso automatizado o por la eliminación del requisito. Retirar suele ser la ruta de mayor valor y de mayor riesgo de negocio, porque cambia el proceso, no solo la tecnología. Retain significa que el workload se queda donde está: en el datacenter, en otra nube, en las instalaciones del cliente, o en una máquina virtual que se mantiene en Google Cloud porque moverla no aportaría nada. Retain es una decisión legítima y a menudo subestimada; un portafolio maduro tiene una proporción estable de cargas retenidas, y el error es cargar el programa de migración con cargas sin valor de negocio.
Las siete rutas de migración se ordenan en un espectro de esfuerzo, plazo, riesgo y valor crecientes:
- 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. Va a Compute Engine como máquina virtual, o a un producto de appliances migrados. Es la ruta de entrada, útil para cargas estables y legadas, y también un buen mecanismo de salida inicial de un datacenter. Su valor es real pero limitado: se eliminan costes de hardware y se gana resiliencia; no se gana agilidad ni coste unitario.
- Replatform: se cambian algunos componentes por equivalentes gestionados, sin rediseñar la aplicación. Un servidor de ficheros a Filestore, una base de datos autoalojada a Cloud SQL, un servidor de correo a un servicio gestionado. La aplicación conserva su lógica y sus integraciones, pero la operación pasa a ser gestionada. Es la ruta con mejor relación esfuerzo/valor cuando el problema es la operación, no la lógica.
- Move and improve: la carga se traslada a la nube y se mejora en el camino sin cambiar el código: se activan plantillas de instancia, autoscaling, balanceo global, discos SSD y mantenimiento automatizado. Es una rehost con un plus operativo, y suele ser el primer movimiento de un programa de migración.
- Refactor: se cambia el código para aprovechar capacidades nativas: contenedores, funciones, colas y mallas de servicio. Es la ruta de mayor inversión y la de mayor retorno cuando la aplicación es un cuello de botella para el negocio.
- Reimagine: se rediseña el servicio completo en torno a la nube —automatización, serverless, integración con datos e IA—, no solo la infraestructura. Es la ruta de las empresas que compiten con el servicio, no solo con su coste interno.
| Término | Qué significa exactamente | Qué cambia | Cuándo elegirlo | Riesgo principal | Horizonte de valor |
|---|---|---|---|---|---|
| Workload | Conjunto de componentes que produce una capacidad de negocio | Nada por sí mismo; es la unidad de análisis | Siempre, antes de decidir rutas | Confundir servidor con capacidad de negocio | Base de todo el portafolio |
| Retire | El workload desaparece, sustituido por producto, proceso o automatización | El proceso de negocio | Cuando la capacidad ya no aporta o existe alternativa mejor | Resistencia al cambio y sustitución incompleta | Alto si el proceso se rediseña |
| Retain | El workload se queda donde está | Nada | Cuando migrar no aporta valor o hay restricciones regularias | Que retain se use como excusa para no modernizar | Nulo por definición |
| Rehost | Traslado literal a máquina virtual en la nube | Ubicación y hardware | Carga estable, legacy, salida de datacenter | Bajo en funcionalidad, alto en coste estructural | Corto plazo, coste operativo |
| Replatform | Cambio de componentes por servicios gestionados | Parte de la operación | Cuando el dolor es operar la infraestructura | Cambios de configuración y comportamiento | Medio plazo, estabilidad y coste |
| Move and improve | Traslado con mejoras operativas, sin tocar el código | Plantillas, escalado, balanceo, discos | Cuando se quiere valor rápido sin tocar código | Beneficios operativos no lineales | Corto plazo, ampliable |
| Refactor | Cambio de código para usar capacidades nativas | Arquitectura de la aplicación | Aplicación en cuello de botella para el negocio | Regresión funcional | Medio plazo, time-to-market |
| Reimagine | Rediseño completo del servicio en torno a la nube | Proceso y producto | Cuando la ventaja competitiva está en el servicio | Alto riesgo de negocio y organizativo | Largo plazo, nuevos ingresos |
Temas relacionados: Modernización y migración en infraestructura, Cómputo, contenedores y serverless, Modelos de nube y responsabilidad compartida.
Ejemplo Práctico
Para clasificar el portafolio hay que inventariar por tipo de activo, no solo por proyecto. Cloud Asset Inventory permite agrupar los recursos relevantes de una organización en una sola consulta:
gcloud asset search-all-resources \
--scope=organization \
--asset-types=compute.googleapis.com/Disk,container.googleapis.com/Cluster,sqladmin.googleapis.com/Instance \
--format="table(assetType, name, location, state)" \
--limit=300
Lectura de negocio: la comparación entre el número de discos y el número de bases de datos gestionadas es ya un dato de estrategia. Si el portafolio tiene 300 discos y 12 instancias de Cloud SQL, la organización tiene mucho estado en el nivel de máquina virtual y muy poca cosecha de gestión de bases de datos: la candidata natural a replatform es la base de datos, y la candidata a move and improve son las máquinas con carga estable. El campo state permite distinguir recursos activos de recursos en borrado pendiente o con error, que son coste residual y ruido de inventario.
Para dimensionar una rehost, la pregunta operativa es qué versiones de sistema operativo exige la carga y sobre qué base se puede construir el destino. El inventario de imágenes disponibles muestra qué base de sistema se puede reutilizar como punto de partida:
gcloud compute images list \
--filter="family:debian AND deprecated.status!=DEPRECATED" \
--format="table(name, family, creationTimestamp, deprecated.status)" \
--limit=25
Lectura de negocio: la columna deprecated.status señala las imágenes que ya no reciben actualizaciones. Un plan de rehost que arranque de una imagen obsoleta traslada el coste del refresco de hardware al coste de parcheo de sistema operativo, que no desaparece: cambia de naturaleza. La decisión de negocio derivada es si la carga entra directamente en rehost o si conviene combinarla con move and improve —imagen base actualizada, plantilla de instancia, autoscaling— para que el traslado no fije la deuda dentro de la nube.
Cuando ya existen cargas en la nube migradas sin criterio, la revisión de lo que se está pagando es el primer paso hacia el portafolio:
gcloud compute disks list \
--format="table(name, zone.basename(), status, type, sizeGb, users)" \
--sort-by="~sizeGb"
Cada fila es un disco con su propietario (users) y su estado. Un disco con users vacío y status en READY es un recurso huérfano: alguien lo provisionó para una carga que se canceló o para una copia que nunca se liberó. En un programa de migración, estos discos son el ejemplo más barato de valor inmediato, porque no requieren mover nada —bastan con una regla de etiquetado y una política de retención acordada— y liberan presupuesto que financia las waves más difíciles. Es un buen primer movimiento para conseguir legitimidad interna antes de la primera carga crítica.
Subtema 3: Elegir ruta por carga: criterios, riesgos y valor de cada ruta
Elegir ruta no es una decisión estética: es una asignación de riesgo, plazo y dinero. Un Digital Leader que llega a la reunión con una tabla donde cada carga tiene una ruta justificada por criterios observables convence más rápido que uno que llega con "vamos a modernizar" y un gráfico de ahorro genérico.
Los criterios que se cruzan al decidir son cinco. Compatibilidad técnica: si la aplicación depende de un kernel específico, de un sistema de ficheros POSIX estricto, de un componente de hardware o de un middleware propietario, rehost es casi la única opción a corto plazo; si es stateless y expone HTTP, refactor a serverless es viable. Ventana de parada admisible: hay cargas tolerantes a una interrupción de varios minutos (informes nocturnos) y cargas que no toleran más de segundos (cobro, autenticación); la ruta elegida determina el método de corte, y una ruta sin corte posible exige un plan de conmutación de tráfico que hay que diseñar antes. Habilidades del equipo: una ruta que exige competencias que la organización no tiene y que no puede contratar en el horizonte del programa es una ruta que se convierte en rehost de hecho por presión de calendario. Coste operativo resultante: una rehost mantiene el parcheo, el backup y la monitorización dentro del equipo; una replatform o un refactor los desplaza al proveedor, y esa es una partida de TCO concreta. Valor esperado: qué cambia para el negocio si esta carga concreta se moderniza —llegar a un SLA, habilitar un canal nuevo, integrar un dato para decidir.
El riesgo no es solo técnico. Una rehost mantiene el acoplamiento: la aplicación sigue esperando un sistema de ficheros compartido, sigue usando IPs fijas, sigue necesitando el mismo parcheo. Cada uno de esos acoplamientos es una razón por la que, más adelante, un refactor será más caro. Por eso una secuencia sana es tratar la rehost no como destino, sino como opción de reversibilidad: da un activo movible y una línea base de coste, y compra tiempo para hacer el refactor bien. Y por eso una rehost que se queda en rehost durante años no es un éxito del programa, sino una señal de que el programa se ha quedado en la fase de ejecución.
La relación coste-beneficio tiene una forma característica: las rutas baratas en esfuerzo producen valor rápido pero limitado; las rutas caras producen valor grande pero tardío; y las rutas intermedias —replatform y move and improve— concentran el mejor equilibrio para la mayoría del portafolio. La estrategia sana no consiste en llevar todo a la ruta más avanzada, sino en gastar el esfuerzo de refactor donde el negocio lo note y dejar el resto en una ruta estable y barata de operar.
| Criterio de decisión | Rehost | Replatform | Move and improve | Refactor | Reimagine |
|---|---|---|---|---|---|
| Esfuerzo relativo | Bajo | Medio | Bajo | Alto | Muy alto |
| Plazo de entrega | Semanas | Meses | Semanas | Meses a años | Años |
| Riesgo de regresión funcional | Bajo | Bajo | Bajo | Medio | Alto |
| Riesgo de interrumpir el servicio | Bajo si hay copia previa | Bajo | Bajo | Medio | Medio |
| Reducción de coste operativo | Media | Alta | Media | Alta | Muy alta |
| Ganancia en time-to-market | Nula | Baja | Nula | Alta | Muy alta |
| Ganancia en escalado elástico | Nula | Parcial | Media | Alta | Muy alta |
| Habilidades exigidas al equipo | Sistemas | Sistemas y plataforma | Sistemas | Desarrollo y arquitectura | Producto, arquitectura y datos |
| Riesgo de crear dependencia | Bajo | Medio | Bajo | Medio | Alto si no se diseña con portabilidad |
| Cuándo tiene sentido | Salida de datacenter, carga estable legacy | Base de datos, ficheros, middleware | Bases de datos, cargas con picos moderados | Monolito en el camino crítico | Servicio central para el modelo de negocio |
Temas relacionados: Modernización y migración en infraestructura, Cómputo, contenedores y serverless, Infraestructura global de Google Cloud.
Ejemplo Práctico
Para separar cargas candidatas a rehost de cargas que conviene modernizar, el punto de partida es el inventario con datos de configuración y de plataforma, no solo el nombre:
gcloud compute instances list \
--format="table(name, zone.basename(), machineType.basename(), scheduling.provisioningModel, status, labels)" \
--filter="status=RUNNING"
Lectura de negocio: una instancia SPOT en una carga transaccional es un riesgo de disponibilidad; una instancia PROVISIONED en un servicio interno de bajo tráfico es una partida de coste optimizable. Las labels son la columna estratégica: si el portafolio tiene etiquetas app, owner, criticality y env, el programa puede agrupar cargas por aplicación, detectar dependencias y construir las waves con datos. Si no las tiene, la primera tarea del assessment es etiquetar retrospectivamente, porque sin metadatos no hay agrupación, no hay ownership y no hay responsable.
Para saber si la carga puede modernizarse hacia un motor gestionado, la consulta de las instancias de base de datos y su versión de motor es determinante:
gcloud sql instances list \
--format="table(name, databaseVersion, state, settings.tier, settings.availabilityType, region)" \
--limit=50
Lectura de negocio: settings.availabilityType con valor ZONAL señala una base de datos de una sola zona, que es una decisión de coste heredada del modelo de datacenter y que se puede revisar con una ventana de mantenimiento acordada. settings.tier indica la capacidad reservada, y la comparación de ese tier con la CPU realmente consumida revela sobreaprovisionamiento, que es el tipo de ahorro que no requiere tocar una sola línea de código y que suele financiar la primera wave. databaseVersion y region son también el insumo directo para una replatform con Database Migration Service, si la versión está soportada y el equipo tiene la disciplina de prueba de restauración.
El test de restauración previo a cualquier movimiento es un control, no un detalle, y la verificación se hace con la misma herramienta que se usará en producción:
gcloud sql backups list \
--instance=INSTANCE_NAME \
--format="table(name, type, instanceCreationTime, state, backupBytes, expireTime)"
Lectura de negocio: type con valor ON_DEMAND indica una copia bajo demanda y SCHEDULED indica una política recurrente. expireTime es la fecha en que la copia desaparece, y una política con retención de siete días es coherente con una ventana de cambio, pero insuficiente como única protección ante corrupción lógica. state debe ser SUCCESS en todas las copias: una copia en FAILED o en CREATING durante semanas es la señal de que el proceso de backup no está realmente funcionando, y esa es una conversación de riesgo antes de que la wave toque esa carga.
Subtema 4: Los riesgos de no modernizar
El argumento "migrar es mejor" no es un argumento. El argumento de negocio es "no migrar tiene un precio, y ese precio se puede cuantificar". Los seis riesgos canónicos de no modernizar son la deuda técnica, la exposición de seguridad, la imposibilidad de escalar, el coste estructural, la falta de talento y la pérdida de oportunidades.
Deuda técnica es el coste futuro que se acumula por decisiones que se posponen. Se manifiesta como software que solo una persona entiende, dependencias que ya no admiten parche de seguridad, automatizaciones que son scripts de shell colgados de un servidor, y despliegues que requieren una ventana de cuatro horas y un procedimiento documentado en una wiki. La deuda técnica no se ve en la factura; se paga en tiempos de entrega y en riesgo de incidente.
Exposición de seguridad crece con el tiempo en los entornos que no se actualizan: sistemas operativos fuera de soporte, versiones de base de datos sin parches, credenciales embebidas en el código, accesos que nunca se revocan porque nadie sabe quién los pidió. El coste de un incidente no es solo el directo: incluye laysty de negocio, el coste legal, la pérdida de clientes y, en entornos regulados, la capacidad de demostrar control, que es justamente lo que se pierde cuando el inventario de activos y el parcheo dejan de estar gestionados.
Imposibilidad de escalar es un límite físico y contractual. En el datacenter propio, un pico de demanda es un ticket de compra de hardware con plazos de meses y un compromiso de compra por años; en la nube es una pregunta de configuración. La consecuencia de negocio es la pérdida de oportunidades: el pico que no se puede atender es el cliente que se va a la competencia y la campaña que no sale.
Coste estructural: la infraestructura propia se paga por su presencia, no por su uso. Los servidores comprados para un pico de diciembre pagan doce meses. La capacidad ociosa es dinero que no está en la hoja de nóminas y por tanto no se ve en la revisión de presupuesto, pero sale de la caja. Es el coste más invisible y el que más se subestima en la comparación inicial.
Falta de talento: los profesionales que saben operar el stack heredado son cada vez menos, y su brecha salarial con los perfiles de nube crece. Una organización que depende de un puñado de personas que conocen un sistema legacy no tiene un problema de continuidad: tiene un problema de continuidad de dos o tres años.
Pérdida de oportunidades es el riesgo más caro y el menos cuantificable: el producto que no se lanzó, el mercado que no se entró, la analítica que no se pudo construir porque los datos estaban atrapados en un sistema que no se podía consultar.
| Riesgo de no modernizar | Manifestación técnica | Indicador observable | Impacto de negocio | Palanca de mitigación |
|---|---|---|---|---|
| Deuda técnica | Scripts manuales, acoplamiento, documentación obsoleta | Tiempo de despliegue, cambios manuales, dependencias sin parche | Cycle time largo, coste de cambio alto | Move and improve y luego refactor por prioridad |
| Seguridad | SO fuera de soporte, credenciales en código, accesos sin revocar | Antigüedad de la imagen base, cobertura de parcheo, permisos heredados | Incidentes, pérdida de confianza, bloqueo regulatorio | Replatform, IAM, Secret Manager, parcheo gestionado |
| Escalabilidad | Pico que no se puede servir | Capacidad ociosa y capacidad no disponible por zona | Clientes perdidos, campañas aplazadas | Escalado automático, serverless, multi-zona |
| Coste estructural | Capacidad reservada e infrautilizada | Coste por instancia frente a consumo real, porcentaje de ociosidad | Margen erosionado en la estacionalidad | Autoescalado, precios por commit, scheduler de instancias |
| Falta de talento | Dependencia de pocas personas, stack heredado | Ratio de conocimiento crítico, tiempo de incorporación | Continuidad del negocio y coste de contratación | Servicios gestionados, simplificación, formación |
| Pérdida de oportunidades | Time-to-market largo, datos inaccesibles | Lead time desde la idea hasta producción | Ingresos no capturados | Modernizar aplicaciones, datos en BigQuery, APIs |
Temas relacionados: Agilidad de negocio e innovación, Transformación con tecnología cloud, Infraestructura global de Google Cloud.
Ejemplo Práctico
La deuda técnica y la exposición de seguridad no se opinan: se miden. Las recomendaciones de optimización que genera la plataforma son un indicador temprano del desperdicio y de la configuración subóptima:
gcloud recommender recommendations list \
--project=PROJECT_ID \
--location=global \
--format="table(state.state, impact.category, content.content)" \
--limit=40
Lectura de negocio: impact.category con valores como PERFORMANCE o COST señala máquinas con margen de ahorro o de rendimiento, y state.state en ACTIVE significa que la suboptimalidad sigue viva. Un volumen alto de recomendaciones de coste sin aplicar indica un problema de dimensionado y de etiquetado, no de arquitectura: es la señal de que existe valor inmediato sin necesidad de refactor. Es el argumento más fácil de defender ante un comité, porque no requiere cambiar una sola aplicación.
El estado de las políticas operativas a nivel de máquina virtual muestra si el parcheo y la configuración de seguridad están gestionados de verdad:
gcloud compute os-config describe-policies \
--format="table(name, state, description)"
gcloud compute instances list \
--filter="labels.goog-guest-agent-enabled=true" \
--format="table(name, zone.basename(), status)" --limit=50
Lectura de negocio: si la salida de describe-policies está vacía o muestra políticas en estado no aplicado, la organización no tiene Guest Policies desplegadas, lo que significa que el parcheo y la configuración de seguridad de los invitados dependen de scripts internos que probablemente no se ejecuten de forma uniforme. Es la prueba de que la seguridad de la carga no está gestionada en la nube. Aplicar Guest Policies y OS Config antes de la wave es una acción de bajo esfuerzo y riesgo bajo que resuelve parte de la exposición de seguridad antes de mover nada.
Finalmente, la foto del patrimonio de contenedores y de datos muestra la parte del portafolio que ya tiene la plataforma de modernización montada:
gcloud container clusters list \
--format="table(name, location, status, currentMasterVersion, currentNodeVersion)"
gcloud bigquery datasets list \
--format="table(datasetName, labels, access[].role)" \
--limit=30
Lectura de negocio: un clúster con una versión de nodo por debajo de la soportada es deuda con fecha de caducidad; y un dataset con access[].role en OWNER amplio indica que el acceso al dato —el activo que más valor tiene para el negocio— no sigue un modelo de mínimo privilegio. En un programa de migración, cerrar la brecha de acceso a datos antes de mover aplicaciones evita replicar en la nube el problema de permisos que ya existía en el datacenter, que es la forma más habitual de récord de un proyecto que "ha ido bien".
Subtema 5: Fases de la migración: assessment, wave planning, ejecución, validación y optimización
Un programa de migración que no tiene fases es un proyecto de ejecución continua sin criterios de decisión. Las cinco fases son las que estructuran el método y, sobre todo, los puntos donde se puede parar y reevaluar.
Fase 1: assessment y construcción del portafolio. El objetivo es inventariar, no migrar. Se recopilan las cargas de trabajo, sus dependencias, sus propietarios de negocio, su criticidad, su ventana de parada admisible, sus requisitos de datos y sus restricciones regulatorias. El entregable es el portafolio de aplicaciones: una lista ordenada de cargas con atributos comparables. El criterio de salida es simple: toda la infraestructura conocida está inventariada y clasificada, y cada carga tiene propietario identificado. Saltarse esta fase produce el síntoma clásico: la primera wave se hace con las cargas más fáciles —porque son las que se han inventariado primero— y más adelante se descubre que no se puede seguir.
Fase 2: wave planning. Las cargas se agrupan en olas. Un grupo de aplicación, sus dependencias y sus datos se mueven juntos. La wave tiene un objetivo de negocio, un alcance, una ventana, un responsable y un plan de reversión. El criterio de salida: la wave tiene un plan de ejecución probado en un entorno no productivo y un criterio de abortar claro. La wave no es un grupo arbitrario: agrupar por dependencia técnica reduce el riesgo de ruptura de relaciones, pero no genera valor por sí sola; lo que genera valor es que cada wave tenga un objetivo de negocio.
Fase 3: ejecución. Se migra la wave: rehearsal, cutover, validación técnica y conmutación de tráfico. El rehearsal en un entorno de pruebas no es opcional en cargas con datos: es la única forma de medir de verdad la duración real de la parada, que casi siempre es mayor que la estimada en el plan.
Fase 4: validación. Tras el cutover se comprueba que la carga funciona: pruebas funcionales, comparación de métricas de servicio antes y después, reconciliación de datos y confirmación con el propietario de negocio. El criterio de salida es la firma del negocio, no la del equipo técnico. Si el dueño del proceso no ha confirmado que su proceso sigue igual, la wave no está cerrada.
Fase 5: optimización. Es la fase que casi nadie ejecuta y la que determina si el programa fue un éxito. Se revisan dimensionamientos, se activan instrumentos de coste, se ajustan políticas operativas, se cierran los recursos huérfanos y se resuelve la deuda de seguridad que quedó pendiente. Solo aquí se puede hablar de realizar el valor prometido, porque hasta el final de la fase anterior el programa solo ha movido workloads.
| Fase | Objetivo | Entregable principal | Criterio de salida | Error típico |
|---|---|---|---|---|
| Assessment | Inventariar y clasificar | Portafolio de aplicaciones con atributos y dependencias | Toda carga conocida, con propietario y criticidad | Confundir inventario de servidores con inventario de workloads |
| Wave planning | Agrupar en olas con objetivo de negocio | Plan de olas con alcance, ventana, responsable y reversión | Cada wave con plan probado y criterio de abortar | Formar olas por comodidad técnica sin objetivo de negocio |
| Ejecución | Mover el contenido de la wave | Cutover ejecutado y tráfico conmutado | Carga estable en destino con desviaciones dentro de lo previsto | Ejecutar sin rehearsal ni plan de reversión |
| Validación | Confirmar que el servicio y el proceso siguen iguales | Evidencia funcional, de datos y de negocio | Firma del propietario del proceso | Dar por válida la wave porque la infraestructura está en pie |
| Optimización | Realizar el valor y cerrar la deuda | Ajustes de dimensionamiento, coste, seguridad y operación | Indicadores de valor en línea con el caso de negocio | Terminar el programa al mover la última carga |
Temas relacionados: Modernización y migración en infraestructura, Cómputo, contenedores y serverless, Agilidad de negocio e innovación.
Ejemplo Práctico
La planificación por olas necesita datos de agrupación. Si el portafolio está etiquetado, las olas salen directamente del inventario:
gcloud compute instances list \
--filter="labels.migration_wave!=''" \
--format="table(labels.migration_wave, name, zone.basename(), machineType.basename(), status)" \
--sort-by="labels.migration_wave"
Lectura de negocio: la salida agrupada por labels.migration_wave muestra el tamaño real de cada ola y si hay cargas de una ola anterior aún en ejecución fuera de su fecha prevista. Una ola que mantiene mezcla de estados RUNNING y TERMINATED indica una validación incompleta: la wave no terminó de limpiar y hay carga duplicada, es decir, coste doble durante un tiempo que alguien está absorbiendo en silencio.
Para la fase de validación, la evidencia se toma de los logs del proyecto en la ventana del cutover, que es donde aparecen los errores de aplicación que la comprobación de infraestructura no detecta:
gcloud logging read \
'resource.type="gce_instance"' \
--project=PROJECT_ID \
--limit=50 \
--format="table(timestamp, severity, resource.labels.instance_id, textPayload)" \
--freshness=2d
Lectura de negocio: severity por encima de DEFAULT marca errores que un simple "la máquina está arriba" no detecta. El objetivo de la validación no es cero errores —ningún sistema heredado llega a cero—, sino que la tasa de error tras el cutover no supere la del entorno de origen. Esa es la conversación correcta con el dueño del proceso: no "no hay errores", sino "el error estructural es el mismo que antes y los errores nuevos están identificados".
La comprobación de que una wave ha sentado la base tiene una segunda mitad: los servicios gestionados que la wave debía dejar activados. Si la wave debía dejar una base de datos gestionada y la consulta no la devuelve, la wave está a medio cerrar:
gcloud sql instances list \
--format="table(name, databaseVersion, state, region, settings.availabilityType)" \
--filter="state:RUNNABLE"
El estado RUNNABLE es la señal de que la instancia está sirviendo; un state con STOPPED o en proceso de creación indica que la migración de datos no ha terminado o que se ha detenido la instancia en una ventana de cambio. Cruzar esta consulta con la de las máquinas de la wave es lo que permite al comité ver el cierre real de una ola y no el cierre administrativo.
Subtema 6: De la estrategia de migración a la realización de valor
Value realization es el proceso por el cual los beneficios prometidos en el caso de negocio se convierten en resultados medibles en el negocio. En un programa de migración, la distancia entre promesa y realidad se mide en cuatro cosas: el coste que realmente se ahorra, el tiempo que se recupera en la entrega, la capacidad que se gana para atender picos y el riesgo que se reduce. Un programa bien ejecutado pero sin indicadores acordados no puede demostrar su valor, y un programa sin valor no es un programa de migración: es un gasto de infraestructura.
La relación entre estrategia de migración y realización de valor tiene una forma que conviene entender: la ruta elegida determina el valor esperado y la fecha en que llega. Un rehost entrega ahorro operativo en meses; un refactor entrega time-to-market en trimestres; un reimagine puede abrir un producto nuevo en años. Si el caso de negocio promete un ingreso nuevo en el primer trimestre y la ruta elegida para esa carga es rehost, la estrategia y el caso de negocio son incompatibles, y esa incompatibilidad debería detectarse en el assessment, no en la revisión de resultados.
También hay una relación inversa que se subestima: la velocidad del programa es valor. El coste de oportunidad de una migración lenta no es el sobrecoste de la operación; es el tiempo durante el cual el negocio sigue sin las capacidades que la nube le iba a dar. Un programa que tarda dos años en migrar 400 cargas se queda sin la mitad del valor que habría capturado durante el primer año. Por eso la estrategia necesita una lógica de early wins: un primer conjunto de cargas que aporte valor visible y genere legitimidad interna para sostener el resto del programa.
El mecanismo de gobierno es lo que convierte el valor en algo sostenido. Tres controles mínimos: una etiqueta de coste obligatoria en todo recurso nuevo, para que el gasto pueda atribuirse a un workload y no a un equipo difuso; un presupuesto con alertas por proyecto y por etiqueta, para detectar desviaciones antes de que se conviertan en un hecho consumado; y una revisión periódica de la optimización con el Recommender y con las métricas de uso, para que el dimensionamiento que era correcto en la wave 1 lo siga siendo en la wave 8.
| Indicador de valor | De dónde sale el dato | Qué demuestra | Meta típica en un programa maduro |
|---|---|---|---|
| Coste de infraestructura por workload | Etiquetas de coste y facturación por proyecto | Atribución real del gasto y detección de desviación | 100 % de recursos con etiqueta de workload |
| Ahorro frente a línea base | Comparativa de facturación por carga antes y después | Que la ruta elegida produce el ahorro previsto | Ahorro alineado con el caso de negocio por ruta |
| Lead time de cambio | Historial de despliegues en Cloud Run o GKE y registro de releases | Capacidad de respuesta del equipo | Downtime medido por wave |
| Utilización de la capacidad | Instancias por grupo, CPU y memoria por instancia | Elimina sobreaprovisionamiento | Ratio de ociosidad por debajo del umbral acordado |
| Coste por transacción o por usuario | Facturación dividida por volumen de negocio | Eficiencia real del servicio | Tendencia decreciente tras cada refactor |
| Disponibilidad e incidencias | SLOs, Cloud Monitoring y registro de incidentes | Calidad del servicio tras el cambio | Sin regresión frente a la línea base |
| Valor de negocio habilitado | Ingresos, ahorro o tiempo ahorrado por casos de uso | El fin del programa | Reportado al comité por caso de uso |
Temas relacionados: Agilidad de negocio e innovación, Transformación con tecnología cloud, Cómputo, contenedores y serverless.
Ejemplo Práctico
La atribución del gasto es la base de cualquier conversación de valor. Las etiquetas son el mecanismo que permite responder cuánto cuesta esta carga:
gcloud compute instances list \
--filter="labels.app!=''" \
--format="table(labels.app, labels.env, name, machineType.basename(), status)" \
--sort-by="labels.app"
Lectura de negocio: cada aplicación con etiqueta es una unidad de coste y una unidad de conversación con su propietario. Si una aplicación acumula recursos en env=dev y env=prod con la misma etiqueta app, no hay forma de saber si su coste de desarrollo está disparado; si hay cargas sin labels.app, su coste es invisible y por tanto indefendible ante un comité que pregunta por el ahorro. El primer indicador de valor que un programa puede entregar sin tocar una sola aplicación es, por tanto, un inventario completo y etiquetado.
El control del gasto en el tiempo se apoya en presupuestos con umbrales y alertas por proyecto:
gcloud billing budgets list \
--billing-account=BILLING_ACCOUNT_ID \
--format="table(name, displayName, amount.budgetAmount.amount, amount.actualSpend.amount, thresholdRules[0].thresholdPercent, thresholdRules[0].spendBasis)" \
--limit=30
Lectura de negocio: la comparación entre budgetAmount y actualSpend muestra el consumo respecto al umbral, y thresholdRules[0].thresholdPercent indica en qué punto salta la alerta. Un presupuesto con alertas al 50 % y al 100 % sobre consumos reales es un mecanismo de gobierno maduro: avisa a mitad de camino. El valor de esto no es ahorrar un porcentaje, es que el programa puede hacer correcciones de dimensionamiento mientras todavía hay margen, en vez de descubrir la desviación cuando el dinero ya se gastó.
El indicador que convierte una conversación de coste en una conversación de valor es la comparación por unidad de negocio:
gcloud logging read \
'resource.type="cloud_run_revision"' \
--project=PROJECT_ID \
--freshness=7d \
--format="table(timestamp, resource.labels.service_name, jsonPayload.requestCount)" \
--limit=200
Lectura de negocio: si el servicio que procesa pedidos genera 2000 peticiones diarias y su coste mensual de infraestructura es 400 euros, el coste por transacción se puede calcular y comparar con la línea base del entorno de origen. Ese cociente es el indicador que un comité entiende, y su evolución tras cada refactor demuestra el efecto real de la ruta elegida. El cálculo exacto del gasto en euros sale de Cloud Billing, no de estos logs: los logs aportan el denominador —el volumen de negocio— y la facturación aporta el numerador. La lectura honesta de un Digital Leader es presentar ambos, con su fuente, y no un porcentaje inventado [VERIFICAR: magnitudes concretas de ahorro según sector y tamaño del portafolio, no publicables sin dato propio].
Conceptos Clave
| Concepto | Descripción | Cuándo usarlo |
|---|---|---|
| Workload | Conjunto de componentes —código, datos, configuración, integraciones— que produce una capacidad de negocio | Como unidad de análisis del portafolio, antes de elegir ruta |
| Modernización de infraestructura | Cambiar la plataforma de ejecución sin alterar el código | Cuando el objetivo es resiliencia, operación y coste por consumo |
| Modernización de aplicaciones | Cambiar la arquitectura del software para aprovechar servicios gestionados y serverless | Cuando el objetivo es time-to-market, escalado elástico y coste por transacción |
| Retire | Decidir que un workload desaparece, sustituido por producto, proceso o automatización | Cuando la capacidad dejó de aportar valor o existe alternativa mejor |
| Retain | Decidir que un workload se queda donde está | Cuando migrar no aporta valor o hay restricciones regulatorias |
| Rehost | Trasladar la carga sin cambiar el código ni la configuración | Carga estable, legacy, salida de datacenter |
| Replatform | Sustituir componentes por servicios gestionados sin rediseñar la aplicación | Cuando el dolor operativo está en la base de datos, ficheros o middleware |
| Move and improve | Trasladar y mejorar la operación en el camino, sin tocar el código | Cuando se quiere valor rápido sin asumir riesgo de regresión |
| Refactor | Cambiar el código para usar capacidades nativas de la nube | Aplicación en el camino crítico del time-to-market |
| Reimagine | Rediseñar el servicio completo en torno a la nube | Cuando la ventaja competitiva está en el servicio, no en su coste |
| Wave | Grupo de cargas que se migran juntas con un objetivo de negocio | Unidad de gestión de riesgo, coste y comunicación del programa |
| Rehearsal | Ejecución de la migración en entorno no productivo para medir tiempos reales | Obligatorio en cargas con datos antes de cualquier cutover |
| Cutover | Momento en que el tráfico pasa al destino | Fase de la wave con plan de reversión y comunicación previa |
| Criterio de abortar | Umbral predefinido que detiene la wave y activa la reversión | En toda wave con datos o cambios de configuración relevantes |
| Case de negocio | Documento con beneficios esperados, coste, riesgos y plazos de cada ruta | Base de la priorización del portafolio y de la aprobación del programa |
| Value realization | Proceso por el que los beneficios prometidos se convierten en resultados medibles | Fase de optimización y comité de seguimiento del programa |
| Línea base | Métricas de coste, disponibilidad y lead time anteriores a la migración | Para comparar y demostrar mejora con datos |
| Etiqueta de coste | Metadato que atribuye el gasto de un recurso a un workload o equipo | En todo recurso nuevo, como condición de salida de cada wave |
| Coste de oportunidad del programa | Valor no capturado mientras la migración no se completa | Para calibrar la urgencia de la velocidad del programa |
| Deuda técnica | Coste futuro acumulado por decisiones de diseño pospuestas | Como riesgo de no modernizar y criterio de priorización de refactor |
Comparaciones
| Dimensión | Rehost | Replatform | Move and improve | Refactor | Reimagine |
|---|---|---|---|---|---|
| Código de la aplicación | Sin cambios | Sin cambios o mínimo | Sin cambios | Cambia | Cambia de forma sustancial |
| Servicios Google Cloud típicos | Compute Engine | Cloud SQL, Filestore, AlloyDB | Compute Engine con plantillas, Managed Instance Groups, Cloud Load Balancing | Cloud Run, GKE, Cloud Functions, Pub/Sub | Cloud Run, BigQuery, Vertex AI, APIs |
| Esfuerzo de equipo | Sistemas | Sistemas y plataforma | Sistemas y automatización | Desarrollo y arquitectura | Producto, arquitectura y datos |
| Riesgo para el negocio | Bajo | Bajo | Bajo | Medio | Alto |
| Velocidad de ejecución | Alta | Media | Alta | Baja | Muy baja |
| Momento del primer valor | Semanas | Meses | Semanas | Trimestres | Años |
| Riesgo de crear dependencia nueva | Bajo | Medio | Bajo | Medio | Alto si no se diseña con portabilidad |
| Efecto sobre el coste operativo | Reduce coste de hardware | Reduce operación de la capa sustituida | Reduce o elimina capacidad ociosa | Reduce drásticamente la operación | Convierte el coste en coste por uso |
| Efecto sobre la agilidad | Ninguno | Bajo | Bajo | Alto | Muy alto |
| Cuándo no elegirlo | Si la carga va a desaparecer en semanas | Si la aplicación está para rehacer | Si el problema real es de código o de proceso | Si no hay capacidad de equipo ni objetivo de negocio | Si no hay mandato para cambiar el servicio |
| Dimensión | Modernizar infraestructura | Modernizar aplicaciones |
|---|---|---|
| Horizonte de entrega | Semanas a meses | Meses a años |
| Dependencia del equipo de desarrollo | Nula | Alta |
| Riesgo principal | Interrupción durante el traslado | Regresión funcional |
| Capacidad de seguir invirtiendo en modernización | Sí | Sí, pero con nueva deuda posible |
| Coste de gestión del cambio | Bajo | Alto |
| Beneficio típico | Resiliencia, seguridad de base, coste de hardware | Time-to-market, escalado, coste por transacción |
| Indicador de control | Incidencias de hardware, cobertura de backup | Lead time, frecuencia de despliegue, coste por transacción |
Errores Comunes
- Error: Tratar la migración como un proyecto de infraestructura y prometer con ella beneficios de agilidad, time-to-market y coste por transacción. → Solución: Separar explícitamente los dos programas o, en su defecto, declarar qué rutas del portafolio son rehost y move and improve y cuáles son refactor, y asignar a cada una los indicadores que le corresponden. El ahorro de infraestructura se demuestra con la facturación comparada; el time-to-market se demuestra con el lead time de despliegue y el coste por transacción con la facturación dividida por volumen de negocio. Prometer todo con una sola métrica es la forma más rápida de perder la credibilidad del programa ante el comité.
- Error: Empezar por la migración de las cargas más fáciles —las que se han inventariado primero— y descubrir a mitad del programa que las cargas críticas dependen de un acoplamiento no documentado o de un sistema con datos que no se puede mover. → Solución: Completar el assessment del portafolio antes de la primera wave, incluyendo dependencias, propietario de negocio, ventana de parada admisible y requisitos de datos, y planificar las olas por agrupación de aplicación y de negocio. Las cargas fáciles no generan valor por sí solas; generan legitimidad. El orden correcto es tratarlas como quick wins explícitos y acotados, con el resto del portafolio ya evaluado.
- Error: Ejecutar la primera wave en producción sin rehearsal ni plan de reversión, calculando la ventana de parada a ojo. → Solución: Ejecutar un rehearsal completo en entorno no productivo para medir la duración real de la copia y del corte, documentar un criterio de abortar con umbrales concretos y comunicar la ventana a los propietarios del negocio con antelación. El plan de reversión debe estar probado, no escrito: en una carga con datos, volver atrás exige saber si la fuente sigue intacta y si hay reconciliación de cambios.
- Error: Declarar la wave cerrada porque la carga está en pie en Google Cloud, sin validación con el dueño del proceso ni reconciliación de datos. → Solución: Cerrar la wave con evidencia de negocio: pruebas funcionales ejecutadas por el área usuaria, comparación de la tasa de error antes y después, verificación del volumen y la integridad de los datos migrados y firma del propietario del proceso. El criterio de salida de una wave es la confirmación del negocio, no el despliegue exitoso de la infraestructura.
- Error: Terminar el programa con el cutover de la última carga y no ejecutar la fase de optimización, dejando sin ajustar el dimensionamiento, sin cerrar recursos huérfanos y sin resolver la deuda de seguridad pendiente. → Solución: Tratar la optimización como fase con entregables y criterio de salida: revisión de recomendaciones de coste y rendimiento, ajuste de dimensionamiento de grupos de instancias, eliminación de discos e IPs huérfanos, aplicación de Guest Policies y cierre de la etiqueta de coste. Sin esta fase el valor prometido no se realiza y el programa se convierte en una operación permanente en lugar de un proyecto con final.
Puntos para el Examen
🎯 Punto clave 1: Modernizar infraestructura y modernizar aplicaciones no son sinónimos. La primera cambia dónde se ejecuta el software y se demuestra con resiliencia, backup, coste por consumo y reducción de incidencias de hardware; la segunda cambia la arquitectura del software y se demuestra con time-to-market, escalado elástico y coste por transacción. Un examen que presente un escenario con una aplicación heredada que se quiere mover a Cloud Run espera la respuesta "modernización de aplicaciones", no "rehost".
🎯 Punto clave 2: El vocabulario de migración tiene un significado exacto que hay que respetar: workload es la unidad de análisis; retire significa que la carga desaparece; retain significa que se queda; rehost traslada sin cambiar el código; replatform cambia componentes por servicios gestionados; move and improve traslada y mejora la operación; refactor cambia el código; reimagine rediseña el servicio. La pregunta tipo es "qué ruta recomienda y por qué", y la respuesta esperada combina un criterio técnico, uno operativo y uno de valor de negocio.
🎯 Punto clave 3: El método por fases es el eje del tema: assessment y portafolio de aplicaciones, planificación por olas, ejecución con rehearsal y cutover, validación con el dueño del negocio, y optimización. Lo que se evalúa es el criterio de salida de cada fase y, sobre todo, que ninguna fase se salta: el error más caro no es elegir mal una ruta, es ejecutar la primera wave sin haber inventariado el portafolio.
🎯 Punto clave 4: Los riesgos de no modernizar —deuda técnica, seguridad, escalabilidad, coste estructural, falta de talento y pérdida de oportunidades— son el verdadero caso de negocio del programa, porque tienen coste de oportunidad y no solo de coste de factura. Y el valor se realiza con evidencia: indicadores por workload mediante etiquetas de coste, presupuestos con alertas, comparación de métricas antes y después, y coste por unidad de negocio.
🎯 Punto clave 5: La estrategia de migración y la realización de valor están atadas por la variable tiempo: la ruta elegida determina cuándo llega el valor, y la velocidad del programa multiplica o reduce ese valor. Un programa que tarda años en migrar pierde la mitad de la ventana de beneficio, por eso las quick wins existen. La respuesta completa a "cómo se demuestra que la migración funciona" no es un ahorro teórico: es una etiqueta de coste, una línea base medida antes de migrar y una comparación de indicadores después.
Recursos Externos
- Migrate to Virtual Machines: overview del producto — Alcance del servicio de rehost, su relación con los informes de evaluación y los flujos de trabajo de copia y corte.
- Migrate to Virtual Machines: assessment report — Qué datos recoge el informe de evaluación de una carga y cómo se usa para dimensionar el destino.
- Cloud Architecture Framework: assessment and planning — Principios de evaluación del estado actual y de planificación por fases de la nube.
- Cloud Architecture Framework: execution — Guías de ejecución del cambio con líneas base, agrupación, cutover y reversión.
- Cloud Asset Inventory: overview — Cómo inventariar recursos de una organización con filtros por tipo de activo, que es la base del portafolio de aplicaciones.
- Recommender: overview — Funcionamiento de las recomendaciones de optimización de coste y rendimiento que alimentan la fase de optimización.
Autoevaluación Rápida
-
Pregunta: Una empresa tiene un ERP que no puede reescribir, un portal de clientes con picos estacionales y un motor de cálculo de precios que bloquea el lanzamiento de nuevas tarifas. ¿Qué ruta recomienda para cada uno y qué valor entrega cada ruta? Respuesta: El ERP va a rehost sobre Compute Engine, porque su base de datos, sus informes y sus dependencias propietarias no admiten reescritura; el valor es la estabilidad operativa y la salida del datacenter, es decir, la eliminación del coste de hardware y la resiliencia por zonas, no la agilidad. El portal de clientes va a move and improve, es decir, rehost con activaciones: managed instance group con autoscaling, balanceo global y health checks; el valor está en atender el pico sin comprar capacidad y en dejar una base preparada para una posterior migración a serverless. El motor de precios va a refactor, porque bloquea un resultado de negocio concreto —no se pueden lanzar tarifas nuevas— y es candidato a un servicio en Cloud Run con escalado elástico y lógica desacoplada del sistema heredado. La secuencia de valor es: primero el ERP (coste y riesgo), después el portal (elasticidad y disponibilidad) y el motor de precios al final, cuando el equipo ya tiene experiencia con las waves anteriores y el negocio ve el balance. La razón de este orden no es el riesgo técnico, es que cada wave financia la siguiente y el orden inverso comprometería el caso de negocio.
-
Pregunta: ¿Qué diferencia real hay entre rehost y move and improve, y por qué la segunda produce más valor sin más riesgo de código? Respuesta: Rehost traslada la carga tal cual: mismo sistema operativo, misma configuración, misma forma de funcionar, y el resultado es que la carga vive en Google Cloud con el mismo nivel de operación que tenía antes. Move and improve traslada y, en el mismo movimiento, sustituye la configuración manual por configuración gestionada: plantillas de instancia, managed instance groups, autoscaling con límites definidos, discos SSD, balanceo con health checks y mantenimiento automatizado. El valor adicional viene de tres fuentes que no exigen tocar el código: se elimina la capacidad ociosa porque el grupo de instancias crece y se encoge con la demanda; se mejora la disponibilidad porque el balanceo deja de enrutar a una instancia caída; y se reduce el esfuerzo de parcheo y de administración de sistemas. El riesgo de código no aumenta porque la lógica de la aplicación no cambia: lo que cambia es la plataforma que la ejecuta. El riesgo que sí aparece es operacional —un autoscaling mal configurado puede propagar el fallo en vez de mitigarlo—, y por eso la mejora viene con límites minSize y maxSize explícitos y con un health check que detecte el fallo de la aplicación y no solo el del proceso.
-
Pregunta: El equipo de migración propone mover 200 cargas a Compute Engine en tres meses, porque "las máquinas ya están documentadas y el movimiento es automatizable". ¿Qué le respondería un Digital Leader? Respuesta: Le respondería que ese plan optimiza la fase más fácil y pospone la fase que genera valor, y le pediría cuatro cosas concretas. Primera, un assessment completo del portafolio: qué cargas existen más allá de esas 200, qué dependencias hay entre ellas, qué propietario de negocio tiene cada una y qué ventana de parada admite cada proceso. Segunda, un plan de validación por parte de los dueños de proceso, porque el criterio de salida de una wave no es que la máquina esté en pie, es que el proceso sigue igual y alguien lo firma. Tercera, un rehearsal con datos reales en un entorno no productivo para medir la duración efectiva de la parada, que es el dato que nunca coincide con la estimación. Y cuarta, una fase de optimización explícita al final, con revisión de dimensionamiento y cierre de recursos huérfanos, porque sin ella el programa deja de ser un proyecto y se convierte en una operación permanente con el presupuesto del proyecto. La propuesta de tres meses no es mala por rápida: es mala porque probablemente mueve las cargas fáciles y descubre tarde el acoplamiento crítico, que es el escenario que hunde el valor esperado.
-
Pregunta: Un comité pregunta cuánto va a ahorrar esta migración. ¿Qué respondería con evidencia real y qué no debería afirmar? Respuesta: Con evidencia real, respondería con tres lecturas de consola. La atribución:
gcloud compute instances list --filter="labels.app!=''"muestra cuántas cargas tienen etiqueta de workload y, por tanto, cuántas se pueden atribuir a un dueño; sin esa cobertura no se puede atribuir el gasto y cualquier ahorro es una afirmación sin base. El consumo y la desviación:gcloud billing budgets listcontrastaactualSpendcontrabudgetAmounty muestra si las alertas están configuradas antes de que se desvíe. Y la eficiencia: la facturación dividida por el volumen de negocio, donde el volumen sale de los logs del servicio y el gasto de Cloud Billing, da el coste por transacción o por usuario, que es la cifra que el comité entiende y que permite comparar antes y después de cada refactor. Lo que no debería afirmar es un porcentaje de ahorro genérico, un ahorro por licencia calculado sobre precios de lista sin ajustar por descuentos y por el propio coste de la nube, ni una proyección de valor sin línea base medida antes de la migración. La línea base —coste, disponibilidad y lead time del entorno de origen— es lo que convierte la comparación en una prueba; sin ella, solo hay dos números que se comparan sin contexto. -
Pregunta: ¿Por qué el valor de la nube depende tanto de la velocidad del programa y cómo se gestiona esa tensión? Respuesta: Porque la nube no entrega valor por el mero hecho de estar ahí: entrega valor por las capacidades que habilita —elasticidad para picos, agilidad para lanzar, datos para decidir— y esas capacidades solo existen cuando la carga correspondiente está migrada y modernizada. Entre el día en que se aprueba el programa y el día en que se completa, el negocio sigue operando como antes, pero ha cambiado su coste de infraestructura y su carga de trabajo operativo sin haber capturado ninguna de las capacidades nuevas. Ese desfase es el coste de oportunidad del programa y reduce el retorno total. La tensión se gestiona con tres decisiones. La primera, ordenar el portafolio por valor y no por facilidad, aceptando que las cargas fáciles van primero por su coste de ejecución, pero identificando al menos una quick win por wave que aporte valor visible y genere legitimidad interna. La segunda, acotar el alcance: un programa que mueve un grupo de aplicaciones completo y lo deja operativo es defendible; un programa que intenta cubrir todo el portafolio se queda en movimiento perpetuo. Y la tercera, medir en valor y no en infraestructura: cada wave se cierra con su indicador de negocio, y el comité recibe valor acumulado, no un porcentaje de servidores movidos.