El 1 de octubre, Microsoft comenzará a desactivar su API Exchange Web Services (EWS), antes de su cierre total en abril de 2027. Para muchas organizaciones, EWS ha sido durante mucho tiempo la problemática infraestructura invisible que sustenta herramientas diarias en el lugar de trabajo. Permite que aplicaciones se conecten a buzones de Exchange, facilitando el acceso y la gestión de datos de correos electrónicos, calendarios, contactos y carpetas.

Pero EWS tiene casi 20 años. Microsoft afirma que ya no se alinea con los requisitos modernos de seguridad, escala y fiabilidad, y su implicación en el ataque Midnight Blizzard de 2024 ha añadido urgencia a su retirada. El riesgo más amplio también es claro: las APIs, especialmente las más antiguas y menos visibles, se han convertido en objetivos atractivos para los ciberdelincuentes. Investigaciones recientes indicaron que el 99% de las organizaciones encontraron problemas de seguridad en APIs durante el último año.

En ese contexto, la decisión de Microsoft de mover a los clientes hacia APIs más modernas como Microsoft Graph tiene sentido. Pero la modernización de APIs rara vez es tan simple como cambiar una conexión por otra, y muchas organizaciones pueden enfrentar pronto una despiadada sacudida.

No se puede migrar lo que no se sabe que existe

El principal reto para las organizaciones al migrar de EWS a Microsoft Graph es la visibilidad. A pesar de sus limitaciones, EWS continúa detrás de muchos procesos cotidianos en talleres grandes y antiguos.

La reserva de reuniones, la sincronización de calendarios o permitir que un CRM registre automáticamente la actividad de correo pueden depender de la API. Tras casi dos décadas de uso, EWS se ha incrustado profundamente en las operaciones diarias.

Eso genera un problema. Muchas organizaciones pueden ya no tener una visión clara de dónde se usa EWS, por quién o con qué propósito. Algunas integraciones fueron creadas hace años por desarrolladores que ya no trabajan en la empresa. Otras pueden residir dentro de flujos de trabajo heredados que los equipos de TI rara vez tocan.

Y las herramientas de terceros que quedan fuera del control del equipo de IT a menudo se conectan a EWS. En consecuencia, es casi seguro que algunas dependencias ocultas se crucen durante la migración, ya que las organizaciones solo pueden sustituir las integraciones de EWS que conocen que existen.

Para algunas organizaciones, esta falta de visibilidad puede hacer que la migración parezca desalentadora, especialmente cuando EWS está tan estrechamente ligado a las operaciones diarias. Puede ser tentador recurrir al viejo dicho “si no está roto, no lo arregles”, sobre todo si una migración mal gestionada podría interrumpir herramientas y flujos de trabajo críticos.

Pero a medida que Microsoft desactiva EWS y finaliza su soporte, no hacer nada no es una opción viable. Aplicaciones vitales podrían perder acceso a Exchange, mientras que los riesgos de seguridad de dejar APIs heredadas incrustadas en el negocio se volverán más acentuados.

Otras organizaciones pueden intentar evitar una migración difícil interceptando las llamadas de EWS y traduciéndolas a Microsoft Graph, redirigiendo el tráfico en lugar de reemplazar la integración subyacente. A primera vista puede parecer una solución ingeniosa. En realidad, es solo una solución temporal.

El mismo conjunto de retos de seguridad, visibilidad e integración permanece, mientras cada dependencia adicional construida alrededor de este enfoque añade otra capa de complejidad. A escala, eso podría volverse inmanejable muy rápidamente.

Más allá de evitar

En lugar de esconder la cabeza bajo la arena o buscar atajos ingeniosos pero, en última instancia, ineficaces para evitar migrar de EWS, las organizaciones deberían tratar su retirada como un recordatorio de la necesidad de una gestión robusta del ciclo de vida del software.

Muchos equipos evalúan una API exhaustivamente durante la implementación y luego rara vez la revisan de nuevo. Pero las APIs evolucionan, surgen problemas de seguridad y los proveedores introducen actualizaciones que requieren acción. Las organizaciones que integren resiliencia y buenas prácticas de gestión del ciclo de vida en su inventario de APIs estarán mejor posicionadas para responder con rapidez a migraciones forzadas, minimizar interrupciones y evitar sorpresas ante cambios repentinos.

En la práctica, eso significa tratar las APIs como parte de la cadena de suministro digital y aplicar el mismo nivel de escrutinio que se usa para proveedores externos al evaluar una posible integración.

Las APIs críticas deben ser monitorizadas de forma continua para que las organizaciones sepan dónde se usan, qué soportan y cómo funcionan. Los equipos de TI también deben mantenerse informados sobre cambios planificados de los proveedores, por pequeños que parezcan, y evaluar cómo podrían afectar a su programa de gestión de APIs.

A partir de ahí, las organizaciones necesitan un plan de migración de APIs completamente preparado. Algunos cambios pueden exigir acción inmediata, como cuando un tercero divulga una vulnerabilidad crítica. Otros, como la retirada de EWS por parte de Microsoft, pueden venir con plazos más largos pero ser de mayor alcance y escala.

En cualquier caso, las organizaciones requieren una estrategia holística que cubra descubrimiento de APIs, mapeo de dependencias, propiedad y gestión, pruebas y monitoreo continuo. Sin esa base, corren el riesgo de migrar solo las integraciones que pueden ver, dejando dependencias ocultas que podrían fallar más tarde.

Preparando el futuro hoy

La desactivación de EWS por parte de Microsoft no es la primera acción de este tipo, y no será la última. A medida que evolucionan los patrimonios tecnológicos, más APIs heredadas serán retiradas a favor de versiones más modernas que se integren de forma más eficaz y segura con soluciones actuales. Por lo tanto, la retirada de EWS debe tratarse como algo más que un simple plazo de Microsoft; es una advertencia sobre lo que sucede cuando las integraciones críticas se vuelven invisibles.

Esto subraya la necesidad de resiliencia. Con una gestión robusta del ciclo de vida del software, las organizaciones pueden abandonar migraciones reactivos y de pánico, y tomar un mayor control sobre su inventario de APIs. Aquellas que se preparen ahora estarán en mejor posición para gestionar la migración de EWS y lo que venga después.

Este artículo forma parte de las perspectivas de TechRadar Pro Perspectives, nuestro canal para presentar a las mentes más brillantes de la industria tecnológica de hoy.

Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, descubra más aquí: https://www.techradar.com/pro/perspectives-how-to-submit