Un equipo decide agregar "Login con Microsoft" a su SaaS un viernes por la tarde. Tienen otros tres proveedores de identidad ya integrados, todos resueltos en menos de una hora cada uno. Esto debería ser igual.
Cuatro horas después, ese mismo equipo está atrapado entre tres consolas distintas, una cuenta que dice no tener permisos sobre el recurso que ella misma creó, un validador de email que rechaza el alias del dominio corporativo, y una pantalla azul que repite el mismo error sin ofrecer ningún camino de salida. Nadie hizo nada mal. Cumplieron la documentación oficial. La plataforma simplemente está rota — y lo está hace años.
Esto no es una anécdota aislada. Es la experiencia reproducible de adoptar Azure en 2026. Y al desarmarla, el patrón que aparece no es el de un producto con bugs aislados, sino el de un producto donde la mala UX cumple una función económica. La pregunta no es por qué Azure no se arregla. La pregunta es por qué Microsoft no tiene incentivos para arreglarlo.
Recursos que mueren sin avisar
El primer golpe llega cuando intentás volver a un recurso que dejaste de usar por unos meses. La consola te muestra una pantalla con un código de error, un trace ID y un mensaje que dice que el recurso fue bloqueado por inactividad. La política existe, está documentada en aka.ms/TenantLifecycle, y el código de error AADSTS5000225 aparece en cientos de hilos de soporte público. Pero nunca recibiste un correo previo. Nunca hubo una alerta en la consola. El recurso pasó de funcionar a estar bloqueado sin un solo intento de comunicación.
Lo mismo aplica a las cuentas Microsoft personales: la política oficial las marca para eliminación tras dos años de inactividad. Cuentas con datos, con compras de juegos, con licencias de software, con contactos de Outlook — todo desaparece con un único correo de aviso días antes del corte. La carga de mantener esos recursos vivos recae enteramente en el usuario.
El contraste con otros proveedores cloud es directo. Cuando una cuenta de AWS pasa por debajo del umbral de uso, el equipo de billing manda múltiples correos durante semanas, ofrece extender períodos gratuitos, y nunca rompe el flujo del usuario sin contexto. La diferencia no es técnica — es cultural. Un proveedor decidió que avisar es parte de su trabajo. El otro decidió que no.
Principio: Una plataforma que rompe tus recursos sin avisar te está diciendo dónde te ubica en su lista de prioridades.
Errores que no llevan a ninguna parte
El segundo golpe es el patrón de UX que todos los usuarios de Azure aprenden a reconocer: pantalla azul, código de error con prefijo críptico, trace ID, correlation ID, timestamp, y un único botón "Try again" que vuelve al mismo error.
Es un anti-patrón clásico de diseño de producto. Cuando un sistema falla, la UI tiene tres responsabilidades: explicar qué pasó, indicar quién puede arreglarlo, y ofrecer al menos un siguiente paso accionable. Las consolas de Microsoft cumplen la primera, ignoran las otras dos.
El daño compuesto es enorme. Cada error te empuja a abrir una pestaña nueva, googlear el código, leer hilos de soporte de hace cinco años, y reconstruir el camino mental que la plataforma debería haberte mostrado. Multiplicado por el volumen de tareas que hace un dev en una semana, es un impuesto silencioso a la productividad.
El equivalente en otros proveedores no es perfecto, pero es radicalmente mejor. Los errores de IAM en AWS te dicen qué política falta y dónde verla. Los errores de DNS en Cloudflare te muestran el registro problemático y un enlace al editor. Los errores de OAuth en Google Identity te explican qué scope falta y cómo agregarlo. Esa diferencia no es accidental: refleja una decisión de producto sobre quién absorbe el costo del fallo.
Principio: Un mensaje de error sin acción accionable no es un error — es una orden de buscar ayuda en otro lado.
Validadores rotos desde 2010
Cuando intentás registrarte con un alias de tu dominio corporativo —un email perfectamente válido bajo la RFC 5321, soportado por todos los proveedores de mail desde hace décadas— el formulario lo rechaza. El carácter + en la parte local del email viola el validador de Microsoft. Hay que usar puntos, alias formales, o mails alternativos.
Es un detalle minúsculo. Y exactamente por eso es tan revelador.
Un validador de email que rechaza + en 2026 es un fósil. Es código que nadie revisa, en un flujo crítico (registro de usuario nuevo), que afecta a cualquier dev que use Gmail, Workspace u Outlook con subdirecciones. El equipo de producto tuvo años para arreglarlo. Hilos de queja existen desde 2010. Sigue así.
Cuando un detalle pequeño y trivial de arreglar lleva década y media sin resolverse, no es porque el equipo no lo sepa. Es porque nadie en la empresa tiene como objetivo de carrera arreglar la fricción de los nuevos usuarios. El sistema de incentivos internos no los premia por eso.
Principio: Los detalles que llevan años rotos no son errores — son señales de qué le importa a la empresa.
Fragmentación deliberada
El cuarto golpe llega cuando descubrís que la plataforma no tiene una consola, sino tres. Cada una con responsabilidades parcialmente solapadas, navegación inconsistente, y links cruzados que te redirigen a la consola equivocada según el contexto. Para tareas comunes hay que aprender en cuál de las tres vive cada opción, y aceptar que la respuesta cambia con el tiempo cuando los equipos de producto reorganizan menús.
Sumá a eso la fragmentación de identidades: cuenta personal, cuenta de trabajo, tenant, suscripción, dominio, organización. Seis conceptos distintos que el onboarding nunca explica. Un usuario que crea su primera cuenta no entiende que la dirección de email con la que se registró pertenece a un "tenant" diferente del "tenant" donde están los recursos que va a usar, y que esa distinción puede romper permisos sin previo aviso.
El contraste es directo. Otros proveedores cloud tienen una consola principal y, como mucho, una consola separada para billing. La identidad se modela con dos o tres conceptos claros (cuenta, usuario, rol), no con seis. La fragmentación no es una necesidad técnica — es una elección de producto.
Principio: Cuando un producto requiere que aprendas su organigrama interno para usarlo, el problema no es tu falta de experiencia.
El bug del propio admin
El quinto golpe es el más absurdo. Creás un recurso. Sos el único usuario en él. Y al intentar abrir un menú dentro de ese recurso, la plataforma te dice que no tenés permisos.
El bug es conocido, está reportado en foros oficiales desde hace años, y afecta especialmente a flujos donde el primer admin se registra con una cuenta de un dominio corporativo gestionado por otro proveedor de identidad. El onboarding crea el recurso pero falla en asignar correctamente los roles administrativos al usuario que lo creó. El resultado: una cuenta sin acceso a su propio recurso, sin un camino claro para repararlo desde la UI.
La solución oficial suele involucrar abrir un ticket de soporte, esperar 24 a 72 horas, o eliminar el recurso y empezar de cero con otra identidad. Ninguna de las dos opciones es aceptable para un dev que ya invirtió tiempo en el setup. Y ninguna de las dos opciones existiría si el flujo de onboarding hubiera sido testeado en serio antes de salir a producción.
Principio: Si una plataforma no testea el camino de su propio onboarding, no esperés que testee el resto.
Esto no son bugs, es modelo de negocio
Pasados los cinco pitfalls, una pregunta razonable es: ¿cómo es posible que un proveedor de esta escala mantenga este nivel de fricción durante tantos años?
La respuesta no es incompetencia. Es economía. Microsoft tiene dos tipos de cliente para Azure, y la mala UX afecta a uno mucho más que al otro.
El cliente enterprise paga contratos de soporte premium que pueden ir de 25.000 a 250.000 dólares anuales, tiene un Technical Account Manager asignado, y delega buena parte de la fricción a consultoras especializadas. Para ellos, los errores sin acción accionable se transforman en un ticket que alguien resuelve por ellos a cambio de horas facturables. La mala UX es, literalmente, el motor del negocio de servicios profesionales que rodea a Azure.
El dev independiente, la startup, el equipo pequeño que evalúa la plataforma sin contrato premium, absorben el costo en tiempo y frustración. Microsoft no pierde dinero cuando ese segmento se traba — al contrario, alimenta la demanda de TAMs, partners certificados y consultoras. La empresa tiene un incentivo financiero claro para que la consola sea apenas usable sin ayuda profesional.
Este patrón no es exclusivo de Azure. Aparece en otros productos del catálogo. Teams fue forzosamente desbundlado de Microsoft 365 en la Unión Europea en 2023 tras una investigación antimonopolio que encontró prácticas anticompetitivas. Edge inserta diálogos disuasivos cuando el usuario intenta instalar Chrome. OneDrive empuja popups agresivos de sign-in en Windows incluso para usuarios que eligieron explícitamente no usarlo. Skype fue cerrado de forma programada para empujar a sus usuarios hacia Teams. Windows Recall, en 2024, intentó habilitar por defecto una función que captura screenshots periódicas del usuario sin un opt-in claro, hasta que la presión pública obligó a revisar el flujo. Cada uno de estos casos siguió el mismo patrón: maximizar lock-in y minimizar fricciones de salida, aún a costa de la confianza del usuario.
Cuando un patrón se repite en cinco productos distintos durante dos décadas, ya no es un accidente de diseño. Es la cultura corporativa expresándose en código.
Principio: Un producto refleja la cultura de la empresa que lo construye. Ningún rediseño parcial cambia eso.
Por qué AWS sigue siendo la apuesta segura
El contraste no es ideológico, es operativo. AWS también tiene errores, también tiene una consola que en algunas zonas envejeció mal, también cobra soporte premium caro. Pero la diferencia estructural es que AWS nació de Amazon, donde "customer obsession" es el primer principio de liderazgo de la empresa, repetido en cada onboarding interno desde hace 25 años. Esa diferencia cultural se traduce en decisiones concretas que el usuario nota cada día.
Los errores de IAM te dicen qué política falta. Las facturas inesperadas se pueden disputar y AWS frecuentemente las cancela. El soporte gratuito incluye las preguntas de cuenta y billing — no necesitás contrato premium para que alguien te explique por qué te suspendieron una cuenta. Las políticas de ciclo de vida sobre recursos llegan con avisos múltiples antes de cualquier acción destructiva. La documentación es navegable, los SDKs son consistentes entre lenguajes, y un dev solo puede armar una arquitectura completa sin necesitar un consultor certificado de por medio.
Eso no significa que AWS sea perfecto, ni que cada equipo tenga que migrar mañana. Significa que cuando estás eligiendo cloud para tu próximo proyecto, la decisión que parece técnica (qué servicios ofrece cada uno, qué precios tiene cada uno) está dominada por una variable cultural mucho más predictiva: cuánto te respeta el proveedor cuando algo se rompe. Por ese eje, AWS sigue ganando con margen amplio.
Antes de tu próxima decisión cloud
Si estás evaluando Azure para tu SaaS, tu producto interno, o tu próxima migración, llevate este checklist:
- Probá el flujo de error antes de comprometerte. Borrá un secret, malformá una URL de callback, dejá un recurso inactivo. Mirá qué te dice la plataforma cuando algo se rompe — no cuando todo funciona.
- Leé las políticas de ciclo de vida de cada recurso que vas a crear. Si la plataforma puede destruir tu trabajo sin notificación previa, ese costo va a llegar tarde o temprano.
- Contá cuántas consolas de administración tiene el producto. Más de dos es señal de equipos internos en conflicto, y de fricción que vas a heredar.
- Probá el registro con un email de un dominio corporativo y con un alias. Si el validador rechaza casos básicos, asumí que el resto del producto va a tener el mismo nivel de cuidado.
- Buscá el producto en foros de soporte y filtrá por hilos sin resolver de hace más de dos años. Si encontrás muchos, esos bugs no se van a arreglar mientras vos seas el dueño del recurso.
- Calculá el costo en horas de fricción esperadas, no sólo en dólares por hora de cómputo. Una hora perdida por semana, durante tres años, son 156 horas. Multiplicá por el costo cargado de tu equipo y comparalo con la diferencia de pricing entre proveedores.
El costo real de un cloud no se mide en la página de pricing. Se mide en cuántas veces al mes vas a pelear con la plataforma para hacer cosas que en otra plataforma simplemente funcionan. Por ese cálculo, Azure es caro aunque sea gratis.
Azure por dentro: cuando los errores no son bugs, son cultura corporativa