Servicios de migración a Azure para empresas

Sí; partimos de la Enterprise-Scale Landing Zone del Cloud Adoption Framework de Microsoft y personalizamos, sin escribir nunca una landing zone desde cero. Desplegamos con el Terraform AVM (Azure Verified Modules) oficial o con Bicep cuando el cliente prefiere herramientas nativas de Microsoft. Las personalizaciones son deliberadas: jerarquía de grupos de administración alineada con sus unidades de negocio (no con los valores por defecto de Microsoft), iniciativas de Azure Policy para la fijación de región y los bloqueos de recursos, Defender for Cloud en nivel Standard en todas las suscripciones y una topología de vNet hub-spoke con Azure Firewall Premium en el hub. La identidad es Entra ID (antes Azure AD) con Privileged Identity Management obligatorio para cualquier rol por encima de Reader en las suscripciones de producción.

Azure Migrate para la evaluación y el mapeo de dependencias es realmente bueno, con agente o sin agente según su enfoque de seguridad. Lo usamos como fuente principal para el rightsizing de VM y la puntuación de compatibilidad de SQL Server a SQL MI. Donde se queda corto es en las dependencias de la capa de aplicación de los monolitos distribuidos, así que lo complementamos con datos de Movere cuando están disponibles, o montamos nuestro propio trazado ligero basado en eBPF durante dos semanas para capturar el tráfico este-oeste. El resultado es un único grafo de dependencias unificado que guía la planificación de las oleadas, no tres hojas de cálculo que compiten entre sí.

Las cargas de trabajo con datos personales de la UE aterrizan en West Europe (Países Bajos), North Europe (Irlanda), Sweden Central o France Central según las necesidades de latencia y soberanía. Usamos Azure Policy a nivel de grupo de administración para denegar la creación de recursos fuera de las regiones aprobadas: un desarrollador no puede aprovisionar por accidente en East US. Para Schrems II usamos Customer Lockbox, Confidential Computing (Intel SGX / AMD SEV-SNP) en SKU DCasv5/ECasv5 para cargas atestables, claves gestionadas por el cliente en Azure Key Vault HSM (o Azure Key Vault Managed HSM FIPS 140-2 Level 3) y SCC en el DPA. El compromiso de EU Data Boundary de Microsoft se aplica a nivel de etiqueta de suscripción y se audita cada mes.

La decisión depende de la capacidad del equipo, no de la moda arquitectónica. Las capas web sin estado que no necesitan malla de sidecars ni redes personalizadas van a App Service o a Azure Container Apps (con Dapr cuando ya tenemos patrones dirigidos por eventos). Todo lo que tenga complejidad regulatoria, requisitos de aislamiento multi-tenant o una necesidad real de service mesh va a AKS, con Azure CNI Overlay, el complemento Azure Policy, Workload Identity (no pod identity) y un equivalente de Karpenter mediante NAP (Node Auto Provisioning, actualmente en preview pero listo para producción en nuestra experiencia). SQL Server se consolida en Azure SQL Managed Instance mediante migración online con DMS con inactividad casi nula; PostgreSQL va a Azure Database for PostgreSQL Flexible Server.

Exportaciones de Cost Management + Billing a ADLS Gen2 y después Synapse o Fabric para la analítica, no Power BI en bruto sobre la API, que aplica límites de peticiones. La política de etiquetado se aplica mediante Azure Policy con reglas de denegación si falta una etiqueta: centro de coste, entorno, id de app, propietario. La cadencia de FinOps es semanal: rightsizing con Azure Advisor, seguimiento de la cobertura de Reserved Instance y Savings Plan, Hybrid Benefit aplicado siempre que las licencias de Windows Server / SQL Server lo permiten (ahorro típico del 40 % solo en esos SKU) y VM Spot en AKS para cargas por lotes. El ahorro típico del primer año frente a la línea base de lift-and-shift es del 25–35 %.

Precios en USD de alcance cerrado y todo incluido: servicios individuales desde $200, un lift-and-shift desde $1,800, un re-platform desde $4,100 y una salida completa de AWS/Azure/GCP desde $5,800. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de escribir una sola línea de código; sin recargo por intermediación, sin sobrecostes por herramientas y con los costes de la nube en sus propias cuentas, de modo que conserva el control del coste. Los plazos dependen del tamaño del parque: un parque de 250 VM con consolidación de SQL Server suele completarse en 5–7 meses de extremo a extremo, con los cutovers de SQL MI y las oleadas de replatform a AKS presupuestados por oleada.

Las bases de datos son lo que más preocupa a los clientes, así que por defecto usamos la migración online con Azure Database Migration Service: la replicación continua se ejecuta mientras el origen sigue activo, y el cutover real es una breve ventana de mantenimiento medida en minutos, no en horas. Para SQL Server a SQL Managed Instance usamos el modo online de DMS con Log Replay Service como alternativa para casos límite; en bases de datos muy grandes o con mucho tráfico añadimos un puente de replicación transaccional para que el delta en el cutover sea despreciable. Cada cutover tiene un runbook de rollback por escrito y un paso de validación del rendimiento frente a la línea base previa a la migración antes de dirigir el tráfico de producción a la nueva instancia. Si la validación falla, revertimos y reprogramamos; nunca dejamos una base de datos a medio migrar en producción.

Sí, y en clientes regulados o industriales suele ser la respuesta correcta. Conectamos el entorno on-premise con Azure mediante ExpressRoute (o VPN de sitio a sitio para parques más pequeños), ampliamos la identidad con Entra ID Connect y gestionamos los recursos on-premise y de Azure a través de un único plano de control con Azure Arc, de modo que los servidores, clústeres de Kubernetes e instancias de SQL fuera de Azure también reciben Azure Policy, Defender for Cloud y la gestión de actualizaciones. Eso le permite trasladar a Azure la analítica, el ERP y las capas de cara al cliente mientras MES, SCADA o los sistemas de control sensibles a la latencia permanecen en la planta. La landing zone CAF se diseña para ese límite híbrido desde el principio y no se adapta después.

La recuperación ante desastres (DR) forma parte de la landing zone, no es un añadido posterior. Las VM usan Azure Backup con retención aplicada por política y, cuando el RPO/RTO lo exige, Azure Site Recovery para la conmutación por error entre regiones con runbooks documentados y probados. Azure SQL Managed Instance funciona con configuraciones redundantes entre zonas o con replicación geográfica según el nivel, y PostgreSQL Flexible Server con alta disponibilidad y réplicas de lectura entre regiones. Fijamos los objetivos de RPO y RTO por carga de trabajo durante el descubrimiento, los asignamos al nivel de resiliencia adecuado para que no pague redundancia geográfica en una máquina de desarrollo, y realizamos al menos un simulacro de conmutación antes del traspaso para que el runbook esté demostrado y no sea teórico.

Sí; de nube a nube es una parte importante de nuestro trabajo. El descubrimiento es el mismo ejercicio de las 7R, pero las palancas son distintas: mapeamos los equivalentes de servicios gestionados (RDS a Azure SQL MI o PostgreSQL Flex, EKS/GKE a AKS, S3 a Blob/ADLS Gen2, Lambda a Functions o Container Apps), reexpresamos la IaC (estado de Terraform migrado, CloudFormation reconstruido en Bicep o Terraform AVM) y planificamos con cuidado la salida de datos porque la nube de origen la factura. Como contenedorizamos y definimos todo como código, el mismo proyecto le deja portable en lugar de cambiar una dependencia por otra; ese es el entregable explícito de nuestro modelo «Exit AWS/Azure/GCP».

Sí, y es uno de los argumentos de coste más sólidos para migrar. Las cargas de trabajo que no se pueden actualizar en el sitio antes de una fecha de fin de soporte obtienen Extended Security Updates gratuitas cuando se ejecutan en Azure (en VM de Azure, Azure VMware Solution o híbrido habilitado con Arc), lo que da tiempo para hacer el replatform como es debido en lugar de pagar ESU on-premise. En la práctica hacemos primero el lift-and-shift de los servidores en riesgo para eliminar la exposición de seguridad y después el replatform de la base de datos a Azure SQL Managed Instance (que es evergreen, así que el reloj del fin de soporte se detiene por completo) en una oleada de seguimiento rápido. Hybrid Benefit sobre esas mismas licencias suele compensar buena parte del coste de cómputo.

Todos los proyectos terminan con una guardia en sombra de 30 días: su equipo asume las operaciones mientras nosotros seguimos en el puente de incidentes, de modo que la transferencia de conocimiento es real y no una presentación. Después puede asumir la propiedad total (runbooks, IaC y paneles son todos suyos) o continuar con una iguala de servicios gestionados que cubre el mantenimiento del secure score de Defender, auditorías mensuales de Hybrid Benefit y Reserved Instance, optimización de FinOps y actualizaciones de la plataforma. No hay ninguna cláusula de dependencia del proveedor: como el parque sigue el estándar CAF y está definido en código, otro socio (o sus propias contrataciones) puede retomarlo sin reconstruirlo.