Semana 11 · Módulo 11 de 12

Migración, negocio y casos de estudio

Cómo planificar una migración a Google Cloud de principio a fin (evaluar, planificar, desplegar, optimizar), con qué herramientas, cómo afectan las licencias y el dinero, y cómo gestionar personas y procesos. Cierra con un método para resolver los casos de estudio, que suponen entre el 20 y el 30 % del examen.

Reparto de la semana

Por qué importa

El examen no pregunta solo «qué servicio es mejor». Pregunta cómo llegar hasta él desde lo que la empresa tiene hoy, cuánto cuesta, qué riesgos hay y cómo se gestiona a las personas. Los apartados 1.4 (plan de migración), 1.1 (requisitos de negocio, estrategias de disposición, KPIs y ROI), 1.5 (mejoras futuras) y 4.2 (procesos de negocio) aparecen en preguntas sueltas y, sobre todo, en los casos de estudio: tres de los cuatro casos (Cymbal Retail, EHR Healthcare y KnightMotives) incluyen sistemas on-premises que migrar, y los cuatro exigen reducir costes o mejorar la operación.

Además, en el examen salen dos casos y sus preguntas suponen entre el 20 y el 30 % del total. Esta semana cierras la teoría con el método para resolverlos.

El marco de migración de Google

Google describe la migración como un viaje en cuatro fases, documentado en la serie Migrate to Google Cloud del Cloud Architecture Center:

flowchart LR
  A["Fase 1: Assess (evaluar y descubrir)"] --> P["Fase 2: Plan (planificar y construir la base)"]
  P --> D["Fase 3: Deploy (desplegar las cargas)"]
  D --> O["Fase 4: Optimize (optimizar)"]
  O -.->|"mejora continua"| A

1. Assess: evaluar y descubrir

Objetivo: saber qué tienes y qué conviene hacer con cada cosa.

• Inventario de servidores, bases de datos, aplicaciones, almacenamiento y red. Nunca te fíes solo de la CMDB: descubre con herramientas.
• Dependencias: qué habla con qué (puertos, protocolos, latencias). Lo que está muy acoplado se migra junto.
• Clasificación de cada carga: criticidad, complejidad, requisitos de cumplimiento, dueño de negocio.
• Elegir la estrategia (las «R», más abajo) y calcular un TCO inicial.
• Madurez de la organización: Google propone el Google Cloud Adoption Framework, que evalúa cuatro temas (Learn, Lead, Scale, Secure) en tres fases (tactical, strategic, transformational).
• Primeras candidatas: cargas poco críticas, con pocas dependencias y un equipo motivado. Sirven de aprendizaje.

2. Plan: planificar y construir la base

Antes de mover nada se construye la landing zone (la base):

• Identidad: Cloud Identity o Google Workspace, federación con el directorio existente (Google Cloud Directory Sync, SSO).
• Jerarquía de recursos: organización, carpetas, proyectos; políticas de organización.
• Red: Shared VPC, plan de direccionamiento IP sin solapamientos con on-premises, conectividad híbrida (Interconnect o HA VPN), DNS.
• Seguridad: IAM con grupos, registros de auditoría centralizados, KMS, VPC Service Controls si hay datos sensibles.
• Facturación y FinOps: cuentas de facturación, presupuestos, etiquetas, exportación a BigQuery.
• Plan de migración por olas, con criterios de éxito, pruebas y plan de vuelta atrás (rollback).

3. Deploy: desplegar

Se ejecutan las olas: se transfieren datos, se migran VMs, contenedores y bases de datos, se prueba, se hace el corte (cutover) y se retira lo antiguo. Google recomienda pasar de despliegues manuales a automatizados (infraestructura como código, CI/CD) en cuanto se pueda.

4. Optimize: optimizar

Tras migrar, se mejora de forma continua: dimensionamiento (rightsizing con las recomendaciones de Active Assist), descuentos (CUDs), servicios gestionados, autoescalado, observabilidad y automatización. Es aquí donde se consigue buena parte del ahorro que justificó la migración.

Las «R» de la migración

La documentación de Google define seis tipos de migración. En la práctica (y en muchos enunciados) se añaden dos más, retire y retain, que no son migraciones sino decisiones de no mover.

Estrategias de disposición: build, buy, modify, deprecate

La guía del examen (apartado 1.1) usa otra clasificación, más de negocio, para decidir qué hacer con cada carga (workload disposition):

Ejemplo del caso KnightMotives: el CRM integral es un «buy» claro; la experiencia a bordo con IA es un «build» porque es la diferenciación de la marca; el ERP obsoleto es «buy» o «modify»; los informes duplicados, «deprecate».

Herramientas de migración

Google Cloud Migration Center

Migration Center es la plataforma unificada para el inicio de cualquier migración. Qué hace:

• Descubrimiento de activos (asset discovery): inventario automático de servidores y de bases de datos Microsoft SQL Server, MySQL y PostgreSQL mediante un cliente de descubrimiento; también admite subir los datos a mano (por ejemplo, exportaciones de RVTools o CSV).
• Evaluación: informes de TCO (total cost of ownership), sugerencias de producto de destino según el encaje técnico, dependencias de aplicaciones y de red para decidir qué migrar junto.
• Estimación rápida de costes (en Preview según la documentación actual): una cifra aproximada del coste en Google Cloud a partir del tamaño del entorno.
• Planificación: agrupar activos, preparar olas y lanzar las herramientas de ejecución (rehost, replatform, refactor).

Migrate to Virtual Machines (rehost)

Migra VMs y discos desde vSphere on-premises, AWS, Azure y Google Cloud VMware Engine a Compute Engine. Características clave:

• Replicación continua en segundo plano mientras la VM origen sigue en marcha.
• Clones de prueba (test clones) en Google Cloud sin afectar al origen: permiten validar antes del corte.
• Corte (cut-over) con poca parada: se detiene el origen, se sincroniza el último delta y se arranca en Google Cloud.
• Adaptación del sistema operativo para que arranque en Compute Engine.

Alternativas: si el requisito es no cambiar nada de VMware (herramientas, procesos, licencias de vSphere), la respuesta es Google Cloud VMware Engine (VMware gestionado en Google Cloud), no Compute Engine.

Migrate to Containers (replatform)

Convierte cargas que corren en VMs (de VMware on-premises o Compute Engine) en contenedores para GKE (o Cloud Run según la carga). Genera los artefactos (Dockerfile, manifiestos). Útil para aplicaciones sin estado o con estado sencillo; menos útil para bases de datos o aplicaciones muy ligadas al sistema operativo. Evalúa antes el encaje de cada carga (la herramienta incluye una evaluación de idoneidad).

Database Migration Service (DMS)

Migra bases de datos a Cloud SQL y AlloyDB for PostgreSQL:

• Homogéneas (mismo motor): MySQL → Cloud SQL for MySQL; PostgreSQL → Cloud SQL for PostgreSQL o AlloyDB; SQL Server → Cloud SQL for SQL Server (a partir de copias de seguridad y logs de transacciones subidos a Cloud Storage).
• Heterogéneas (motor distinto): por ejemplo Oracle → Cloud SQL for PostgreSQL / AlloyDB, con conversión de esquema y código asistida por Gemini.
• Continua (carga inicial + CDC, change data capture) para mínimo tiempo de inactividad, o única (one-time, volcado y carga) si se admite parada.
• Serverless: no hay que gestionar servidores de replicación.

Otras bases de datos: Redis → Memorystore (for Redis o for Valkey); MongoDB → Firestore with MongoDB compatibility (edición Enterprise) o MongoDB Atlas; replicación a BigQuery para analítica con Datastream.

BigQuery Migration Service

Para migrar almacenes de datos (Teradata, Redshift, Snowflake, Oracle, Hive…) a BigQuery. Cubre cada fase:

• Assess: BigQuery migration assessment (qué tablas, consultas y usos hay).
• Translate SQL: traductor por lotes, interactivo o API, de dialectos SQL a GoogleSQL, con personalización asistida por Gemini.
• Transfer data: con BigQuery Data Transfer Service.
• Validate: herramienta de validación de datos (open source).

Transferencia de datos masivos

Cálculo rápido: 100 TB por un enlace de 1 Gbps efectivo son unos 100 × 8.000 Gb / 1 Gbps ≈ 800.000 s ≈ 9-10 días si el enlace está dedicado al 100 %. Con 10 Gbps, ~1 día. Si el cálculo sale en semanas o meses, o la red se necesita para producción, piensa en Transfer Appliance. La guía oficial de transferencia de datos incluye una tabla con estos tiempos: úsala como referencia.

Planificar red, dependencias, pruebas y olas

Planificación de red

• Direccionamiento IP: define rangos para las VPC que no se solapen con on-premises ni con otras nubes. Un solapamiento impide enrutar por Interconnect o VPN (y el peering de VPC no admite rangos superpuestos).
• Conectividad híbrida según ancho de banda y SLA: HA VPN (rápida de montar, cifrada, ancho de banda moderado), Partner Interconnect (a través de un proveedor), Dedicated Interconnect (circuitos de 10, 100 o 400 Gbps; necesitas presencia en una ubicación de colocation de Google). Cross-Cloud Interconnect para otras nubes.
• DNS híbrido: Cloud DNS con zonas de reenvío y políticas de servidor entrante para resolver nombres en ambos sentidos.
• Salida a internet y seguridad: Cloud NAT, reglas de firewall jerárquicas, Private Google Access.
• Latencia: las aplicaciones «habladoras» que se quedan on-premises y su base de datos se va a la nube pueden degradarse; por eso se migran juntas.

Dependencias

Mapea dependencias (con Migration Center, con flujos de red o con entrevistas) y construye grupos de migración (move groups): conjuntos de aplicaciones y datos que deben moverse a la vez. Reglas prácticas:

• La base de datos y sus aplicaciones más «habladoras», juntas.
• Servicios compartidos (identidad, DNS, monitorización) antes que las aplicaciones.
• Lo que no puede moverse todavía (mainframe, integraciones heredadas) se queda con conectividad híbrida y, si hace falta, una fachada de API (Apigee).

Pruebas de la carga de trabajo

• Funcionales: la app hace lo mismo que antes.
• De rendimiento y carga: con tráfico realista (por ejemplo, con herramientas de carga distribuidas en GKE), comparando con la línea base de on-premises.
• De integración: con sistemas que se quedan fuera.
• De datos: recuentos, sumas de control, validación de esquemas (la herramienta de validación de datos de BigQuery Migration Service, por ejemplo).
• De recuperación: conmutación, restauración de copias, plan de vuelta atrás.
• Clones de prueba de Migrate to VMs y entornos paralelos para validar sin tocar producción.

Olas de migración

Una ola es un lote de grupos de migración que se ejecuta en una ventana. Buenas prácticas:

1. Ola piloto con cargas poco críticas: valida herramientas, procesos y la landing zone.
2. Olas siguientes por prioridad de negocio (por ejemplo, el centro de datos cuyo contrato vence primero, como en EHR Healthcare).
3. Cada ola con criterios de entrada y salida, ventana de corte, comunicación y rollback.
4. Lecciones aprendidas después de cada ola (mejora continua).

gantt
  title Ejemplo de olas de migración
  dateFormat YYYY-MM-DD
  section Base
  Landing zone e identidad      :a1, 2026-10-01, 30d
  Interconnect y DNS            :a2, after a1, 20d
  section Olas
  Ola piloto (cargas no críticas) :b1, after a2, 20d
  Ola 1 (centro con contrato a vencer) :b2, after b1, 45d
  Ola 2 (bases de datos a servicios gestionados) :b3, after b2, 45d
  section Optimizar
  Rightsizing y CUDs            :c1, after b2, 60d

Licencias

Las licencias pueden cambiar por completo el coste de una migración. Lo que el examen espera que sepas:

• Licencias incluidas (pay-as-you-go): imágenes públicas premium de Compute Engine (Windows Server, SQL Server, RHEL, SLES) llevan la licencia en el precio por hora. Sencillo y flexible; puede salir caro en cargas estables.
• BYOL (bring your own license): traer licencias propias. Si el contrato exige hardware dedicado (licencias por núcleo o procesador físico, como Windows Server en muchos contratos), hay que usar sole-tenant nodes (servidores físicos dedicados a tu proyecto), que además permiten controlar y reportar el uso de núcleos físicos. No hay recargo de Google por traer la imagen, pero pagas tus licencias según tu contrato.
• Licencias que no necesitan sole-tenant: según la documentación, los escenarios Linux BYOS con RHEL o SLES y aplicaciones de Microsoft como SQL Server o SharePoint con Microsoft License Mobility (a través de Software Assurance).
• Cloud SQL for SQL Server: la licencia se incluye en el precio del servicio.
• Oracle: opciones actuales en Google Cloud:
  • Oracle Database@Google Cloud: servicios de base de datos de Oracle (Exadata Database Service, Autonomous AI Database, Base Database Service, Exascale, GoldenGate) desplegados en centros de datos de Google Cloud sobre hardware Exadata de OCI, con baja latencia hacia tus cargas en Google Cloud, gestionados desde Google Cloud con IAM.
  • Bare Metal Solution: servidores físicos dedicados en regiones concretas de Google Cloud, conectados con baja latencia, para cargas especializadas (históricamente Oracle con requisitos de licenciamiento o de hardware certificado). Consulta la disponibilidad de regiones: en Europa figuran Londres, Fráncfort y Países Bajos, no Madrid.
  • Replatform a otro motor (PostgreSQL en Cloud SQL o AlloyDB) con DMS heterogéneo si se quiere salir del licenciamiento de Oracle.
• VMware: Google Cloud VMware Engine para seguir con vSphere; revisa el modelo de licencias vigente de VMware con el proveedor.

Impacto financiero

CapEx frente a OpEx

• CapEx (capital expenditure): inversión en activos (servidores, centros de datos) que se amortiza en años. Hay que prever capacidad de pico, que suele estar infrautilizada.
• OpEx (operational expenditure): gasto operativo de pago por uso. La nube convierte CapEx en OpEx: sin inversión inicial, se paga lo que se usa y se escala con la demanda.
• Cuidado: OpEx no significa más barato automáticamente. Una VM encendida 24/7 sin descuentos puede costar más que un servidor amortizado. Por eso se optimiza.

TCO

El TCO compara todos los costes de on-premises (hardware, licencias, energía, refrigeración, espacio, personal, mantenimiento, amortización, costes de oportunidad) con los de la nube (recursos, licencias, red, soporte, formación, coste de la propia migración y periodo de doble ejecución mientras conviven ambos entornos). Herramientas: informes TCO de Migration Center y la calculadora de precios de Google Cloud (cloud.google.com/products/calculator).

Descuentos de Compute Engine

Los CUDs basados en gasto están migrando a un nuevo modelo de consumo basado en descuentos en lugar de créditos: si trabajas con facturación, consulta la página de Spend-based CUDs. Los porcentajes exactos cambian por serie y región: compruébalos en las páginas de precios.

FinOps, etiquetas y facturación

• FinOps es la práctica de gestión financiera de la nube: visibilidad (quién gasta qué), optimización (rightsizing, descuentos, apagar lo que sobra) y responsabilidad compartida entre finanzas, negocio e ingeniería.
• Etiquetas (labels) en los recursos (equipo, entorno, centro-coste) para repartir costes en los informes; tags (etiquetas de recurso con IAM) para políticas condicionales.
• Presupuestos y alertas (budgets) por proyecto o etiqueta, con notificaciones a Pub/Sub para automatizar acciones.
• Exportación de facturación a BigQuery para análisis detallado y cuadros de mando en Data Studio (antes Looker Studio).
• Recomendaciones de Active Assist (VMs ociosas, rightsizing, compromisos) y Gemini Cloud Assist para investigar costes.
• Jerarquía: facturación ligada a proyectos; carpetas por unidad de negocio facilitan el showback/chargeback.

Procesos de negocio (apartado 4.2)

El arquitecto no solo diseña: convence, coordina y acompaña. El examen plantea escenarios donde la respuesta correcta es un proceso, no un producto.

Gestión de stakeholders

• Identifica a los interesados: dirección (patrocinio y presupuesto), finanzas (TCO, CapEx/OpEx), seguridad y cumplimiento, operaciones, desarrollo, negocio, clientes y socios (por ejemplo, los concesionarios de KnightMotives o las aseguradoras de EHR).
• Influye y facilita: presenta opciones con compromisos (coste, riesgo, plazo) en el lenguaje de cada interlocutor; al CFO le hablas de TCO y flujo de caja; al CISO, de controles y responsabilidad compartida.
• Consigue patrocinio ejecutivo (executive sponsorship): el tema Lead del Adoption Framework.

Gestión del cambio

• Comunica qué cambia, por qué y cuándo; involucra pronto a los afectados.
• Cambia procesos, no solo tecnología: por ejemplo, pasar de tickets manuales a infraestructura como código y revisiones de código.
• Usa pilotos y victorias tempranas para generar confianza.
• Mide la adopción y ajusta.

Evaluación del equipo y preparación de habilidades

• Haz un inventario de habilidades (skills assessment) frente a lo que exige la arquitectura objetivo.
• Cierra la brecha con formación (rutas de Google Skills, certificaciones), contratación selectiva, socios de Google Cloud y pairing con expertos.
• Crea un Cloud Center of Excellence (CCoE): equipo transversal que define estándares, plantillas y buenas prácticas.
• Escoge tecnologías acordes a las habilidades cuando el plazo aprieta (por ejemplo, rehost antes que re-architect si el equipo no conoce Kubernetes).

Toma de decisiones

• Decisiones basadas en datos: pruebas de concepto, métricas, comparativas de coste.
• Documenta las decisiones de arquitectura (ADR, architecture decision records) con contexto, opciones y compromisos.
• Define quién decide qué (por ejemplo, un comité de arquitectura para decisiones transversales; los equipos, autonomía dentro de las guardarraíles).

Customer success

Gestionar el éxito del cliente (interno o externo) significa medir si la solución entrega el valor prometido: adopción, satisfacción, incidencias, KPIs de negocio. En Google Cloud, además, existen los Technical Account Managers y los niveles de Customer Care para acompañar a los clientes en producción.

Continuidad de negocio

• Business continuity plan (BCP): cómo sigue funcionando el negocio ante una interrupción; incluye personas, procesos y proveedores, no solo TI.
• Disaster recovery (DR): la parte técnica, con RTO (cuánto tiempo puedo estar caído) y RPO (cuántos datos puedo perder).
• Durante la migración hay riesgos propios: doble escritura, cortes, dependencia de la conectividad híbrida. Planifica rollback y ventanas de corte.

KPIs, métricas de éxito y ROI

La guía pide definir medidas de éxito (success measurements): KPIs, ROI y métricas.

ROI (return on investment) = (beneficio − coste) / coste. El beneficio incluye ahorros (centro de datos, licencias, personal de operación) e ingresos nuevos (conversión, monetización). Presenta el ROI por fases, con supuestos explícitos.

Visión de futuro: cloud-first y mejora continua (apartado 1.5)

• Cloud-first: para cada nueva necesidad, la opción por defecto es un servicio gestionado o serverless en la nube; solo se justifica otra cosa por un motivo concreto (latencia on-premises, regulación, coste). Diseña pensando en automatización, elasticidad y servicios gestionados desde el principio.
• Evolución de las necesidades de negocio: diseña con acoplamiento débil (APIs, eventos con Pub/Sub), para cambiar piezas sin romper el resto; deja puntos de extensión para IA (datos en BigQuery, APIs expuestas con Apigee).
• Mejoras tecnológicas de la nube: los productos cambian rápido (el cambio de Vertex AI a Gemini Enterprise Agent Platform en 2026 es un buen ejemplo). Revisa periódicamente la arquitectura con el Well-Architected Framework y las notas de versión, y planifica la adopción de novedades (nuevas series de máquinas, modelos más baratos, servicios gestionados que sustituyen a los autogestionados).
• Mejora continua: ciclos de revisión de coste, rendimiento y fiabilidad (postmortems sin culpables, revisiones de SLO, FinOps mensual).

Método para resolver los casos de estudio

Los cuatro casos oficiales están resumidos y analizados en su propia página: Altostrat Media, Cymbal Retail, EHR Healthcare y KnightMotives Automotive. En el examen el caso aparece en un panel junto a las preguntas: puedes consultarlo, pero no tendrás tiempo de leerlo con calma. Por eso tienes que llegar con ellos estudiados.

Antes del examen (preparación)

1. Lee cada PDF oficial en inglés al menos dos veces. El examen usa exactamente esas palabras.
2. Para cada caso, construye una tabla requisito → servicio → motivo. Si un requisito no tiene servicio asignado, falta algo en tu diseño.
3. Dibuja la arquitectura objetivo y el plan de migración (qué se queda, qué se mueve, en qué orden).
4. Localiza las frases prioritarias: «reliability and cost management are our top priorities» (Altostrat), «lease about to expire» (EHR), «security is a paramount concern» (KnightMotives), «human-in-the-loop» (Cymbal).
5. Anota las restricciones: sistemas que no se tocan, presupuesto, habilidades, regulación.

Durante el examen (cada pregunta de caso)

1. Lee primero la pregunta, no el caso: ¿qué se pide exactamente (qué hacer primero, qué servicio, cómo reducir coste)?
2. Identifica el requisito del caso al que alude la pregunta. Muchas veces la pregunta repite una frase del caso.
3. Filtra por restricciones del caso: si EHR dice que las integraciones heredadas no se tocan, descarta cualquier opción que las migre o reescriba.
4. Aplica la prioridad declarada: si dos opciones funcionan, gana la que encaja con la prioridad del directivo (coste, fiabilidad, seguridad, rapidez).
5. Prefiere lo gestionado y lo más sencillo que cumpla todos los requisitos. Descarta soluciones que añadan operación sin necesidad.
6. Comprueba que la opción no rompe nada: cumplimiento, residencia de datos, disponibilidad.

flowchart TD
  Q["Lee la pregunta"] --> R["¿Qué requisito del caso toca?"]
  R --> C["¿Qué restricciones del caso aplican?"]
  C --> F["Descarta opciones que las violan"]
  F --> P["Entre las que quedan: la que mejor encaja con la prioridad declarada"]
  P --> M["Desempate: más gestionada, más sencilla, menos coste operativo"]

Trampas típicas del examen

• «Primero» es evaluar: inventario y dependencias con Migration Center antes de mover nada.
• Plazo corto → rehost. Refactorizar antes de que venza el contrato del centro de datos es la trampa.
• «Sin cambiar nada de VMware» → Google Cloud VMware Engine, no Migrate to VMs.
• Mínimo downtime en bases de datos → DMS continuo (CDC), no exportar/importar.
• Terabytes a petabytes con red lenta → Transfer Appliance. Desde otra nube → Storage Transfer Service.
• Almacén de datos a BigQuery con miles de consultas → BigQuery Migration Service (traducción SQL).
• BYOL con hardware dedicado → sole-tenant nodes. SQL Server con License Mobility no lo necesita.
• Oracle sin reescribir → Oracle Database@Google Cloud o Bare Metal Solution. Oracle para quitar licencias → DMS heterogéneo a PostgreSQL/AlloyDB.
• SUDs son automáticos y no aplican a E2; CUDs exigen compromiso de 1 o 3 años.
• Solapamiento de IP con on-premises rompe la conectividad híbrida: se planifica en la fase de base.
• Respuestas «de personas»: formación, patrocinio ejecutivo, pilotos y comunicación suelen ser correctas cuando el problema es de adopción o resistencia al cambio; comprar más tecnología, no.
• CRM, ERP, correo → buy (repurchase). Diferenciación → build.

Resumen

• La migración sigue cuatro fases: assess, plan, deploy, optimize, y es un proceso iterativo.
• Las «R» van de menos a más esfuerzo: retire, retain, rehost, replatform, repurchase, refactor, re-architect, rebuild; la disposición de negocio es build, buy, modify, deprecate.
• Migration Center descubre, evalúa, calcula TCO y dependencias; Migrate to VMs hace rehost; Migrate to Containers, replatform a GKE; DMS, bases de datos a Cloud SQL y AlloyDB; BigQuery Migration Service, almacenes de datos.
• Datos masivos: Storage Transfer Service por red, Transfer Appliance físicamente.
• Planifica IP sin solapes, dependencias en grupos de migración, olas con piloto, pruebas y rollback.
• Licencias: BYOL con sole-tenant nodes si hay hardware dedicado; Oracle Database@Google Cloud / Bare Metal Solution para Oracle.
• Finanzas: CapEx → OpEx, TCO, SUDs automáticos, CUDs por compromiso, Spot para lo tolerante, FinOps con etiquetas, presupuestos y exportación a BigQuery.
• Procesos: stakeholders, gestión del cambio, evaluación de habilidades, CCoE, decisiones documentadas, continuidad de negocio.
• Mide el éxito con KPIs ligados a los requisitos y ROI por fases.
• En los casos: pregunta → requisito → restricciones → prioridad declarada → opción gestionada y sencilla.

Practica lo aprendido

Documentación oficial para ampliar

• Migrate to Google Cloud: Get started
• Migration Center overview
• Migrate to Virtual Machines
• Database Migration Service overview
• Introduction to BigQuery migration
• Migrate to Google Cloud: Transfer your large datasets
• Bringing your own licenses (sole-tenant nodes)
• Committed use discounts
• Oracle Database@Google Cloud overview