Retirada de EWS en Exchange Online: qué deben revisar los responsables de sistemas empresariales

Si una aplicación empresarial depende de Exchange Web Services (EWS) en Exchange Online, identifique las funciones que utiliza y confirme cómo continuarán antes de aprobar la reconstrucción de la aplicación. Una actualización compatible del proveedor o un cambio en la integración pueden cubrir la necesidad. Sustituir toda la aplicación debe plantearse cuando la opción disponible no permita realizar el trabajo que necesita su empresa.

Para quien aprueba el presupuesto, un buen punto de partida es un breve registro de dependencias: qué hace la conexión, quién es responsable, qué opción compatible la sustituirá y qué pruebas demostrarán que la función empresarial sigue operativa.

Entienda el calendario y el alcance actuales

El aviso general de Microsoft sobre la retirada de EWS describe dos fases. La desactivación gradual, controlable por los administradores, comenzó el 1 de octubre de 2026, inquilino por inquilino. Durante esta transición, el acceso depende de la configuración del inquilino y de los controles de la aplicación, por lo que la fecha por sí sola no permite saber si la conexión está bloqueada actualmente. El apagado permanente comienza el 1 de abril de 2027; a partir de entonces, los administradores ya no podrán controlar el acceso a EWS mediante la configuración del inquilino.

El aviso se aplica a Microsoft 365 y Exchange Online. Los servidores Exchange locales quedan fuera de esta retirada. Pida al responsable técnico que confirme a qué entorno se conecta realmente la conexión afectada.

Cuando esté permitido, restaurar temporalmente el acceso a EWS puede dar tiempo durante la transición. Asigne a esa medida una persona responsable y una fecha límite para completar la nueva opción. Que se restaure el acceso demuestra que la conexión actual puede volver a funcionar; no demuestra que la aplicación esté preparada para el apagado permanente.

Vincule la dependencia técnica con una persona responsable de la operación

Empiece por las personas responsables de los sistemas conectados. Pida a TI pruebas del uso de EWS y a cada responsable de aplicación que explique qué hace la conexión identificada. La guía de retirada de Microsoft remite a los administradores a informes de uso y herramientas de análisis.

Un identificador de aplicación resulta útil para quien controla el presupuesto cuando puede vincularse a una función empresarial. Por ejemplo, una conexión podría actualizar las citas de un sistema de planificación. Si falla, el personal podría trabajar con una agenda desactualizada. Esa consecuencia ayuda a establecer la prioridad y quién debe aprobar el resultado.

Registre estos datos para cada dependencia:

• Función y consecuencia: qué hace la conexión, con qué frecuencia es importante y qué ocurre si falla.
• Aplicación y responsabilidad: el sistema, el proveedor y la persona interna responsable de que siga funcionando.
• Requisito técnico: las operaciones o capacidades de EWS que se utilizan, además del buzón y el entorno implicados.
• Pruebas de continuidad: el destino compatible propuesto, la versión o documentación del proveedor que lo respalda y cualquier carencia pendiente.
• Implantación y aceptación: quién hará el cambio, para cuándo y qué prueba empresarial debe superarse.

Un informe de actividad observada ayuda a localizar una dependencia. Aun así, el responsable de la aplicación debe explicar su importancia operativa, incluidos los procesos ocasionales, como el cierre de mes.

Compruebe las capacidades de la sustitución propuesta

Microsoft Graph admite muchos escenarios de EWS, pero no debe darse por supuesta una equivalencia completa. La hoja de ruta de capacidades de Microsoft identifica carencias pendientes, alternativas y capacidades que no se añadirán. Por ejemplo, la importación y exportación de carpetas públicas es distinta del acceso habitual para crear, leer, actualizar y eliminar. La opción propuesta debe cubrir las operaciones que necesita la aplicación.

La misma hoja de ruta indica que las fechas estimadas de disponibilidad son objetivos que pueden cambiar. Que una función aparezca en la hoja de ruta para un trimestre, aunque ya haya pasado, no basta para demostrar que se ha entregado. Pida al proveedor o al responsable técnico que identifique la capacidad disponible y la versión que la incorpora.

Si una actualización compatible de la aplicación cubre las funciones necesarias, evalúe su coste, los requisitos de implantación y las pruebas de aceptación. Si puede cubrirlas un cambio en la integración, evalúe ese alcance. Si un componente necesario no dispone de una opción compatible adecuada, compare otro componente, un flujo de trabajo modificado u otra aplicación. Base la comparación en la función que falta y su consecuencia para la empresa, para que la decisión tenga un fundamento claro.

Apruebe un resultado que pueda verificar

Como prueba ilustrativa de un sistema de gestión de citas, cree una cita mediante el sistema conectado, cambie su hora y confirme que los registros previstos se actualizan para las personas indicadas. Compruebe que los permisos siguen correspondiendo a sus funciones. Incluya una acción fallida y confirme que una persona responsable puede verla y resolverla. Acuerde los resultados esperados antes de probar.

Un inicio de sesión correcto demuestra una parte de la conexión. La aceptación debe demostrar el trabajo real, incluido un caso de fallo con consecuencias. Adjunte el resultado al registro de dependencias para que quien apruebe la finalización pueda ver qué se comprobó.

Si una conexión de un sistema empresarial se ha visto afectada y necesita ayuda, describa la aplicación y la función que realiza. Ofrecemos servicios de integración de API; esa información sirve como punto de partida para hablar del alcance del trabajo necesario.