Elegir un partner Azure por la migración y descubrir después que nadie sabe operar lo que se ha construido
Muchas organizaciones concentran la selección en el momento más visible: assessment, proyecto de migración y cutover. Es lógico, pero incompleto.
Azure empieza a demostrar su valor después: cuando aparecen nuevas cargas, cambian los costes, entra una adquisición, una aplicación necesita modernizarse, seguridad exige nuevos controles, negocio quiere utilizar IA o dirección pregunta por qué la factura cloud ha aumentado un 27%.
El proveedor adecuado no debería desaparecer al terminar la migración. Debe poder explicar cómo quedarán arquitectura, responsabilidades, observabilidad, recuperación, seguridad, costes, soporte y evolución.
Si Azure se convierte en una plataforma crítica, ¿quién responderá por el conjunto?
La nube cruza infraestructura, aplicaciones, identidad, seguridad, redes, datos, costes, continuidad, desarrollo, soporte y cada vez más inteligencia artificial.
Un proveedor puede ejecutar muy bien una migración concreta y no disponer de capacidad para gobernar ese ecosistema durante tres años.
Por eso una RFP debería evaluar la capacidad de ejecutar hoy y la capacidad de sostener mañana.
Define qué problema quieres resolver. “Migrar a Azure” no es un objetivo empresarial.
Cerrar un centro de datos, reducir obsolescencia, mejorar continuidad, integrar una adquisición, modernizar aplicaciones, controlar costes o preparar una plataforma para IA son objetivos distintos. Pueden terminar utilizando Azure, pero requieren decisiones, arquitecturas, secuencias y métricas diferentes.
Salir de un centro de datos
La prioridad puede ser calendario, dependencia contractual, continuidad, sizing, migración por oleadas y retirada ordenada de infraestructura.
Modernizar aplicaciones
La decisión ya no es dónde alojar una máquina virtual, sino qué aplicaciones merece la pena refactorizar, sustituir, contenerizar, integrar o retirar.
Reducir riesgo operativo
Resiliencia, backup, disaster recovery, monitorización, identidad, vulnerabilidades, actualización y procedimientos de respuesta pasan al centro de la evaluación.
Controlar costes cloud
Se necesitan ownership, presupuestos, etiquetado, rightsizing, reservas cuando proceda, eliminación de desperdicio, forecast y un modelo FinOps sostenible.
Preparar datos e IA
La plataforma debe contemplar identidad, seguridad, datos, integración, observabilidad, modelos, agentes, aplicaciones y costes de consumo desde una arquitectura común.
Ordenar un Azure que ya existe
Muchas empresas no empiezan desde cero. Ya tienen suscripciones, recursos, excepciones, costes y aplicaciones en cloud. El reto es gobernar un entorno brownfield sin detenerlo.
15 criterios que debería evaluar una RFP para seleccionar partner Azure
No todos tienen que pesar igual. Una entidad regulada puede dar más peso a seguridad y gobierno. Una compañía que abandona un data center puede priorizar capacidad de migración. Una organización AI-first necesitará mucha más profundidad en datos, integración e IA.
Capacidad para descubrir antes de recomendar
El proveedor debe poder inventariar aplicaciones, infraestructura, dependencias, propietarios, criticidad, rendimiento, costes, contratos y restricciones. Una buena recomendación empieza admitiendo qué información falta.
Economía y TCO, no solo sizing
Pide escenarios comparables que incluyan consumo, licencias, inversiones evitadas, transición, migración, servicios gestionados, reservas cuando proceda y sensibilidad ante cambios de volumen.
Diseño de landing zone y plataforma
Comprueba experiencia en jerarquía, suscripciones, redes, conectividad, identidad, políticas, observabilidad, automatización, continuidad y entornos de aplicación.
Capacidad de ejecutar por oleadas
Pide metodología para discovery, agrupación de cargas, pruebas, rollback, cutover, estabilización, dependencias, retirada del origen y criterios de aceptación.
Saber cuándo no hacer lift & shift
Un buen partner debe distinguir entre rehost, replatform, refactor, replace, retain y retire. Llevar deuda técnica a Azure no la convierte en innovación.
Seguridad integrada desde arquitectura
Identity-first, least privilege, segmentación, postura, amenazas, secretos, cifrado, logging, compliance y respuesta deben formar parte del diseño, no de una fase posterior.
Guardrails que permitan crecer sin perder control
Pregunta cómo se aplicarán políticas, roles, nomenclatura, etiquetado, excepciones, compliance, resource hierarchy y ownership cuando el entorno tenga diez veces más cargas.
Capacidad para operar después del go-live
Monitorización, incidentes, problemas, cambios, patching, backup, capacidad, disponibilidad, runbooks, escalados y continuidad deben tener propietarios y métricas.
Gobierno económico continuo
No basta con optimizar una vez. Pide presupuestos, alertas, allocation, tagging, forecast, rightsizing, compromisos de consumo cuando tengan sentido y revisiones periódicas de coste versus valor.
Infrastructure as Code y operación repetible
La calidad de la plataforma mejora cuando landing zones, políticas, entornos y configuraciones pueden desplegarse de forma consistente y versionada.
Capacidad de conectar infraestructura y plataforma de datos
Si el roadmap incluye analítica, Fabric, integración o IA, pregunta quién diseñará datos, conectividad, seguridad, ownership y observabilidad más allá de la infraestructura.
Preparación para aplicaciones inteligentes y agentes
Un entorno Azure puede terminar soportando Microsoft Foundry, modelos, RAG, agentes, APIs, búsqueda, datos y automatización. Conviene evaluar esa capacidad antes de necesitarla.
Equipo real asignado al proyecto
No puntúes solo logos y certificaciones corporativas. Pide arquitecto, responsables técnicos, seniority, disponibilidad, experiencia sectorial y dependencia de subcontratación.
Referencias comparables
No basta con haber hecho “proyectos Azure”. Busca complejidad comparable: volumen, sector, criticidad, regulación, internacionalización, modernización y modelo operativo.
Capacidad para acompañar el roadmap
El proveedor debería explicar cómo evolucionará de migración a optimización, modernización, datos, automatización e IA sin obligarte a reconstruir la plataforma cada vez.
Cómo ponderaría una RFP Azure para evitar que el precio decida por defecto
La ponderación debe adaptarse al escenario. Pero asignar el 60% de la puntuación a precio y migración suele producir una paradoja: se selecciona al proveedor más competitivo para mover cargas y después se paga durante años la falta de arquitectura, automatización o gobierno.
| Dimensión | Peso orientativo | Qué buscar |
|---|---|---|
| Arquitectura, seguridad y gobierno | 20% | Landing zone, identidad, red, políticas, compliance, resiliencia y capacidad de escalar. |
| Migración y modernización | 20% | Discovery, dependencias, oleadas, cutover, pruebas, refactor, replatform y retirada. |
| Operación y servicios gestionados | 15% | SLA, monitorización, automatización, backup, cambios, incidencias, problemas y mejora continua. |
| FinOps y optimización | 10% | Ownership, tagging, presupuesto, forecast, rightsizing, reservas y coste por servicio. |
| Datos, integración e IA | 10% | Capacidad de evolucionar de infraestructura a plataforma empresarial. |
| Equipo y experiencia | 10% | Perfiles asignados, referencias, certificaciones, continuidad y conocimiento aplicable. |
| Modelo económico | 10% | Transparencia de precios, supuestos, escalado, costes adicionales y TCO. |
| Gobierno de la relación | 5% | Comités, escalado, roadmap, mejora continua y accountability. |
esta ponderación es un punto de partida, no una plantilla universal. En una migración muy acotada el peso de ejecución puede ser mayor. En una plataforma regulada, seguridad y gobierno deberían crecer considerablemente.
Pregunta cómo será la base antes de preguntar qué servidor se migra primero
Una landing zone bien diseñada establece una base común para organizar, gobernar y proteger las cargas de Azure. El objetivo no es construir una arquitectura monumental antes de generar valor, sino evitar que cada nuevo proyecto cree su propia red, sus propias excepciones, su propia seguridad y su propia forma de operar.
La RFP debería obligar al proveedor a explicar cómo organizará management groups, subscriptions, identidad, conectividad, políticas, observabilidad, automatización, continuidad, costes y entornos de aplicación.
También debería explicar qué decisiones se necesitan desde el principio y cuáles pueden madurar después. Sobrediseñar la landing zone puede retrasar meses la adopción. Diseñarla por debajo de las necesidades obliga a rehacerla cuando migrar recursos y políticas ya es mucho más difícil.
Un proveedor serio debería poder decirte qué no merece la pena migrar
Una migración cloud no debería convertirse en un concurso por maximizar el número de máquinas trasladadas. Algunas aplicaciones deberían modernizarse antes, otras pueden sustituirse por SaaS, otras mantenerse temporalmente y algunas deberían retirarse.
El partner debe ser capaz de separar lo técnicamente migrable de lo empresarialmente conveniente.
Azure Migrate permite descubrir y evaluar infraestructura, aplicaciones y datos, pero la herramienta no conoce por sí sola contratos, estacionalidad, dependencia funcional, calendario comercial, procesos críticos o decisiones futuras de negocio.
Ahí entra el valor del assessment: combinar evidencia técnica con contexto empresarial.
Qué exigir para cada oleada
Si seguridad entra después de la migración, entra demasiado tarde
Identidad, privilegios, políticas, segmentación, registros, protección, compliance y respuesta deberían formar parte de las decisiones iniciales de plataforma. No porque cada carga necesite el máximo control posible, sino porque las excepciones son mucho más fáciles de gobernar cuando existe una baseline común.
Lo que debería explicar el proveedor
Cómo plantea identity, RBAC, privileged access, Azure Policy, Defender for Cloud, secretos, logging, network segmentation, backups, recovery, compliance y gestión de vulnerabilidades.
Y, sobre todo, cómo convierte esos controles en prácticas operativas que pueden mantenerse cuando el número de workloads aumenta.
La mala respuesta
“La seguridad la veremos con vuestro equipo de ciberseguridad”.
Puede existir un equipo específico de seguridad, pero arquitectura cloud, red, identidad, plataforma, operaciones y seguridad deben trabajar sobre decisiones comunes. Las fronteras organizativas no eliminan las dependencias técnicas.
El partner no debería limitarse a enviarte una factura Azure que nadie sabe explicar
Cloud transforma parte de la inversión tecnológica en consumo. Eso aporta flexibilidad, pero también exige disciplina.
Cada recurso debería tener propósito, propietario y relación con una aplicación o servicio. Cost Management, presupuestos, alertas, tags, Azure Advisor y procesos FinOps ayudan, pero la herramienta por sí sola no decide quién debe apagar un entorno, quién puede aceptar un sobrecoste o qué KPI de negocio justifica ese consumo.
Por eso la RFP debería preguntar cómo será la conversación mensual sobre coste, no solo qué descuento o reserva puede conseguirse.
KPIs mínimos de gobierno económico
Pregunta qué ocurre el lunes siguiente al cierre del proyecto
La transición a operación debería diseñarse durante el proyecto, no dos semanas antes del go-live. El equipo que recibe la plataforma necesita arquitectura, inventario, runbooks, monitorización, contactos, escalados, acceso, decisiones de diseño, excepciones y conocimiento de las dependencias.
Modelo reactivo
El proveedor responde cuando algo falla.
Puede ser suficiente para cargas poco críticas o equipos internos maduros, pero no debería confundirse con gestión de plataforma.
Modelo operativo
Además de incidencias, cubre monitorización, backups, cambios, mantenimiento, capacidad, actualizaciones y continuidad.
La plataforma tiene responsables claros y procedimientos repetibles.
Modelo de optimización
Operación, FinOps, seguridad, automatización, deuda técnica y mejora continua forman parte de revisiones periódicas.
No se limita a mantener Azure encendido. Busca que funcione mejor y cueste lo que debe.
Modelo de evolución
El partner conecta operación con modernización, datos, IA, nuevas aplicaciones y roadmap empresarial.
La plataforma se convierte en una capacidad de negocio, no en infraestructura gestionada de forma aislada.
Si el roadmap incluye IA, evalúa hoy una capacidad que probablemente necesitarás mañana
Microsoft está integrando Azure con datos, aplicaciones inteligentes y agentes. Eso no significa que todas las empresas tengan que desplegar IA inmediatamente. Significa que decisiones actuales sobre identidad, datos, conectividad, observabilidad, APIs, seguridad y gobierno condicionarán la facilidad con la que esas capacidades podrán incorporarse.
Una empresa que hoy migra aplicaciones puede querer mañana conectarlas con Microsoft Fabric, Microsoft Foundry, Azure AI Search, modelos generativos o agentes capaces de ejecutar tareas.
Si el partner que construye la plataforma inicial no comprende esas capas, la organización puede terminar creando una segunda arquitectura paralela cuando llegue la IA.
25 preguntas que deberían estar en una RFP Azure seria
Cuanto más concreta sea la pregunta, menos espacio habrá para contestar con una presentación comercial reutilizada.
- ¿Cómo validaréis el inventario y las dependencias antes de recomendar una ruta?
- ¿Qué datos necesitáis para construir un business case?
- ¿Cómo decidís entre rehost, replatform, refactor, replace, retain y retire?
- ¿Qué decisiones de landing zone deben cerrarse antes de la primera carga?
- ¿Cómo diseñáis management groups y subscriptions?
- ¿Cómo integraréis identidad híbrida y privilegios?
- ¿Cómo se gestionarán políticas y excepciones?
- ¿Cómo se diseñará conectividad con sedes, data centers y terceros?
- ¿Cómo se automatizará el despliegue de plataforma?
- ¿Qué baseline de seguridad estará activa antes de producción?
- ¿Cómo se probarán backup, restore y disaster recovery?
- ¿Qué métricas utilizaréis para validar rendimiento después del cutover?
- ¿Cómo se agruparán las cargas en oleadas?
- ¿Cuál es el procedimiento de rollback?
- ¿Cuándo consideráis que una migración ha terminado realmente?
- ¿Cómo se transferirá conocimiento a operación?
- ¿Qué SLA proponéis y qué queda excluido?
- ¿Cómo se gestionarán incidentes que crucen varias tecnologías?
- ¿Cómo se controlará y asignará el gasto Azure?
- ¿Qué cadencia FinOps proponéis?
- ¿Qué parte del equipo será propia y qué parte subcontratada?
- ¿Quién será el arquitecto responsable del conjunto?
- ¿Qué referencias tenéis con complejidad comparable?
- ¿Cómo evolucionaréis la plataforma hacia datos, automatización e IA?
- ¿Qué recomendación podríais hacernos que redujese vuestro propio alcance?
La última pregunta es especialmente útil.
Un proveedor maduro debería ser capaz de recomendar retirar una carga, mantenerla donde está, utilizar SaaS o reducir un servicio si es lo mejor para el cliente. Si todas las respuestas aumentan el proyecto, conviene revisar los incentivos.
Diez respuestas que deberían hacerte profundizar antes de adjudicar
Puede tener sentido en casos concretos, pero no como estrategia por defecto.
Las referencias ayudan, pero deben adaptarse al tamaño, riesgo y modelo operativo.
Seguridad puede tener especialistas propios, pero no puede quedar desconectada de arquitectura.
Las herramientas ayudan; ownership y decisiones siguen siendo necesarios.
Ser técnicamente migrable no significa que sea conveniente.
La transición operativa debería formar parte del diseño.
Pregunta qué recursos, horarios, severidades, dependencias y terceros quedan realmente cubiertos.
Bien, pero pide quién trabajará en tu proyecto y qué experiencia tiene.
Puede ser futura, pero algunas decisiones de datos, integración y seguridad conviene prepararlas ahora.
Una metodología es positiva. Una respuesta idéntica para cualquier organización no lo es.
¿Un especialista Azure o un partner end-to-end?
Tampoco aquí existe una única respuesta correcta. La cuestión es cuántas dependencias tendrá Azure con el resto de la organización y quién será responsable de gobernarlas.
Puede ser la opción adecuada cuando el alcance está claramente desacoplado
Por ejemplo, una migración técnica muy concreta, una plataforma independiente o una organización que ya dispone internamente de arquitectura empresarial, seguridad, datos y vendor management.
La especialización puede aportar profundidad y velocidad si las fronteras son reales y están bien gobernadas.
Gana valor cuando Azure atraviesa aplicaciones, datos, seguridad, automatización e IA
Si el programa conecta Dynamics 365, Microsoft 365, Power Platform, Fabric, aplicaciones propias, seguridad, datos o agentes, reducir interfaces entre proveedores puede disminuir considerablemente el trabajo de coordinación.
Pero “end-to-end” debe demostrarse con arquitectura transversal, equipos y referencias, no con un catálogo comercial.
Una propuesta Azure debería poder continuar cuando la conversación deja de ser infraestructura
Ayesa combina capacidades Microsoft en aplicaciones empresariales, Azure, datos e IA, Modern Work, seguridad, Power Platform, integración y servicios gestionados.
La práctica Microsoft cuenta con seis designaciones, seis especializaciones y más de 800 certificaciones Microsoft. Estas credenciales no deberían sustituir la evaluación del equipo, la arquitectura o las referencias concretas, pero ayudan a validar que existe amplitud suficiente para trabajar sobre varias capas de la plataforma.
Para un programa Azure, esa capacidad importa especialmente cuando después de la migración aparecen modernización de aplicaciones, Fabric, Power Platform, Dynamics 365, seguridad, automatización o inteligencia artificial.
Qué conviene aclarar antes de seleccionar un partner Azure
¿Qué debería hacer un partner Azure?
Depende del alcance, pero un partner completo puede participar en assessment, estrategia, arquitectura, landing zone, migración, modernización, seguridad, gobierno, operación, FinOps, datos e IA. La RFP debe especificar qué responsabilidades espera realmente la empresa.
¿Las certificaciones Microsoft son suficientes para elegir proveedor?
No. Son una evidencia útil, pero deben complementarse con equipo asignado, experiencia comparable, referencias, metodología, arquitectura, capacidad operativa y claridad contractual.
¿Qué diferencia hay entre migrar y modernizar?
Migrar cambia la ubicación o plataforma de una carga. Modernizar cambia parte de su arquitectura, tecnología o modelo operativo para mejorar escalabilidad, mantenibilidad, seguridad, velocidad o capacidad de innovación.
¿Hay que modernizar todo durante una migración?
No. Intentar modernizar todas las aplicaciones simultáneamente puede aumentar mucho el riesgo. La secuencia debe priorizar dónde modernizar aporta valor y dónde conviene migrar primero y evolucionar después.
¿Qué es una landing zone Azure?
Es una base arquitectónica para organizar, gobernar, proteger y escalar un entorno Azure con criterios comunes para plataforma y workloads. Incluye decisiones sobre organización, identidad, red, políticas, gestión, seguridad y servicios compartidos.
¿Qué es FinOps?
Es una disciplina de colaboración para que tecnología, finanzas y negocio gestionen el valor económico del cloud. Incluye visibilidad, ownership, presupuestos, previsión, optimización y decisiones sobre consumo.
¿Conviene contratar migración y operación al mismo proveedor?
Puede reducir fricción y pérdida de conocimiento, pero no es obligatorio. Si son proveedores diferentes, la transición debe definirse desde el inicio con documentación, RACI, inventario, accesos, runbooks y criterios de aceptación.
¿Tiene sentido cambiar de partner Azure si la plataforma ya está funcionando?
Sí, si existen problemas relevantes de control, costes, soporte, seguridad, evolución o dependencia. Pero el cambio debería empezar con una baseline objetiva del entorno y una transición ordenada, no con una transformación simultánea de todo.
La evaluación debería apoyarse en marcos y documentación vigente
Microsoft estructura la adopción de Azure alrededor de estrategia, planificación, preparación, adopción, gobierno, seguridad y gestión. También proporciona referencias específicas para landing zones, evaluación con Azure Migrate y gobierno de costes.
No elijas al partner que promete mover más rápido. Elige al que pueda explicar cómo quedará la empresa después.
La migración importa. Pero dirección debería poder ver también qué arquitectura quedará, cómo se gobernará, quién responderá por seguridad y operación, cuánto costará sostenerla, cómo se controlará el consumo, qué capacidad interna necesitará la organización y cómo podrá evolucionar hacia aplicaciones, datos e inteligencia artificial.
Una RFP bien diseñada obliga a que esas respuestas aparezcan antes de firmar y no cuando ya existe dependencia tecnológica y contractual.
¿Estáis preparando una migración, revisando vuestro Azure o buscando un nuevo partner?
Podemos revisar arquitectura actual, aplicaciones, dependencias, seguridad, operación, costes, roadmap y modelo de proveedor para identificar qué criterios deberían pesar realmente en vuestra decisión.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)