EWS se apaga en Exchange Online y la migración a Microsoft Graph es urgente antes de abril de 2027

Microsoft ha confirmado una noticia esperada por muchos administradores y desarrolladores: la API Exchange Web Services (EWS) para Exchange Online será desactivada por completo en abril de 2027. Tras casi dos décadas actuando como puente entre aplicaciones y buzones de Exchange, EWS seguirá disponible en instalaciones locales de Exchange Server, pero los buzones alojados en Microsoft 365 deberán dejar de usarla antes de la fecha límite.

La hoja de ruta que ha planteado Microsoft marca dos momentos clave: a partir del 1 de octubre de 2026 EWS quedará bloqueada por defecto en Exchange Online, y el 1 de abril de 2027 se producirá la desconexión definitiva sin excepciones. Microsoft ofrece una ventana de gestión para reducir el impacto: los administradores pueden crear listas de aplicaciones permitidas y, si lo hacen antes de finales de agosto de 2026, su organización quedará excluida de ese primer bloqueo automático.

Si una organización no prepara su propio listado, Microsoft empezará en septiembre de 2026 a generar listas prellenadas basadas en el uso real de cada tenant, con la intención de minimizar interrupciones imprevistas. Además, para identificar dependencias ocultas, la compañía ha anunciado que podría realizar breves apagados controlados —a los que ha llamado coloquialmente “scream tests”— y mantendrá a los administradores informados mediante notificaciones periódicas en el Message Center con resúmenes y recordatorios específicos por tenant. Puedes leer el anuncio oficial y las explicaciones del equipo de Exchange en el blog técnico de Microsoft: Exchange Team (Microsoft Tech Community).

Para entender por qué Microsoft toma esta decisión conviene recordar el papel que EWS ha jugado. Nacida con Exchange Server 2007, EWS permitió construir clientes y herramientas que leen correos, gestionan calendarios y contactos, y realizan operaciones complejas sobre buzones desde plataformas distintas. Con el tiempo, Microsoft ha ido promoviendo Microsoft Graph como la API moderna que integra identidades, correo, calendarios, archivos y muchas otras funciones bajo un único modelo y con mejoras en seguridad y escalabilidad. El proceso de aviso no es nuevo: ya en 2018 Microsoft adelantó cambios y, en 2021, deshabilitó un subconjunto de las llamadas menos usadas por razones de seguridad; puedes consultar aquellos avisos en el TechCommunity: aviso de 2018 y la comunicación de 2021.

¿Qué significa esto para empresas y desarrolladores? En primer lugar, cualquier aplicación que todavía utilice EWS para acceder a buzones en la nube debe planear una migración. Microsoft recomienda cambiar a Microsoft Graph, que ya ofrece paridad de características para la mayoría de escenarios e incluye mejoras de autenticación y control de acceso. La compañía publica guías para ayudar en la migración y en la adaptación de llamadas y permisos: Migrate applications from EWS to Microsoft Graph.

En segundo lugar, los administradores deben auditar y mapear el uso de EWS en su entorno: identificar aplicaciones, scripts y servicios que hacen llamadas EWS, priorizar las más críticas y coordinar pruebas. Microsoft ha facilitado mecanismos de permit listing para dar tiempo a la transición, pero esos mecanismos son temporales. Además, la empresa ofrecerá información automática sobre el uso de EWS por tenant para ayudar a detectar dependencias ocultas antes del bloqueo masivo.

Hay una nota importante para entornos híbridos: la retirada afecta a Exchange Online (la nube). Las instalaciones on-prem seguirán soportando EWS, pero las interacciones entre escenarios híbridos y la nube pueden requerir componentes concretos para que las llamadas a Microsoft Graph funcionen correctamente. Microsoft ha explicado que Autodiscover seguirá siendo la forma de determinar dónde está un buzón, y que los clientes híbridos necesitarán disponer de la infraestructura necesaria para soportar Graph cuando llamen a buzones en la nube; conviene revisar la documentación técnica del fabricante para detalles específicos de cada topología.

Prácticamente, ¿qué deberías hacer ya? La receta es sencilla en su idea: inventario, pruebas y migración. Hacer un inventario exhaustivo de clientes y scripts que usan EWS, priorizar los casos críticos y comenzar a reescribir o adaptar esas integraciones a Microsoft Graph. Aprovechar las herramientas y las guías oficiales para minimizar retrabajos, y planificar ventanas de prueba antes del bloqueo de octubre de 2026. Microsoft ofrece recursos y documentación para desarrolladores en la página de Microsoft Graph; es un buen punto de partida para entender permisos, endpoints y flujos de autenticación: Microsoft Graph documentation.

No conviene confiar en el mecanismo de listas permitidas como solución a largo plazo: son un alivio temporal, no una alternativa permanente. El riesgo está en descubrir dependencias ocultas de forma tardía —por ejemplo, integraciones internas o aplicaciones de terceros que nadie mantiene activamente— y que esos servicios queden fuera de servicio por un bloqueo imprevisto. Por eso Microsoft propone las pruebas controladas y las notificaciones mensuales para que las organizaciones puedan reaccionar con tiempo.

Finalmente, aunque esta transición es técnica, no deja de ser una oportunidad: migrar a Graph suele traer beneficios en seguridad (manejo de permisos más fino, soporte para los estándares modernos de OAuth), en mantenimiento (una única API para muchos servicios) y en posibilidades funcionales (integración más directa con Teams, OneDrive y otros servicios de Microsoft 365). Si tu organización todavía depende de EWS en Exchange Online, conviene tratar el calendario de Microsoft como una fecha límite real y activar recursos para la migración con antelación.

Para más detalles y el panorama oficial, revisa la entrada del equipo de Exchange en el TechCommunity de Microsoft y la guía de migración a Microsoft Graph:

Anuncio del Exchange Team y Guía de migración de EWS a Microsoft Graph.

En resumen: EWS para Exchange Online tiene fecha de caducidad en la nube: prepara inventario, prioriza migraciones y utiliza la ventana de administración que Microsoft ofrece para evitar impactos cuando llegue octubre de 2026 y, definitivamente, abril de 2027.