Migración segura a Microsoft Azure (2025): guía extensa paso a paso con landing zones, red híbrida, seguridad, costes y operación

Migración a Microsoft Azure: contexto, objetivos y resultados

Migrar a la nube ya no es solo trasladar máquinas virtuales. Es reordenar arquitectura, responsabilidades y controles para que la operación diaria sea más predecible. Azure aporta servicios administrados, automatización nativa y observabilidad integrada; pero esos beneficios aparecen cuando la plataforma está bien diseñada y el cambio se ejecuta en oleadas con pruebas y métricas.

El primer objetivo es reducir riesgo: menos exposición pública, identidades con privilegios temporales y datos cifrados por defecto. El segundo, garantizar continuidad con copias inmutables y simulacros. El tercero, gobernar el gasto con presupuestos, etiquetas y compromisos de consumo. A la par, se busca mejorar la experiencia: despliegues repetibles, diagnósticos claros y menos trabajos manuales.

Cloud Adoption Framework (CAF) y estrategias 8R para migrar a Azure

CAF ordena el viaje en seis fases: estrategia, plan, preparación (ready), adopción (adopt), gobierno y operación. Ayuda a decidir qué se migra, cómo se medirá el éxito y qué controles son obligatorios. No es teoría: aporta plantillas y decisiones tipo que se convierten en entregables reales (políticas, topologías, repositorios).

La decisión por aplicación se sostiene en las “8R”: retirar, retener, rehost, replatform, refactor, rearchitect, rebuild o replace. No hay una única respuesta; suelen convivir varias. Por ejemplo, un ERP con dependencias fuertes comienza como rehost (IaaS) para liberar el CPD, mientras que portales o APIs con buena capa de pruebas pueden pasar directamente a replatform (App Service, PostgreSQL Flexible).

Azure Landing Zones: plataforma, gobierno y seguridad desde el inicio

Una landing zone es la “pista de aterrizaje” de los recursos. Define jerarquía de management groups, suscripciones por entorno, red troncal (hub), diagnósticos, políticas y automatización. La ventaja es que todo “nace” con los mismos guardrails: si se prohíben IP públicas para bases de datos, nadie podrá crearlas por error.

La implementación práctica usa infraestructura como código (Bicep/Terraform) en un repositorio con ramas, revisiones y versiones. Un pipeline despliega la plataforma en dev, pre y prod. Los cambios quedan trazados y reversibles. Esto, además de orden, aporta velocidad: crear una suscripción nueva con todas las políticas y diagnósticos configurados pasa a ser una tarea de minutos.

• Estructura de management groups por dominios y entornos.
• Hub-and-spoke con Firewall/Azure Gateway, DNS privado y salida controlada a Internet.
• Asignación de iniciativas de seguridad y cumplimiento en el MG raíz.
• Registros obligatorios a Log Analytics y catálogos de alertas base.
• Plantillas de suscripción y etiquetas obligatorias (cost center, owner, app, entorno).

Principios y áreas de diseño de una Azure Landing Zone

Las áreas de diseño de CAF funcionan como una lista de comprobación. Permiten tomar decisiones explícitas sobre identidad, suscripciones, redes, seguridad, operaciones, costes y automatización. Cuando todo está escrito, los equipos no dependen de “cómo se hizo la última vez”, sino de criterios publicados.

Esta tabla se convierte en tareas en un backlog: crear las políticas, desplegar el DNS privado, definir etiquetas obligatorias, escribir los runbooks de operación. Así, gobierno y plataforma avanzan a la par.

Conectividad híbrida en Azure: ExpressRoute, VPN, Private Link y DNS

La red es el pegamento entre lo que ya funciona y lo que se despliega en la nube. A alto nivel, hay dos caminos hacia Azure: VPN (IPsec) y ExpressRoute. La VPN permite empezar en días y cuesta poco; ExpressRoute aporta conexiones privadas con garantías de ancho de banda y latencia. Muchas organizaciones emplean VPN para el arranque y dejan ExpressRoute para cuando la carga crece o se requiere estabilidad.

Con los servicios PaaS, el salto de calidad llega con Private Link, que crea private endpoints en redes internas. Se deja de exponer un nombre público y el tráfico va por la VNet. Para que funcione de forma transparente, se usa Private DNS y una estrategia de resolución dividida: el mismo nombre responde a IP privada dentro de la red y a IP pública fuera, si fuese necesario. Este patrón evita fugas y cumple requisitos estrictos.

El patrón de hub-and-spoke centraliza los controles: el hub aloja el Firewall, los gateways y el DNS; los spokes son espacios de aplicación. El tráfico se enruta de forma explícita, no se deja “pasar todo”. Si un equipo crea un recurso inseguro, el recorrido de red no le permitirá salir a Internet sin pasar por reglas conocidas.

Seguridad de identidad: Entra ID, Acceso Condicional, PIM y Managed Identities

La identidad es la puerta de entrada a todo. El plan mínimo de seguridad combina MFA universal, Acceso Condicional por riesgo y contexto, y PIM para que los roles altos se activen solo cuando hace falta y con aprobación. Conviene empezar con Acceso Condicional en “solo informe”, ver qué rompería en producción y ajustar. Después, se activa en “imposición” por grupos.

Para aplicaciones y automatizaciones, las Managed Identities evitan contraseñas. La aplicación se identifica contra Azure y obtiene tokens que le permiten hablar con Key Vault, Storage o SQL sin credenciales en texto claro. Este cambio reduce incidentes y simplifica auditorías.

Gobierno y cumplimiento: Azure Policy + Microsoft Cloud Security Benchmark

El benchmark de seguridad de Microsoft recoge controles transversales (identidad, datos, redes, registro, respuesta). Defender for Cloud calcula una puntuación de seguridad, propone remediaciones y permite seguir el progreso. Azure Policy es el “motor” que aplica la configuración: audita, corrige e incluso impide crear recursos fuera de norma.

Un enfoque eficaz es trabajar por sprints quincenales. Se seleccionan diez recomendaciones de alto impacto (por ejemplo, cerrar IP públicas de bases de datos, forzar TLS actual, activar diagnósticos obligatorios), se crean políticas o asignaciones y se miden ganancias. Las excepciones se aprueban con fecha de fin y responsable; si vence el plazo, la excepción se revisa o se cierra.

Protección de datos: Key Vault, CMEK, gestión de secretos y almacenamiento

Key Vault custodia secretos, certificados y claves con control de acceso y registro. Se recomienda un Key Vault por aplicación y por entorno; así, si ocurre un problema, se limita el impacto. Con Private Endpoint, el cofre deja de depender de accesos públicos.

Cuando los servicios lo admiten, CMEK permite usar claves propias para cifrar datos, cumpliendo requisitos de clientes regulados. Las claves se rotan y se documenta la cadencia de rotación. En Storage, la elección de redundancia (LRS, ZRS, GRS, GZRS) se hace con los objetivos de RTO/RPO y el presupuesto sobre la mesa; los contenedores sensibles se exponen por red privada y se minimiza el uso de firmas SAS de larga duración.

Azure Migrate: inventario, evaluación y migración por oleadas

Azure Migrate descubre lo que hay, mide cómo funciona y propone tamaños realistas. El appliance recoge CPU, memoria, disco y red durante varias semanas. Con datos suficientes, las evaluaciones performance-based recomiendan series de VM y discos ajustados. Esta simple decisión técnica (dimensionar por rendimiento, no por fichas antiguas) suele ahorrar costes sin afectar servicio.

Cómo implementarlo con orden

1. Crear el proyecto de Migrate y desplegar el appliance donde están las cargas (VMware, Hyper-V o físico).
2. Verificar credenciales y puertos; iniciar la recopilación y revisar dependencias entre servidores.
3. Ejecutar evaluaciones basadas en rendimiento con márgenes para picos reales.
4. Elegir tres cargas representativas para el piloto: una web, una base de datos y un proceso por lotes.
5. Definir oleadas por dominio de negocio con ventanas, pruebas de humo y plan de reversión.

La réplica prepara el cambio final con interrupción mínima. Tras un mes en Azure, se ejecuta rightsizing y se decide el uso de reservas y savings plans. Ese es el momento de afinar coste con datos reales.

Datos y bases de datos: SQL Managed Instance, SQL Database y PostgreSQL/MySQL

Para SQL Server, Managed Instance aporta compatibilidad amplia con características on-prem (agentes, Linked Servers en ciertos escenarios) sin la carga de parches del sistema operativo. SQL Database encaja donde la aplicación puede asumir un modelo PaaS con escalado elástico y alta disponibilidad gestionada. En código abierto, PostgreSQL/MySQL Flexible Server ofrece alta disponibilidad zonal y control de versión y mantenimiento.

La conectividad privada con Private Link y el uso de Azure AD authentication (cuando aplica) reducen exposición y simplifican la retirada de credenciales locales. Antes del corte, es recomendable ejecutar pruebas A/B con las consultas pesadas, registrar planes de ejecución y ajustar niveles de servicio.

Modernización de aplicaciones: App Service, AKS, contenedores y WAF

App Service simplifica el ciclo de vida de aplicaciones web y APIs: despliegues repetibles, ranuras (slots) para blue/green, diagnósticos detallados y escalado automático. Cuando la aplicación ya está contenedorizada o necesita un control más fino de recursos, AKS permite grupos de nodos por tipo de trabajo, ingress con WAF y autoscaling por métricas de aplicación.

En ambos casos, Managed Identity para acceder a dependencias y Private Link para llegar a datos sin salir a Internet. El pipeline de CI/CD incorpora análisis de dependencias, escaneo de imágenes y pruebas de salud reales; si falla algo, el despliegue se detiene antes de afectar a clientes.

Disaster Recovery: Azure Backup inmutable y Azure Site Recovery

Las copias de seguridad deben resistir errores humanos y ataques. La opción de enhanced soft delete en Azure Backup evita desactivar la protección y dificulta borrados maliciosos. Combinado con bloqueo del vault y roles segregados, aporta una barrera real.

Azure Site Recovery replica máquinas a otra región y permite pruebas de conmutación controladas. Los simulacros se ejecutan en redes aisladas y generan un acta con tiempos y resultados. Esa evidencia vale más que cualquier promesa en un documento: demuestra recuperación.

Postura y detección: Defender for Cloud, Azure Monitor y Microsoft Sentinel

Defender for Cloud da una visión transversal de la postura y de riesgos explotables. Se priorizan acciones de alto impacto y se mide la mejora. Azure Monitor y el agente moderno (AMA) recogen métricas y logs en Log Analytics; se crean reglas de recopilación para normalizar qué datos envía cada recurso. Sentinel conecta esas señales, aplica analíticas y automatiza respuestas.

SigninLogs | where ResultType == 0 | where Identity matches regex ".*(admin|adm).*" | where hour_of_day(TimeGenerated) < 7 or hour_of_day(TimeGenerated) > 20 | summarize intentos=count() by Identity, bin(TimeGenerated, 1h)

Con reglas como la anterior se detectan inicios de sesión administrativos fuera de horario y se lanza un playbook para forzar MFA adicional o revocar tokens. Una biblioteca corta de respuestas bien hechas resuelve la mayoría de incidentes repetitivos.

FinOps: Cost Management, presupuestos, reservas y savings plans

Cost Management permite crear presupuestos por suscripción o grupo de recursos, alertas por umbral y vistas por etiqueta (centro de coste, propietario, entorno). Después de estabilizar el consumo se aplican reservas para recursos concretos (por ejemplo, un tipo de base de datos) y savings plans para cómputo con variedad de servicios. La regla práctica: primero dimensionar bien, luego comprometer consumo.

Cada mes conviene revisar la utilización de reservas y savings, identificar recursos huérfanos y ajustar políticas de apagado automático en entornos no productivos. Con esa disciplina, el gasto deja de sorprender.

Plan de proyecto y criterios de cierre por ola

Una migración ordenada se publica por oleadas con condiciones de paso. No se trata de “acabar la fecha”, sino de cumplir criterios que protegen al negocio: postura mínima, copias probadas, alertas activas y presupuesto bajo control. Así, cada promoción a producción tiene garantías.

1. Descubrimiento: inventario con Migrate, dependencias, criticidad y requisitos.
2. Ready: landing zone como código y políticas asignadas en el MG raíz.
3. Piloto: una muestra variada de cargas para medir latencia, seguridad y DR.
4. Seguridad y BCDR: Acceso Condicional, PIM, Backup inmutable y ASR funcionando.
5. Olas: por dominio de negocio, con runbooks y planes de reversión documentados.

Paso a paso — de cero a producción

1) Plataforma

Desplegar la landing zone con Bicep/Terraform, asignar iniciativas de seguridad en el MG raíz, crear el hub de red con Firewall y DNS, y habilitar diagnósticos hacia Log Analytics con el agente moderno. Publicar la guía de etiquetas y las plantillas de suscripción en el repositorio interno.

2) Identidad

Configurar Acceso Condicional en “solo informe”, revisar impacto y pasar a “imposición” por grupos. Habilitar PIM, documentar cuentas de emergencia y migrar automatizaciones a Managed Identities. Trasladar secretos a Key Vault y rotarlos.

3) Migración

Usar Azure Migrate para inventario y evaluaciones basadas en rendimiento. Ejecutar un piloto con tres cargas y luego publicar por oleadas. Medir latencias, ajustar tamaños y documentar resultados.

4) Continuidad

Activar Backup con enhanced soft delete y bloquear el vault. Configurar Site Recovery entre regiones y realizar pruebas de conmutación periódicas con actas. Definir RTO/RPO por servicio y revisar anualmente.

5) Operación

Activar Defender for Cloud y Sentinel, crear alertas clave y playbooks de respuesta. Establecer presupuestos, revisar gasto mensual y ajustar reservas/savings. Cerrar el ciclo con retrospectivas y mejoras.

Riesgos típicos y mitigación

• Servicios PaaS expuestos: habilitar Private Link y DNS privado; revisar rutas de salida.
• Gobierno débil: asignar iniciativas en el MG raíz; gestionar excepciones con caducidad y responsable.
• Identidad sin controles: Acceso Condicional gradual y PIM en roles críticos; cuentas de emergencia controladas.
• Backups vulnerables: enhanced soft delete y bloqueo del vault; roles segregados.
• Costes imprevistos: etiquetas y presupuestos obligatorios, rightsizing y revisión de reservas/savings mensual.

Preguntas frecuentes

Recursos oficiales

• Cloud Adoption Framework (CAF) — visión general
• Azure Landing Zone — principios y guía
• Áreas de diseño de landing zones
• Microsoft Cloud Security Benchmark
• Azure Migrate — evaluaciones
• Dimensionamiento basado en rendimiento
• Azure Backup — enhanced soft delete
• Site Recovery — prueba de conmutación
• Cost Management y facturación

Conclusión y siguientes pasos

Migrar a Azure con cabeza significa diseñar una plataforma consistente, mover cargas con datos y no por intuición, y cerrar el círculo con seguridad, continuidad y costes bajo control. Con una landing zone como código, conectividad privada, políticas heredadas, copias inmutables y observabilidad unificada, el cliente reduce riesgo, gana velocidad y puede demostrarlo con evidencias.