EWS desaparece de Exchange Online el 1 de abril de 2027: cómo llevar tus integraciones a Microsoft Graph

Microsoft ha empezado a desactivar Exchange Web Services (EWS) en Exchange Online. Los primeros pasos de aplicación se ejecutan este mes, después se irá desactivando uno a uno en los tenants que nunca tocaron su configuración de EWS, y a partir del 1 de abril de 2027 EWS deja de existir para todos los tenants de Microsoft 365. Microsoft ha dicho claramente que no habrá excepciones más allá de abril de 2027.

Si algo que tu empresa ha construido habla con buzones de Microsoft 365 a través de EWS, deja de funcionar en esa fecha como muy tarde, y posiblemente mucho antes. Los sospechosos habituales: un CRM que archiva los correos de los clientes en sus cuentas, un script de archivo o de retención, una pantalla de reserva de salas de reuniones, un sistema de tiques que lee un buzón compartido de soporte, un informe que cuenta los correos por equipo. La solución es reescribirlo contra Microsoft Graph, y parte de lo que EWS podía hacer no tiene ningún equivalente en Graph.

Qué pasa, fecha a fecha

Microsoft controla EWS por tenant mediante la opción EWSEnabled, que tiene tres valores: Null (el predeterminado), True y False. Junto a ella hay ahora una segunda opción, EWSAllowedAppIDs: una lista de identificadores de aplicación que todavía pueden usar EWS. La página actual de Microsoft Learn da las líneas generales: «Octubre de 2026: EWS empieza a deshabilitarse globalmente para todas las organizaciones» y «Abril de 2027: EWS queda totalmente deshabilitado».

El detalle está en la entrada del equipo de Exchange del 1 de octubre, EWS Deprecation Is Here. Para la nube comercial mundial:

• 2 de octubre de 2026, al final del día en hora del Pacífico: Microsoft registra todos los tenants que tienen EWSEnabled en True pero ninguna lista de permitidos.
• 8 y 9 de octubre de 2026: para esos tenants, Microsoft crea la lista de permitidos y la rellena con los identificadores de las aplicaciones que usaron EWS en los 60 días anteriores.
• Desde el 10 de octubre de 2026: cuando EWSEnabled está en True, la lista de permitidos es obligatoria. Una aplicación que no figure en ella es rechazada.
• Segunda fase, a continuación: a los tenants que sigan en Null se les pone EWSEnabled en False, lo que bloquea EWS para todas las aplicaciones. Cada uno recibe un aviso con 7 días de antelación en el Centro de mensajes, y poco antes Microsoft rellena una lista de permitidos a partir de 60 días de uso, de modo que un administrador puede volver a activar EWS con True.
• 1 de abril de 2027: EWS queda «deshabilitado de forma total y permanente», y los administradores de los tenants pierden la posibilidad de cambiar EWSEnabled.

Los tenants de las demás nubes de Microsoft reciben sus propios calendarios a través del Centro de mensajes.

La lista de permitidos compra tiempo, no es una solución

La lista automática se construye a partir de 60 días de tráfico, y la propia guía de Microsoft del 4 de septiembre advierte de que «puede omitir aplicaciones que se ejecutan con poca frecuencia». Una exportación de cierre de trimestre o un proceso de archivo de fin de año no estarán en ella, y fallarán la próxima vez que se ejecuten.

Los cambios en la lista de permitidos tardan 24 horas en surtir efecto, y los cambios en EWSEnabled, alrededor de una hora. Cualquier arreglo que hagas después de un fallo cuesta al menos un día.

Para ver en qué situación está tu tenant, un administrador con PowerShell de Exchange Online puede ejecutar:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Para quién es esto, y quién puede dejar de leer

Exchange Server local no se ve afectado. Microsoft dice que la retirada se aplica «solo a Microsoft 365 y Exchange Online», y que «no hay cambios en EWS en Exchange Server». Si todos tus buzones están en tus propios servidores, puedes parar aquí.

Las configuraciones híbridas necesitan una revisión más detenida. Los buzones locales pueden seguir usando EWS; los buzones en la nube tienen que pasar a Graph. La entrada de Microsoft sobre entornos híbridos del 30 de septiembre trata dos casos que requieren actuar ya, entre ellos los buzones locales con archivo en Exchange Online, para los que el consejo por ahora es mantener EWS habilitado y añadir la aplicación híbrida a la lista de permitidos.

El software comercial es trabajo del fabricante. Si lo que llama a EWS es un producto comercial, sacar una versión para Graph le toca al fabricante, y a ti te toca conseguir una fecha e instalar la actualización. Los propios clientes de Microsoft no son distintos: algunos todavía aparecen en los informes de uso y necesitan la lista de permitidos hasta que se actualicen.

El código propio es trabajo tuyo. Los scripts, los servicios internos, las herramientas de código abierto personalizadas y las integraciones que una agencia construyó hace años no tienen a nadie aguas arriba que las arregle. Ahí está el trabajo. Para hacerse una idea de la escala: exchangelib, una biblioteca de Python para hablar con Exchange a través de EWS, se descargó 1.174.625 veces de PyPI el último mes. Parte de eso es uso local, pero da una idea de cuánto código habla EWS directamente.

Primer paso: encontrar todo lo que usa EWS

Empieza por el informe de uso de EWS del Centro de administración de Microsoft 365 (Informes, Uso, Exchange y, después, la pestaña de uso de EWS). Para cada aplicación muestra el identificador de aplicación de Microsoft Entra, cada acción SOAP que llamó esa aplicación, el volumen de llamadas y la fecha de la última actividad. Puedes mirar 7, 30 o 90 días atrás y exportarlo a CSV.

Tres cosas que conviene saber:

• Los datos se agregan semanalmente y pueden tardar hasta 10 días en aparecer.
• Un identificador de aplicación no es un responsable. Cruza cada identificador con las aplicaciones empresariales de Microsoft Entra, y después busca la persona o el equipo que la gestiona. Cuenta con encontrar algunos identificadores que nadie reconoce.
• La columna de acciones SOAP te dice el tamaño de cada trabajo. Una aplicación que solo llama a FindItem y GetItem es un trabajo corto. Una que llama a SyncFolderItems, Subscribe y ExportItems es un proyecto.

Ni siquiera 90 días capturan los procesos anuales, así que mira también por el otro lado: tareas programadas y entradas de cron, y los repositorios de código, buscando el endpoint de EWS (Exchange.asmx), la EWS Managed API para .NET y exchangelib. La página de Microsoft sobre la retirada enlaza además un analizador de EWS para código .NET (marca las llamadas a EWS en Visual Studio y VS Code y sugiere equivalentes en Graph) y un tutorial sobre refactorización asistida por IA.

Segundo paso: decidir en qué se convierte cada integración

Cada aplicación de la lista recibe una de cuatro respuestas:

1. Retirarla. Algunas integraciones solo existen porque nadie las apagó.
2. Actualizarla. Los productos de terceros reciben una actualización del fabricante. Acuerda la fecha ya.
3. Reescribirla contra Microsoft Graph. La opción por defecto para el código propio.
4. Rediseñarla. Para todo lo que dependa de una capacidad que Graph no tendrá nunca (ver más abajo).

Microsoft menciona también Power Platform como forma de reimplementar un flujo de trabajo. Para un script que reenvía adjuntos a una carpeta, puede ser la respuesta más barata.

Qué implica realmente reescribir contra Graph

La mayoría de las operaciones de EWS tienen un equivalente directo en Graph, y Microsoft mantiene una correspondencia entre EWS y Graph. La correspondencia es la parte fácil. Las partes difíciles son las que no muestra.

Los permisos se estrechan, y eso es una ventaja

Una aplicación que usa EWS sin un usuario con sesión iniciada tiene el permiso de aplicación de EWS, que Microsoft describe como «acceso total a todos los buzones». Graph lo divide en permisos separados: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read y así sucesivamente.

También puedes limitar a qué buzones llega una aplicación. RBAC para aplicaciones en Exchange Online asigna un permiso sobre un ámbito de administración o una unidad administrativa, y sustituye a las antiguas directivas de acceso a aplicaciones. Una pantalla de reserva de salas puede leer los calendarios de doce buzones de sala y nada más. Una trampa: los permisos concedidos así se suman a cualquier permiso para todo el tenant concedido en Microsoft Entra, así que si Mail.Read sigue consentido ahí, tu ámbito no restringe nada. Elimina el permiso de Entra.

Usa certificados en lugar de secretos de cliente para autenticar la aplicación siempre que puedas, y mantén las credenciales fuera de los scripts y de los repositorios.

La sincronización y las notificaciones se reconstruyen, no se traducen

Este suele ser el mayor cambio para todo lo que guarda una copia local de los datos del buzón.

Sincronización. SyncFolderItems se corresponde con la consulta delta de mensajes de Graph, y SyncFolderHierarchy con la consulta delta de carpetas de correo. La delta de mensajes trabaja carpeta a carpeta, así que una sincronización completa del buzón implica seguir el árbol de carpetas y guardar un enlace delta separado por carpeta. El filtrado es limitado (solo por fecha de recepción), y los resultados incluyen eliminaciones, traslados fuera de la carpeta y cambios de estado de lectura aunque no coincidan con tu filtro.

Notificaciones. Las suscripciones de streaming y push de EWS pasan a ser notificaciones de cambios de Graph, entregadas a un webhook que gestionas tú o a Azure Event Hubs o Event Grid. Un webhook tiene que ser accesible desde el lado de Microsoft, lo que supone un cambio de arquitectura para un script que antes mantenía una conexión abierta desde detrás del cortafuegos. Las suscripciones a correo, calendario y contactos duran como máximo 10.080 minutos (algo menos de siete días), o 1.440 minutos cuando la notificación incluye los datos, así que algo tiene que renovarlas. Cada buzón admite como máximo 1.000 suscripciones activas entre todas las aplicaciones.

El patrón que resiste: trata una notificación como un aviso, ejecuta la consulta delta para ver qué ha cambiado, y ejecútala también con un temporizador para recoger lo que una notificación perdida habría dejado fuera.

Datos, identificadores y rendimiento

• Identificadores guardados. Si tu CRM o tu sistema de tiques guardó identificadores de elementos de EWS para vincular correos con registros, esos vínculos hay que convertirlos. Graph tiene una función translateExchangeIds precisamente para esto. Planifica la conversión como un paso de migración en sí mismo.
• Búsquedas. ResolveNames se corresponde con la People API, GetUserAvailability con getSchedule, y la configuración de fuera de la oficina con la configuración del buzón. Equivalentes cercanos, no idénticos.
• Limitación de peticiones. Graph limita cada par de aplicación y buzón a 10.000 solicitudes cada 10 minutos, cuatro solicitudes simultáneas y 150 MB de subidas cada 5 minutos. Un proceso masivo que lanzaba decenas de hilos de EWS en paralelo contra un buzón tiene que rediseñarse en torno a esas cifras.

Las carencias, y lo que no llegará nunca

Microsoft publica una hoja de ruta de las capacidades de EWS que todavía faltan en Graph. Incluye la importación y exportación de alta fidelidad para buzones de archivo, de carpetas públicas y de grupos, el acceso a los archivos locales del buzón, los permisos de carpeta a través de la Exchange Admin API y la creación de mensajes que no sean borradores a partir de MIME. La mayoría tienen como objetivo el cuarto trimestre de 2026. Unas pocas estaban previstas para el tercer trimestre, que ya ha terminado, así que comprueba qué se ha publicado realmente antes de diseñar contando con ello. La propia advertencia de Microsoft: si una capacidad no está en la hoja de ruta, «no cuentes con» un equivalente en Graph antes de que se apague EWS.

Tres capacidades están confirmadas como que nunca llegarán a Graph:

• El acceso genérico a carpetas públicas (crear, leer, actualizar y eliminar carpetas y elementos).
• El acceso genérico a los buzones de los grupos de Microsoft 365. En su lugar, Graph cubre las conversaciones, los hilos y las publicaciones de los grupos.
• El acceso a los buzones de detección. Microsoft remite a Purview eDiscovery.

Si una herramienta depende de alguna de ellas, portar el código no basta: primero los datos o el flujo de trabajo tienen que trasladarse a otro sitio, y eso lleva más tiempo que una reescritura.

Un plan de seis meses

De hoy al 1 de abril de 2027 hay algo menos de seis meses. Un orden realista:

Octubre de 2026: saber dónde estás. Comprueba EWSEnabled y la lista de permitidos. Exporta 90 días del informe de uso. Revisa la lista que rellenó Microsoft, quita lo que no debería estar y añade los procesos poco frecuentes que conozcas. Si tu tenant sigue en Null, plantéate configurar tú mismo la lista y poner True en lugar de esperar a que Microsoft lo cambie a False y descubrir qué se rompe.

Noviembre de 2026: clasificación. Asigna un responsable y una respuesta (retirar, actualizar, reescribir, rediseñar) a cada identificador de aplicación. Analiza el código. Marca todo lo que toque carpetas públicas, buzones de grupo o buzones de detección y empieza ya el rediseño. Crea los registros de aplicación de Graph con permisos acotados.

De diciembre de 2026 a enero de 2027: desarrollo. Empieza por la integración que el negocio echaría de menos antes. Construye una sola vez la infraestructura de sincronización y notificaciones y reutilízala. Convierte los identificadores guardados.

Febrero de 2027: ejecutar ambas versiones en paralelo. Mientras EWS siga funcionando, ejecuta la versión antigua y la nueva contra los mismos buzones y compara los resultados. A medida que aceptes cada una, quita su identificador de la lista de permitidos. Esa es también la prueba: espera las 24 horas y confirma que no ha dejado de funcionar nada más.

Marzo de 2027: apagar EWS tú mismo. Pon EWSEnabled en False bastante antes del 1 de abril. Lo que se te haya escapado fallará mientras todavía puedes volver a activar EWS. Después del 1 de abril esa opción desaparece. Haz también antes una ejecución de prueba deliberada de los procesos trimestrales y anuales: un proceso que se ejecuta al cerrar el primer trimestre se ejecutará por primera vez cuando EWS ya no exista.

Dónde conseguir ayuda

El caso difícil es la integración cuyo desarrollador original ya no está. Nuestro servicio de mantenimiento de sistemas heredados está pensado para eso: leemos el código existente, reescribimos las partes de EWS contra Microsoft Graph (permisos, sincronización, notificaciones, migración de identificadores) y ejecutamos la versión antigua y la nueva en paralelo hasta que las cifras coinciden. Si lo que necesitas son ingenieros que trabajen dentro de tu propio equipo, consulta nuestro servicio de ampliación de equipos.

Si tu informe de uso está lleno de identificadores de aplicación que nadie reconoce, escribe a office@c9group.dev.