Microsoft iniciou oficialmente a contagem regressiva para aposentar de vez o Exchange Web Services (EWS) no Microsoft 365 e no Exchange Online, encerrando o ciclo de uma das APIs mais antigas, difundidas e estratégicas do universo Exchange. A mudança não é apenas técnica: ela impacta diretamente integrações legadas, soluções de terceiros, sistemas corporativos internos e até rotinas críticas de negócio que ainda dependem desse serviço.
De acordo com o cronograma divulgado, o EWS será desabilitado por padrão a partir de 1º de outubro de 2026 em ambientes de Microsoft 365 e Exchange Online. Até lá, organizações que ainda necessitem da API poderão mantê-la em funcionamento ao configurar explicitamente o parâmetro `EWSEnabled = true`, algo que, na prática, transforma o EWS em uma funcionalidade que passa a requerer habilitação deliberada por parte dos administradores. Esse “respiro” vale até agosto de 2026, servindo como último fôlego para ajustes finais de migração.
A data que realmente marca o fim da linha, porém, é 1º de abril de 2027. A partir desse dia, o EWS será encerrado de forma definitiva no Microsoft 365 e no Exchange Online, e a Microsoft foi categórica ao afirmar que não haverá exceções, extensões de prazo ou “jeitinho” para manter a API ativa em cenários específicos. Em outras palavras: quem ainda depender do EWS depois dessa data ficará simplesmente sem acesso à funcionalidade.
Embora muitas organizações só estejam reagindo agora, o fim do EWS não é uma surpresa. A API está oficialmente depreciada há anos, e a aposentadoria foi comunicada pela Microsoft em 2023. Em 2025, a pressão aumentou quando a empresa restringiu ainda mais o acesso, determinando que determinados tipos de licença – incluindo planos voltados a trabalhadores de linha de frente, como F1 e F2 – não poderiam mais utilizar o EWS. Essa mudança já funcionou como um “sinal amarelo” de que o serviço estava com os dias contados.
Lançado originalmente com o Exchange Server 2007, o EWS foi projetado para permitir que aplicações acessem caixas de correio, calendários, contatos, tarefas e outros repositórios de dados tanto no Exchange Online quanto em implementações locais do Exchange Server. Ao longo dos anos, tornou-se praticamente onipresente em integrações corporativas: ferramentas de arquivamento, sistemas de CRM, soluções de e-discovery, aplicativos móveis, complementos do Outlook e incontáveis aplicações internas passaram a utilizá-lo como “ponte” padrão com o Exchange.
Esse alcance massivo, porém, acabou tendo um lado sombrio. Justamente por ser amplamente adotado, o EWS também se consolidou como alvo constante de ataques cibernéticos. Grupos maliciosos passaram a explorar credenciais comprometidas, falhas de configuração e brechas operacionais para abusar da API, muitas vezes usando-a para movimentação lateral, exfiltração de dados ou monitoramento discreto de caixas de e-mail sensíveis. Com o passar do tempo, a superfície de ataque associada ao EWS se tornou uma preocupação crescente para a Microsoft.
A pressão por uma mudança ganhou contornos mais urgentes após o incidente de segurança envolvendo o grupo Midnight Blizzard, que explorou recursos do ecossistema Microsoft em operações altamente sofisticadas. Depois desse episódio, a empresa declarou ter elevado significativamente o nível de prioridade para aposentar o EWS, citando explicitamente motivos de segurança e a necessidade de reduzir vetores de ataque históricos que já não atendem aos padrões modernos de proteção.
É importante destacar que a aposentadoria anunciada atinge apenas o Microsoft 365 e o Exchange Online. Ambientes com Exchange Server on-premises continuarão a ter suporte ao EWS, pelo menos por enquanto, de acordo com o ciclo de vida e as políticas de suporte de cada versão do produto. Ou seja: empresas com infraestrutura local ainda poderão utilizar a API, mas isso não significa que seja prudente apostar no EWS como estratégia de longo prazo, considerando a clara direção de evolução da plataforma.
Para os ambientes em nuvem, o recado é direto: quem ainda não iniciou ou não finalizou o plano de migração precisa acelerar. A recomendação oficial da Microsoft é a transição para o Microsoft Graph, a API moderna que concentra o acesso a dados e serviços em todo o ecossistema Microsoft 365. O Graph oferece um modelo de autenticação mais robusto (com foco em OAuth 2.0 e identidades modernas), controles de permissão mais refinados, registro detalhado de atividades e integração com mecanismos avançados de segurança e governança.
A própria Microsoft, contudo, reconhece que o Microsoft Graph ainda não atingiu paridade funcional completa com o EWS, embora esteja “quase” nesse ponto para a maioria dos cenários. Isso significa que certos fluxos muito específicos ou customizações extremas podem exigir ajustes de arquitetura, reescrita de código ou até revisão de processos de negócio. A empresa também admitiu que nem todas as suas próprias aplicações internas já concluíram a migração, o que evidencia a complexidade do movimento, sobretudo em grandes ambientes.
Uma das grandes dificuldades para muitas organizações é identificar a totalidade das dependências do EWS. Em empresas de grande porte, é comum existir uma “floresta” de integrações legadas, scripts criados anos atrás, aplicações internas sem documentação atualizada e soluções de terceiros que utilizam o EWS em segundo plano. Pensando nisso, a Microsoft sinalizou que poderá executar o que chama de “scream tests”: desligar temporariamente o EWS, de maneira controlada, e religá-lo em seguida com o objetivo de revelar, pelo impacto, quais sistemas ainda dependem da API.
Na prática, esses testes tendem a gerar alertas, falhas ou comportamentos anômalos em aplicações que ainda se apoiam no EWS. O problema é que a empresa não detalhou como os administradores poderão distinguir claramente esses eventos de outros incidentes reais, o que gera desconforto em um contexto já marcado por interrupções recorrentes em serviços online. Em ambientes críticos, isso exige monitoramento fino e comunicação interna clara, para evitar que um teste planejado seja interpretado como um incidente grave.
Do ponto de vista de governança e gestão de risco, o fim do EWS impõe às organizações uma oportunidade – e uma obrigação – de “limpar a casa”. Mapear integrações ativas, descontinuar o que é obsoleto, revisar permissões excessivas, modernizar autenticação e repensar fluxos de dados sensíveis são etapas que vão muito além de uma simples troca de API. Em muitos casos, o processo de migração pode ser aproveitado para reduzir acoplamentos desnecessários, centralizar controles de segurança e reforçar a conformidade com requisitos regulatórios.
Para desenvolvedores, a transição exige uma readequação técnica significativa. O modelo de chamadas, autenticação e tratamento de dados no Microsoft Graph é diferente do EWS, o que demanda atualização de bibliotecas, revisão de endpoints, adaptação de lógicas de paginação e filtragem, além de um novo olhar sobre cache, performance e limites de uso. Em contrapartida, o Graph oferece uma visão unificada de múltiplos serviços (como Teams, OneDrive, SharePoint, Planner e outros), permitindo a criação de soluções mais integradas e ricas do que aquelas baseadas exclusivamente em EWS.
Do lado da segurança, equipes de cibersegurança ganham um aliado mais moderno. O Graph integra-se de forma nativa com políticas de acesso condicional, proteção de identidade, autenticação multifator, vigilância baseada em risco e telemetria avançada. Isso facilita correlação de eventos, resposta a incidentes e aplicação de princípios de Zero Trust, algo bem mais difícil de orquestrar em cima de APIs legadas desenhadas em outra época e sob outro paradigma de ameaça.
Organizações que dependem fortemente de softwares de terceiros precisam, desde já, cobrar posicionamento claro de seus fornecedores: se o produto usa EWS, qual o plano de migração? Haverá nova versão? O roadmap está alinhado às datas definidas pela Microsoft? Ignorar essas questões pode levar a surpresas desagradáveis em 2026 ou, pior ainda, em 2027, com soluções parando de funcionar justamente em processos críticos, como faturamento, atendimento ao cliente, comunicação executiva ou fluxos jurídicos.
Outro ponto sensível é o impacto em ambientes híbridos, que combinam Exchange Server on-premises e Exchange Online. Ainda que o EWS siga existindo localmente, manter dependências dessa API apenas em parte do ambiente pode aumentar a complexidade operacional e dificultar o gerenciamento unificado. Em muitos casos, fará sentido planejar uma migração em duas frentes: modernizar a camada de integração para o Graph no que estiver na nuvem e, em paralelo, planejar a redução gradual do uso de EWS também no on-premises, antecipando um cenário em que a API se torne cada vez menos relevante.
A mudança também impõe um desafio cultural. Muitas equipes de TI se acostumaram a trabalhar “no piloto automático” com o EWS, reproduzindo padrões e scripts conhecidos ao longo de mais de uma década. A desativação obriga essas equipes a se atualizar, aprender novas APIs, revisar boas práticas e, em alguns casos, abandonar soluções “caseiras” que nunca foram devidamente formalizadas. Investir em capacitação, treinamento e documentação interna será essencial para que a transição ocorra com o mínimo de fricção.
Por fim, a mensagem da Microsoft é inequívoca: o EWS faz parte de uma geração de tecnologias que está sendo aposentada para abrir espaço a uma plataforma mais coerente, segura e integrada. Com o prazo final fixado em abril de 2027 e sem margem para exceções, as organizações que ainda não começaram sua jornada de migração estão, de fato, correndo contra o relógio. Antecipar-se, planejar e executar essa transição de forma estruturada pode ser a diferença entre uma adaptação tranquila e uma crise operacional às vésperas do desligamento definitivo.