Corte de EWS en octubre: lista de correo y calendario para operadores individuales
Un operador individual puede mantener sus automatizaciones de correo y calendario funcionando si inventaria sus dependencias ahora y las migra a una API más nueva con sincronización basada en eventos y límites de solicitud más estrictos.
El modo de fallo silencioso para un operador individual no es una caída ruidosa. Es una automatización de facturas que se detiene tras un cambio en la nube, una sincronización de calendario que se desvía, o un analizador de recibos que ya no ve la carpeta correcta. La solución es aburrida: contar las dependencias, migrar las que importan y dejar una excepción estrecha para el resto. El apagado de EWS en Exchange Online, en el servicio de correo en la nube de Microsoft, es escalonado: comienza el 1 de octubre de 2026 y termina con la retirada permanente el 1 de abril de 2027. Eso te da tiempo para hacerlo con calma.
Para un negocio de una sola persona, el margen viene de no gastar horas en automatizaciones frágiles. Si una automatización toca el correo, el calendario, las facturas o los recibos, merece un lugar en un pequeño inventario. No necesitas un equipo de proyecto. Necesitas una lista de verificación con fecha, unas pocas herramientas de administración y una regla: todo cambio futuro se registra.
La fecha límite es una ventana de mantenimiento, no un pánico
La autenticación básica para EWS, POP, IMAP y ActiveSync en Exchange Online se detuvo el 1 de octubre de 2022. Eso significa que los antiguos atajos basados en contraseña ya no existen en la nube. Microsoft Graph requiere OAuth 2.0 a través de Microsoft Entra ID, el servicio de identidad de Microsoft. Si tu automatización aún depende de una contraseña almacenada, la migración no es opcional. Es el único camino soportado.
El inventario va antes que los cambios de código
Mantén una sola lista. Cada elemento debe poder probarse en un minuto: abres la herramienta, ejecutas la comprobación y lo marcas como hecho. La lista de abajo es la que debes conservar.
- Enumera cada automatización que toque el correo, el calendario, las facturas o los recibos, y anota el disparador, el responsable y el punto de acceso.
- Ejecuta el EWS Analyzer contra tu inquilino y guarda la salida.
- Abre los informes de uso de EWS e identifica los principales app IDs y patrones de llamada.
- Marca cada dependencia como migrar o permitir, y escribe la razón en una frase.
- Crea o revisa un registro de aplicación de Microsoft Entra ID para el trabajo con Graph.
- Almacena el client ID y el secreto en un gestor de secretos, no en un script.
- Configura la cola de automatización para no superar 4 llamadas concurrentes a Graph por app ID y buzón.
- Sustituye el sondeo repetido por sincronización basada en eventos donde el flujo lo permita.
- Ejecuta una factura, recibo o evento de calendario de prueba y confirma que el resultado aparece.
- Registra la fecha límite de la lista de permisos de agosto de 2026 en tu calendario de administración.
Microsoft proporciona el analizador y los informes de uso para encontrar dependencias de EWS. Los tres primeros elementos existen porque no puedes migrar lo que no puedes ver. El analizador y los informes son la versión económica de una auditoría de código. Los siguientes elementos existen porque la autenticación de Graph es diferente a los viejos hábitos de EWS. El elemento de concurrencia existe porque Graph es más estricto que el servicio anterior. El elemento de prueba existe porque un operador individual no puede permitirse un fallo silencioso.
Graph funciona mejor con solicitudes más pequeñas y estables
Graph aplica los límites de servicio de Outlook: 10.000 llamadas a la API en 10 minutos, 4 solicitudes concurrentes y 150 MB de cargas en 5 minutos, por app ID y buzón. Por comparación, EWS en Exchange Online permitía 27 conexiones concurrentes, con políticas de limitación configurables por los administradores del inquilino. La diferencia práctica es que tu automatización debe dejar de intentar dispersarse. Agrupa el trabajo. Encola las llamadas. Deja que un buzón termine antes de que empiece el siguiente.
Para un operador individual, el truco duradero es hacer la automatización más pequeña, no más rápida. Si un analizador de recibos necesita leer una carpeta, hazlo una vez por evento en lugar de cada minuto. Si un flujo de facturas necesita crear un bloque en el calendario, envía una solicitud con los campos que necesita. Si una herramienta hace sondeo de cambios, pásala a un patrón basado en eventos. El objetivo es hacer menos llamadas, no escribir código más ingenioso.
OAuth 2.0 también cambia cómo piensas en el acceso. El registro de aplicación es la identidad. El token es el permiso. El buzón es el límite. Si puedes explicarte esas tres cosas a tu yo del futuro, la automatización es más fácil de confiar. Si no puedes, el código está haciendo más de lo que debería.
La lista de permisos es un último recurso
Si una dependencia es demasiado arriesgada para migrarla antes del corte, el camino de excepción es estrecho. Si un operador individual aún necesita EWS después de octubre de 2026, el inquilino debe tener AppID AllowList y EWSEnabled=True configurados antes de finales de agosto de 2026. Eso es un permiso con fecha, no un pase libre, para mantener una vieja puerta abierta mientras terminas la mudanza.
Usa la lista de permisos solo para un app ID nombrado, un buzón nombrado y una fecha límite nombrada. No permitas una categoría. No permitas porque un proveedor no ha respondido. No permitas porque el código es antiguo. La lista de permisos es una excepción temporal, no un diseño permanente.
Guarda la lista de verificación donde guardas el app ID y el secreto. Cuando una nueva automatización toque el correo o el calendario, añádela a la lista antes de que entre en producción. Eso mantiene el próximo cambio pequeño.
