Cambio de partner Microsoft Azure
Cambiar de partner Azure sin perder control de costes, seguridad ni continuidad
Revisa suscripciones, accesos, operación, FinOps, seguridad, soporte y evolución antes de trasladar responsabilidades.
Cambiar de partner Azure no es mover una factura de un proveedor a otro. En una plataforma cloud empresarial puede haber suscripciones críticas, identidades, redes, copias de seguridad, automatizaciones, repositorios, políticas, servicios gestionados, integraciones y responsabilidades de soporte repartidas entre varias organizaciones. Si el cambio se plantea sin conocer esas dependencias, la empresa puede conservar todos sus recursos y perder, sin embargo, una parte importante del control operativo.
Ayesa aborda la transición desde una revisión completa del entorno actual: modelo contractual y de suministro, tenant y suscripciones, roles RBAC, Azure Lighthouse, arquitectura, seguridad, monitorización, continuidad, consumo, reservas, savings plans, etiquetado, incidencias abiertas y capacidad de evolución. El objetivo no es prometer una migración gratuita ni un ahorro automático. Es determinar qué debe protegerse, qué riesgos deben resolverse y qué modelo de servicio permite operar Azure con mayor transparencia.
Cuando el proyecto cumple los requisitos, también se revisa el posible encaje en Azure Accelerate, créditos, inversiones para la ejecución o asistencia de despliegue de Microsoft. Siempre sujeto a elegibilidad, alcance, aprobación y disponibilidad. La financiación puede facilitar la transición o la modernización, pero nunca sustituye un diagnóstico técnico y económico serio.
Una decisión de gobierno cloud
Cambiar de partner Azure no significa necesariamente cambiar de nube.
Muchas empresas llegan a esta decisión porque Azure funciona, pero el modelo de relación ya no funciona. El consumo aumenta sin una explicación clara, el soporte se limita a reenviar incidencias, las decisiones de arquitectura dependen de una sola persona o nadie puede responder de forma sencilla quién controla las suscripciones, los permisos, las reservas o los procedimientos de recuperación.
En otros casos, la plataforma ha crecido por proyectos aislados. Cada equipo creó recursos, redes, automatizaciones y cuentas con criterios distintos. El partner actual conoce algunas piezas, pero no existe una visión completa del conjunto. Cambiar de proveedor puede ser la oportunidad para ordenar ese mapa, aunque no sea necesario trasladar ninguna carga de trabajo.
La cuestión central no es si Azure debe seguir siendo la plataforma. La cuestión es si el modelo actual permite gobernarla, protegerla, optimizarla y evolucionarla con la velocidad y el nivel de control que necesita el negocio.
La pregunta correcta
¿Tu partner Azure administra recursos o se responsabiliza de resultados, riesgo y evolución?
Un servicio cloud útil debe conectar arquitectura, operación, seguridad, costes y prioridades de negocio. Cuando cada conversación termina en una herramienta distinta o en un nuevo ticket, la empresa conserva la tecnología, pero pierde capacidad de decisión.
Señales que justifican una revisión
No hace falta esperar a una caída, una brecha o una factura imposible de explicar.
Una única señal crítica puede ser suficiente. Varias a la vez indican que el problema ya no es una incidencia puntual, sino la forma en la que Azure está siendo administrado, soportado y evolucionado.
El consumo crece sin una explicación útil
Se reciben informes generales, pero no se identifica qué aplicación, servicio, área o decisión está generando el incremento ni quién debe actuar.
No está claro quién controla las suscripciones
Existen propietarios históricos, accesos privilegiados, cuentas externas o relaciones delegadas que nadie revisa de forma periódica.
El soporte rebota entre equipos
Infraestructura, red, aplicación, seguridad y Microsoft se pasan la responsabilidad mientras el negocio sigue esperando una solución.
Hay recursos sin dueño ni propósito
Máquinas, discos, IP, copias, entornos y servicios continúan consumiendo porque nadie sabe si pueden retirarse o qué proceso depende de ellos.
Las copias existen, pero no se prueban
La organización da por hecho que podrá recuperar, aunque no existen evidencias recientes, responsables claros o pruebas alineadas con los tiempos que exige el negocio.
La seguridad depende de configuraciones aisladas
No hay una visión común de identidad, políticas, exposición pública, vulnerabilidades, secretos, registros, Defender for Cloud y respuesta ante incidentes.
La plataforma no evoluciona
Azure se usa como alojamiento, pero no existe una estrategia para modernizar aplicaciones, datos, automatización, observabilidad o inteligencia artificial.
La relación comercial es opaca
No se entiende el modelo contractual, la responsabilidad del partner, el soporte incluido, los compromisos, las renovaciones o el margen de decisión del cliente.
Antes de mover responsabilidades
Doce áreas que deben revisarse para saber qué se está asumiendo.
El diagnóstico inicial reduce incertidumbre. También evita dos errores frecuentes: infravalorar el esfuerzo porque “todo está en Azure” y sobredimensionar la transición como si fuera necesario reconstruir la plataforma completa. La revisión debe separar continuidad inmediata, riesgo técnico, deuda operativa y oportunidades de mejora.
1. Tenant, contratos y modelo de suministro
Se identifica quién mantiene la relación comercial, cómo se adquiere el consumo, qué acuerdos existen, qué fechas o compromisos condicionan el cambio y qué funciones presta realmente el partner. Cambiar la operación, el soporte o la optimización no siempre exige modificar de inmediato el canal de suministro. Ambas decisiones deben analizarse por separado para evitar interrupciones o duplicidades.
2. Suscripciones y grupos de administración
Hay que inventariar suscripciones activas, finalidad, propietario, estado, relación con áreas o aplicaciones y ubicación dentro de los grupos de administración. Esta estructura determina cómo se aplican políticas, roles, presupuestos y controles. Una suscripción sin responsable no es solo un problema de orden: puede generar coste, exposición y decisiones contradictorias.
3. Identidad, RBAC y acceso delegado
Se revisan roles privilegiados, grupos, cuentas de servicio, identidades administradas, usuarios externos, acceso de proveedores y posibles delegaciones mediante Azure Lighthouse. El objetivo es que la empresa conozca quién puede ver, modificar, desplegar, eliminar o facturar recursos. La transición debe aplicar mínimo privilegio y retirar accesos que ya no están justificados.
4. Landing zone, políticas y estándares
Se analiza si existe una landing zone coherente, qué Azure Policies están activas, cómo se aplican naming, regiones permitidas, cifrado, logging, etiquetado y controles de despliegue. En entornos que han crecido sin una base común puede ser necesario corregir progresivamente el gobierno, sin bloquear la operación ni convertir cada excepción histórica en una emergencia.
5. Red, conectividad y exposición
Deben entenderse redes virtuales, peering, DNS, VPN, ExpressRoute si existe, firewalls, balanceadores, puertas de enlace, endpoints privados y exposición pública. Muchas incidencias que parecen de aplicación tienen origen en conectividad, resolución de nombres o reglas de seguridad. La toma de servicio necesita un mapa operativo y responsables claros.
6. Seguridad y postura de riesgo
Se revisan Defender for Cloud, recomendaciones, vulnerabilidades, exposición, cifrado, Key Vault, secretos, identidad, registros y respuesta ante incidentes. La transición no debe limitarse a comprobar que los recursos continúan disponibles. También debe identificar riesgos que el servicio anterior no estaba gestionando o comunicando de manera suficiente.
7. Monitorización y observabilidad
Hay que determinar qué se monitoriza, dónde se almacenan logs, qué alertas existen, quién las recibe, cómo se priorizan y qué información necesita negocio. Un exceso de alertas sin contexto puede ser tan inútil como no tener ninguna. La observabilidad debe permitir detectar, investigar y aprender, no únicamente generar correos automáticos.
8. Backup, recuperación y resiliencia
Se identifican políticas de copia, retención, replicación, recuperación, dependencias, objetivos de tiempo y punto de recuperación y evidencias de pruebas. También se revisa qué ocurre si falla una región, un servicio, una identidad o una integración crítica. La continuidad debe definirse según impacto de negocio, no según la disponibilidad genérica del proveedor cloud.
9. Costes, reservas y savings plans
Se revisan tendencias, anomalías, recursos infrautilizados, apagados, rightsizing, almacenamiento, transferencia, licencias, reservas y savings plans. El objetivo no es reducir a ciegas, sino relacionar consumo con servicio, propietario y valor. FinOps requiere responsabilidad compartida: tecnología puede detectar oportunidades, pero negocio debe decidir qué capacidad y nivel de servicio necesita.
10. Automatización, código y despliegue
Se localizan repositorios, pipelines, plantillas de infraestructura como código, automatizaciones, scripts, credenciales y procesos de despliegue. Un recurso visible en el portal no explica cómo fue creado ni cómo debe modificarse. La transición debe evitar que la plataforma dependa de un repositorio, una cuenta o un procedimiento que solo controla el proveedor saliente.
11. Incidencias, cambios y deuda operativa
Se recopilan tickets abiertos, problemas recurrentes, cambios pendientes, workarounds, tareas manuales y compromisos previos. Esto permite decidir qué debe cerrar el partner saliente, qué asumirá el nuevo servicio y qué requiere una mejora estructural. Sin esta lista, la nueva relación puede empezar heredando frustraciones que nadie ha clasificado.
12. Roadmap de modernización, datos e IA
Una vez entendida la plataforma, se valora qué cargas deben permanecer, modernizarse, retirarse o conectarse con nuevos servicios. El cambio de partner puede abrir una conversación sobre PaaS, contenedores, bases de datos gestionadas, integración, datos, Fabric, Azure AI y agentes. La prioridad es evitar que la operación diaria bloquee cualquier evolución futura.
El riesgo real
Lo peligroso no es cambiar de partner. Es descubrir durante el cambio todo lo que nadie había documentado.
Azure permite operar con gran flexibilidad, pero esa flexibilidad también facilita que la complejidad quede repartida entre portales, scripts, identidades, repositorios, equipos y proveedores. Una transición que solo revisa la lista de suscripciones puede pasar por alto la verdadera arquitectura operativa.
El plan debe incluir inventario, propietarios, accesos, transferencia de conocimiento, procedimientos, criterios de aceptación, contingencias y un periodo de estabilización. El objetivo es que el nuevo equipo pueda responder sin depender de llamadas urgentes al proveedor anterior.
Cómo se realiza la toma de servicio
Una transición Azure necesita etapas, responsables y criterios de salida.
El esfuerzo depende del número de suscripciones, la criticidad, la dispersión, el nivel de automatización y la documentación disponible. El método debe adaptarse al entorno, pero no debería omitir los controles esenciales.
Alineación, alcance y gobierno
Se definen patrocinador, interlocutores, perímetro, objetivos, fechas críticas, restricciones, responsabilidades del cliente y del partner, forma de escalar decisiones y relación con el proveedor saliente. También se aclara si el cambio afecta al suministro, a la administración, al soporte, a CloudOps, a FinOps o a varias capas a la vez.
Descubrimiento e inventario
Se obtiene visibilidad sobre tenants, grupos de administración, suscripciones, recursos, redes, identidades, políticas, costes, monitorización, copias, automatizaciones e integraciones. La información del portal se completa con entrevistas, repositorios, documentación y validación de responsables para identificar dependencias invisibles.
Acceso controlado y transferencia
Se conceden permisos de forma gradual y trazable, se revisan relaciones delegadas y se organizan sesiones de conocimiento por áreas críticas. La transferencia debe producir documentación reutilizable: operación recurrente, arquitectura, alertas, recuperación, despliegue, costes, contactos, excepciones y decisiones conocidas.
Plan de continuidad y cutover
Se acuerda el momento de responsabilidad efectiva, tratamiento de tickets, canales, escalados, guardias si aplican, soporte de Microsoft, contingencias y comunicación a equipos internos. Aunque no exista migración técnica, hay un cambio operativo que debe tener una fecha, un propietario y criterios de aceptación.
Estabilización y seguimiento intensivo
Durante las primeras semanas se revisan incidencias, alertas, trabajos periódicos, costes anómalos, copias, cambios, accesos y dudas. El objetivo es confirmar que el nuevo equipo opera con autonomía, completar lagunas y corregir los riesgos más urgentes sin mezclar estabilización con una transformación masiva.
Roadmap de optimización y modernización
Con el servicio estabilizado se priorizan acciones por impacto, urgencia, coste y dependencia: rightsizing, reservas, seguridad, políticas, resiliencia, observabilidad, automatización, modernización de aplicaciones, datos e IA. La empresa obtiene una hoja de ruta defendible y no una lista interminable de recomendaciones técnicas.
CloudOps y soporte
Operar Azure no es mantener recursos encendidos.
Un modelo CloudOps útil combina monitorización, atención de incidencias, gestión de cambios, capacidad, continuidad, seguridad, mantenimiento y seguimiento. Debe existir una forma clara de distinguir una alerta técnica de un problema de negocio, escalar cuando intervienen varias disciplinas y comunicar impacto y resolución.
También debe quedar claro qué corresponde al cliente, qué asume Ayesa, qué depende de Microsoft y qué pertenece a terceros. Sin esa matriz, una incidencia crítica puede consumir horas en decidir quién debe actuar antes de iniciar el diagnóstico.
El cambio de partner es una oportunidad para convertir un soporte reactivo en una operación gobernada, medible y conectada con la evolución de la plataforma.
FinOps y control económico
Reducir coste sin entender el servicio puede salir muy caro.
FinOps no consiste en buscar máquinas grandes y hacerlas pequeñas. Consiste en relacionar consumo, arquitectura, nivel de servicio, responsabilidad y valor. Un recurso aparentemente caro puede proteger un proceso crítico; otro aparentemente pequeño puede acumular coste durante años sin que nadie lo utilice.
La revisión debe incluir presupuestos, anomalías, etiquetado, derechos de acceso a costes, reservas, savings plans, rightsizing, horarios, almacenamiento, transferencia, entornos no productivos y capacidad de asignar consumo a responsables.
La meta no es lograr una bajada puntual para la presentación del comité. Es construir un mecanismo que permita decidir, medir y corregir cada mes.
Qué puede cambiar realmente
Cuatro capas distintas que no siempre deben moverse al mismo tiempo.
La expresión “cambiar de partner Azure” suele mezclar decisiones diferentes. Separarlas ayuda a reducir riesgo y evita modificar relaciones que todavía cumplen su función.
Suministro y relación comercial
Quién suministra el consumo, cómo se factura, qué acuerdo existe, qué compromisos aplican y cómo se tramitan determinados servicios. Puede mantenerse mientras cambia la operación, o modificarse como parte de un plan coordinado.
Administración y gobierno
Quién tiene permisos, aplica políticas, gestiona suscripciones, controla identidades, mantiene landing zones y autoriza cambios. Esta capa determina el control efectivo del entorno.
CloudOps, soporte y seguridad
Quién monitoriza, atiende, investiga, recupera, aplica cambios y coordina incidencias. Puede asumirla un equipo distinto del proveedor comercial si existen permisos y responsabilidades bien definidos.
FinOps, modernización e innovación
Quién optimiza costes, revisa arquitectura, moderniza aplicaciones, prepara datos, diseña automatización e impulsa IA. Es la capa que evita que Azure se convierta únicamente en infraestructura alojada.
Inversiones y recursos Microsoft
Azure Accelerate puede reducir barreras, pero la elegibilidad debe comprobarse proyecto a proyecto.
Microsoft ofrece mecanismos para acelerar determinados proyectos de migración, modernización, datos e inteligencia artificial. Según el escenario, pueden existir inversiones para la ejecución del partner, créditos Azure, assessments, pilotos o asistencia de despliegue mediante Cloud Accelerate Factory.
No todos los clientes ni todos los proyectos cumplen los requisitos. La disponibilidad depende del alcance, el consumo esperado, la fase, el país, la aprobación y la ausencia de duplicidades con otras inversiones. Por eso Ayesa revisa el posible encaje después de entender el proyecto, no como una promesa comercial previa al diagnóstico.
Cuando existe elegibilidad, estos recursos pueden ayudar a financiar parte del assessment, la planificación, el piloto, la migración, la modernización o la puesta en marcha. Cuando no existe, la propuesta debe seguir teniendo sentido por su impacto en coste, seguridad, continuidad y capacidad de evolución.
Qué recibe la empresa
Una visión ejecutiva para decidir si cambiar, cómo hacerlo y qué priorizar después.
La revisión inicial convierte percepciones difusas en un mapa de decisiones. “Azure es caro”, “el soporte no funciona” o “dependemos demasiado del partner” no son todavía diagnósticos. Hace falta identificar causas, riesgos, alcance y opciones.
Qué no debería prometer ningún partner
Una transición inmediata, ahorro garantizado y financiación asegurada sin haber visto el entorno.
El plazo depende de la complejidad, la colaboración disponible, los accesos, la documentación y la criticidad. El ahorro depende de consumo, compromisos, arquitectura y decisiones del negocio. La inversión Microsoft depende de elegibilidad y aprobación.
Un partner serio puede explicar el método, identificar oportunidades y establecer hipótesis. No debería convertir esas hipótesis en garantías comerciales antes del diagnóstico.
Ayesa plantea una primera revisión para conocer el escenario y decidir el siguiente paso útil, incluso cuando la conclusión sea mantener temporalmente parte del modelo actual.
Por qué Ayesa
Capacidad para conectar operación, FinOps, seguridad, datos, aplicaciones e IA.
Ayesa Digital combina una práctica Microsoft especializada con capacidades en infraestructura, aplicaciones, ciberseguridad, datos, inteligencia artificial, automatización, ERP, CRM y Microsoft 365. Esta visión es relevante porque los problemas Azure rara vez permanecen dentro de una única disciplina.
Una incidencia puede tener origen en identidad, red, código, base de datos, permisos o integración. Una decisión de costes puede afectar a rendimiento y continuidad. Un proyecto de IA puede exigir cambios en datos, seguridad y operación. La capacidad end to end permite tratar el problema completo y no únicamente la parte visible en el portal.
El cambio puede comenzar por soporte o control de costes y evolucionar hacia modernización, datos o IA cuando exista una base estable. No es necesario forzar toda la transformación a la vez, pero sí resulta útil contar con capacidad para acompañarla.
Cómo elegir al nuevo partner
No compares solo precio por hora o descuento sobre consumo. Compara capacidad para asumir responsabilidad.
El proveedor más barato puede resultar caro si necesita escalar cada incidencia, desconoce las aplicaciones que dependen de Azure o no puede coordinar seguridad, redes, datos y desarrollo. La selección debe valorar cómo trabaja el equipo, qué visibilidad ofrece y qué ocurre cuando el problema no cabe dentro de una única categoría técnica.
Equipo y cobertura real
Pregunta qué perfiles atenderán el servicio, cómo se cubren ausencias, qué capacidad existe en red, seguridad, bases de datos, aplicaciones, DevOps y soporte Microsoft. Un modelo que depende de una sola persona reproduce el mismo riesgo con otro nombre.
Método de toma de servicio
Solicita una explicación concreta de cómo se descubrirán recursos, accesos, costes, copias, alertas, automatizaciones y dependencias. Una propuesta que pasa directamente al mantenimiento mensual probablemente está ignorando la complejidad del punto de partida.
Gobierno y transparencia
Debe quedar claro qué indicadores recibirá el cliente, cómo se priorizan incidencias, cómo se aprueban cambios, quién explica el consumo y con qué frecuencia se revisan riesgos, niveles de servicio, capacidad y oportunidades de optimización.
Experiencia comparable
No basta con acreditar conocimiento general de Azure. El partner debe comprender escenarios parecidos en criticidad, regulación, volumen, hibridación, países, aplicaciones, datos y dependencia operativa. La experiencia relevante reduce incertidumbre y acelera decisiones.
Capacidad de modernización
Aunque la prioridad inicial sea estabilizar, conviene saber si el partner puede acompañar PaaS, datos, integración, contenedores, automatización, seguridad e IA. Cambiar otra vez cuando llegue el siguiente proyecto añade coste y vuelve a fragmentar el conocimiento.
Responsabilidad compartida
El cliente también debe asignar responsables, facilitar información, validar prioridades y tomar decisiones. Un partner competente no sustituye el gobierno interno: lo estructura, lo hace visible y ayuda a que cada parte asuma la responsabilidad que le corresponde.
Criterio de decisión
El nuevo partner debe demostrar que puede entender el entorno, proteger la operación, explicar los costes, responder ante incidentes y construir una evolución que el negocio pueda gobernar.
Preguntas frecuentes
Lo que conviene aclarar antes de cambiar de partner Azure.
¿Cambiar de partner Azure obliga a migrar los recursos?
No necesariamente. En muchos casos los recursos permanecen en el mismo tenant y las mismas suscripciones. Lo que cambia es quién administra, soporta, optimiza o acompaña la evolución. Si también debe cambiar el modelo comercial o la estructura de suscripciones, se analiza como una decisión adicional y coordinada.
¿Puede interrumpirse el servicio durante la transición?
El objetivo es evitar impactos relevantes. Para ello se revisan accesos, arquitectura, procesos críticos, monitorización, incidencias, calendarios, copias y contingencias antes de asumir la responsabilidad. El riesgo aumenta cuando la documentación es escasa o existen dependencias no identificadas, por lo que el descubrimiento inicial es fundamental.
¿Es posible cambiar solo el soporte y mantener el proveedor de consumo?
Sí, según el modelo contractual y los permisos disponibles. La relación comercial, la administración, el soporte, CloudOps, FinOps y la modernización son capas diferentes. La revisión sirve para decidir qué debe cambiar y qué puede mantenerse sin aumentar complejidad ni diluir responsabilidades.
¿Ayesa puede reducir el coste de Azure?
La revisión puede detectar oportunidades en rightsizing, recursos inactivos, horarios, almacenamiento, reservas, savings plans, arquitectura o licencias. El resultado depende del entorno y de las decisiones de nivel de servicio. No sería responsable garantizar un porcentaje de ahorro sin analizar consumo, compromisos, aplicaciones y criticidad.
¿Qué ocurre con Azure Lighthouse y los accesos del partner anterior?
Deben inventariarse y revisarse como parte del cambio. La empresa necesita saber qué delegaciones existen, qué roles conceden y qué accesos deben mantenerse temporalmente, sustituirse o retirarse. El cierre debe producirse de forma controlada para no eliminar antes de tiempo una capacidad necesaria para la continuidad.
¿Los fondos de Microsoft están garantizados?
No. Azure Accelerate y otros recursos dependen de elegibilidad, alcance, consumo esperado, fase, región, aprobación y disponibilidad. Ayesa puede revisar el encaje y tramitar el escenario correspondiente cuando proceda, pero la página no debe interpretarse como una garantía de financiación ni de créditos.
¿Cambiar de partner es un buen momento para modernizar?
Puede serlo, pero no siempre debe hacerse a la vez. En entornos complejos suele ser más prudente estabilizar primero, resolver riesgos y construir un roadmap. En otros casos, la obsolescencia o el coste justifican combinar transición y modernización. El diagnóstico ayuda a decidir la secuencia adecuada.
¿Cuánto tiempo requiere la toma de servicio?
Depende del número de suscripciones, criticidad, documentación, integraciones, automatización, colaboración del proveedor anterior y nivel de cobertura requerido. La estimación responsable se realiza después de una primera revisión. Prometer un plazo cerrado sin conocer el entorno suele significar que se está infravalorando el trabajo.
¿Qué información conviene preparar para la primera conversación?
Número aproximado de tenants y suscripciones, consumo mensual, servicios críticos, modelo contractual, proveedor actual, principales incidencias, herramientas de monitorización, expectativas de soporte, proyectos previstos y motivo principal del cambio. No es necesario disponer de toda la documentación para empezar, pero sí explicar qué preocupa y qué resultado necesita el negocio.
Continúa la evaluación
Recursos relacionados para decidir, migrar, optimizar y evolucionar Azure.
Microsoft Azure para empresas
La visión de Ayesa sobre cloud, seguridad, datos, aplicaciones e inteligencia artificial en Azure.
Azure Xperience
Migración, arquitectura, seguridad, optimización y servicios para convertir Azure en una plataforma útil.
Migración a la nube
Costes, riesgos, retorno, escenarios y criterios para decidir qué debe moverse y qué debe modernizarse.
Qué migrar primero a Azure
Una guía para priorizar cargas, evitar movimientos sin retorno y construir una hoja de ruta realista.
Azure + IA empresarial
Cómo preparar arquitectura, datos, integración y seguridad para agentes inteligentes e IA en producción.
Customer Care
Continuidad, incidencias, evolución, conocimiento y seguimiento dentro de un modelo de soporte gobernado.
Business Value
Un método para conectar decisiones de cloud, coste, riesgo, modernización e IA con objetivos defendibles.
Cambiar de partner Microsoft 365
Licencias, tenant, soporte, seguridad, administración y preparación para Copilot sin perder continuidad.
Revisión del entorno Azure
Antes de cambiar de partner Azure, conviene saber qué debes proteger, ordenar y optimizar.
Cuéntanos cuántas suscripciones tienes, el consumo aproximado, los servicios críticos, el modelo actual y la razón por la que estás valorando un cambio. La primera conversación permite determinar si el problema está en soporte, administración, seguridad, costes, continuidad, capacidad de evolución o una combinación de varias áreas.
También revisaremos si existe un proyecto de migración o modernización que pueda encajar en Azure Accelerate u otros recursos disponibles, siempre sujeto a elegibilidad y aprobación.
Solicita una revisión inicial
Indica el número aproximado de suscripciones, el consumo si lo conoces, el servicio principal afectado y qué esperas mejorar con el cambio.