Koniec EWS w Exchange Online: jak przejść do Microsoft Graph

Dlaczego firmy powinny zająć się EWS teraz

EWS przez lata był standardowym sposobem integracji aplikacji z Exchange. Korzystają z niego systemy archiwizacji, narzędzia do obsługi zgłoszeń, aplikacje CRM, rozwiązania do rezerwacji, integracje kalendarzy, roboty przetwarzające pocztę i własne skrypty. Problem polega na tym, że wiele takich zależności działa w tle. Użytkownik widzi tylko końcowy rezultat, na przykład utworzone zgłoszenie albo zsynchronizowane spotkanie, ale nie wie, że proces opiera się na EWS.

Microsoft potwierdza w oficjalnym harmonogramie, że globalne wyłączanie EWS w Exchange Online zacznie się w październiku 2026, a pełne wyłączenie jest planowane na kwiecień 2027. To nie jest jednorazowa zmiana w jednym dniu, lecz okres, w którym kolejne organizacje i aplikacje mogą tracić dostęp. Taki model utrudnia działanie reaktywne, ponieważ test wykonany dziś nie gwarantuje, że ta sama integracja będzie działała po rozpoczęciu fazy wyłączeń.

Microsoft opisał również mechanizm EWSAllowedAppIDs, który ma pomóc kontrolować pozostające zależności w końcowej fazie. Nie należy jednak traktować allowlisty jako zamiennika migracji. To narzędzie przejściowe do zarządzania ryzykiem, a nie sposób na utrzymanie EWS bezterminowo.

Kogo dotyczy zmiana

Najbardziej narażone są organizacje, które mają własne aplikacje lub kupione systemy łączące się bezpośrednio z Exchange Online. Typowe przykłady to:

1. system ticketowy pobierający wiadomości ze skrzynki procesowej,
2. integracja CRM synchronizująca e-maile, kontakty i kalendarze,
3. aplikacja korzystająca z EWS impersonation do działania na wielu skrzynkach,
4. narzędzie do backupu, archiwizacji lub migracji poczty,
5. skrypt PowerShell, usługa Windows albo aplikacja .NET oparta na EWS Managed API,
6. rozwiązanie monitorujące nowe wiadomości przez streaming, push lub pull notifications,
7. system rezerwacji korzystający z kalendarzy i dostępności zasobów.

Zmiana dotyczy EWS używanego z Exchange Online. Microsoft Graph nie obsługuje Exchange Server on-premises, dlatego środowiska hybrydowe wymagają rozdzielenia scenariuszy chmurowych i lokalnych. Aplikacja może potrzebować Graph dla skrzynek w Exchange Online, a innego mechanizmu dla skrzynek pozostających lokalnie.

Właściciel procesu i dane potrzebne do migracji

Właścicielem migracji nie powinien być wyłącznie developer ani administrator Exchange. Potrzebny jest właściciel biznesowy procesu, ponieważ to on potrafi ocenić, co stanie się po zatrzymaniu integracji. Dla systemu ticketowego może to być manager Service Desk. Dla integracji sprzedażowej będzie to właściciel CRM lub procesu lead management. Administrator M365 odpowiada za dane o użyciu, uprawnienia i konfigurację tenantową, a zespół aplikacyjny za kod, testy oraz wdrożenie.

Na wejściu trzeba zebrać co najmniej:

• identyfikator aplikacji i jej właściciela,
• dostawcę oraz wersję produktu,
• używane operacje EWS,
• skrzynki i typy danych objęte dostępem,
• model uwierzytelniania i uprawnienia,
• wolumen wywołań oraz godziny szczytu,
• wymagania dotyczące czasu reakcji,
• zależności od folderów niestandardowych, archiwum lub folderów publicznych,
• konsekwencję biznesową awarii,
• plan wsparcia dostawcy po październiku 2026.

Wynikiem pierwszego etapu powinien być rejestr zależności EWS z priorytetem, właścicielem, ścieżką migracji i datą decyzji. Bez tego organizacja może poświęcić czas na mało ważny skrypt, a pominąć krytyczną integrację działającą pod kontem aplikacyjnym.

Plan migracji z EWS do Microsoft Graph

Krok 1. Wykryj rzeczywiste użycie EWS

Zacznij od raportów użycia EWS i narzędzi migracyjnych wskazanych przez Microsoft. Raporty pokazują aplikacje, typy operacji i wolumen wywołań. Dla własnego kodu można użyć EWS Code Analyzer, który pomaga znaleźć odwołania do EWS i wskazać obszary wymagające zmiany.

Nie opieraj się wyłącznie na dokumentacji aplikacji. Stary system może formalnie wspierać Graph, ale nadal używać EWS w konkretnym module. Z kolei aplikacja oznaczona jako krytyczna może nie wykonywać żadnych wywołań od miesięcy. Dane o aktywności pozwalają oddzielić realne ryzyko od historycznych wpisów w dokumentacji.

Krok 2. Podziel aplikacje według ścieżki działania

Każdą zależność przypisz do jednej z czterech grup:

Takie rozdzielenie zapobiega traktowaniu całego portfolio jak jednego projektu programistycznego. Część problemów rozwiąże aktualizacja produktu, część wymaga własnej pracy, a część najlepiej usunąć.

Krok 3. Zaprojektuj nowy model uprawnień

EWS często działał w modelu szerokiego dostępu. Microsoft Graph pozwala przyznawać bardziej granularne uprawnienia do poczty, kalendarzy, kontaktów i innych zasobów. To poprawia bezpieczeństwo, ale wymaga świadomego projektu.

Trzeba zdecydować, czy aplikacja działa w kontekście użytkownika, czy jako samodzielna aplikacja. Dla aplikacji bez użytkownika stosuje się tożsamość aplikacyjną i przepływ client credentials. Dostęp powinien być ograniczony do niezbędnych skrzynek i operacji. Migracja nie powinna polegać na odtworzeniu szerokiego EWS impersonation w nowej technologii bez ponownej oceny potrzeby biznesowej.

Punkt kontroli człowieka jest potrzebny przy zatwierdzaniu nowych uprawnień, zakresu skrzynek i wyjątków. Administrator nie powinien akceptować zgody tenant-wide tylko dlatego, że przyspiesza test.

Krok 4. Przebuduj powiadomienia i synchronizację

Aplikacje oparte na EWS streaming notifications nie mają bezpośredniego odpowiednika w Microsoft Graph. Graph używa change notifications dostarczanych przez webhooki, a w scenariuszach większej skali może korzystać z Azure Event Hubs. Do niezawodnej synchronizacji Microsoft zaleca łączenie powiadomień z delta queries.

Praktyczny wzorzec wygląda tak:

1. webhook informuje aplikację, że nastąpiła zmiana,
2. aplikacja zapisuje zdarzenie do kolejki,
3. worker pobiera szczegóły z Graph,
4. delta query okresowo uzgadnia stan i wykrywa pominięte zmiany,
5. monitoring wykrywa wygasłe subskrypcje, opóźnienia i błędy.

Szerszy model projektowania takich przepływów opisuje artykuł System operacyjny firmy w Microsoft 365: workflow i AI.

Warto stosować immutable IDs, gdy aplikacja przechowuje identyfikatory wiadomości poza Exchange. Standardowy identyfikator może zmienić się po przeniesieniu elementu do innego folderu. Identyfikator niezmienny ułatwia korelację operacji.

Krok 5. Przetestuj limity, błędy i zachowanie pod obciążeniem

Test funkcjonalny pokazujący, że aplikacja odczytała jedną wiadomość, nie wystarcza. Trzeba sprawdzić:

• szczytowy wolumen wiadomości i zdarzeń,
• opóźnienie webhooków,
• odnowienie i wygaśnięcie subskrypcji,
• retry z backoff,
• obsługę throttlingu,
• duże załączniki,
• przenoszenie wiadomości między folderami,
• duplikaty i zdarzenia dostarczone poza kolejnością,
• przerwę w działaniu endpointu,
• proces odtworzenia stanu przez delta query.

Graph ma inne zasady throttlingu i monitoruje szybkość odpowiedzi endpointów webhook. Dlatego migracja może ujawnić problemy, których nie było w modelu EWS. Wydajność trzeba mierzyć na przepływie zbliżonym do produkcyjnego.

Krok 6. Przełącz proces i zachowaj plan wycofania

Najbezpieczniejszy model to uruchomienie równoległe. Nowa integracja zbiera zdarzenia, ale przez określony czas nie wykonuje działań nieodwracalnych. Wyniki Graph i EWS są porównywane. Dopiero po osiągnięciu ustalonego progu jakości następuje przełączenie.

Plan wycofania powinien określać, kto może cofnąć wdrożenie, jak długo dostępna jest poprzednia wersja i jak chronione są dane przetworzone w okresie przejściowym. Allowlista EWS może być częścią kontrolowanego okresu przejściowego, ale nie powinna zastępować terminu zakończenia migracji.

Jak mierzyć rezultat migracji

Migracja jest zakończona wtedy, gdy proces działa stabilnie bez zależności od EWS, a nie wtedy, gdy nowy kod przeszedł jeden test. Użyteczne KPI to:

• liczba aktywnych aplikacji wykonujących wywołania EWS,
• udział procesów przeniesionych do Graph,
• liczba błędów synchronizacji na 1000 operacji,
• procent zdarzeń uzgodnionych przez delta query,
• czas od zdarzenia w skrzynce do reakcji aplikacji,
• liczba zgód aplikacyjnych o zbyt szerokim zakresie,
• liczba krytycznych aplikacji bez potwierdzonego planu dostawcy,
• skuteczność odnowienia subskrypcji,
• czas przywrócenia procesu po awarii.

Właściciel biznesowy powinien dodatkowo mierzyć efekt procesu, na przykład czas utworzenia zgłoszenia z e-maila, liczbę pominiętych wiadomości albo opóźnienie synchronizacji spotkań.

Najczęstsze ryzyka i ograniczenia

Pierwsze ryzyko to założenie, że każda operacja EWS ma bezpośredni odpowiednik w Graph. Microsoft nadal wskazuje obszary z niepełną zgodnością, między innymi wybrane scenariusze archiwum, importu, eksportu i administracji. Drugie ryzyko to pozostawienie decyzji dostawcy na ostatnie tygodnie. Firma może usłyszeć, że obsługa Graph wymaga nowej wersji produktu, dodatkowej licencji albo migracji całej platformy.

Trzecie ryzyko dotyczy uprawnień. Przejście do Graph jest dobrą okazją do ograniczenia dostępu, ale źle zaprojektowana aplikacja może nadal otrzymać zbyt szerokie uprawnienia. Czwarte to niedoszacowanie pracy przy webhookach, subskrypcjach i uzgadnianiu stanu. Piąte to brak monitoringu po wdrożeniu. Integracja może działać podczas testu, a później zatrzymać się z powodu wygasłej subskrypcji albo throttlingu.

Kiedy migracja do Graph nie jest jedyną odpowiedzią

Nie każdą starą integrację warto przepisywać. Jeżeli skrypt obsługuje proces, który można dziś zbudować prościej w Power Automate, Logic Apps albo innym wspieranym konektorze, przebudowa kodu może być nieopłacalna. Jeżeli aplikacja ma zakończyć życie przed wyłączeniem EWS, lepszy będzie kontrolowany plan wycofania. W środowisku lokalnego Exchange Server Graph nie zastąpi EWS, więc trzeba zaprojektować osobną ścieżkę. Przed podjęciem decyzji warto policzyć wartość procesu w kalkulatorze oszczędności z automatyzacji.

Rozwiązanie nie ma też sensu bez właściciela procesu. Migracja techniczna utrzymująca zbędny proces tylko przesuwa koszt w czasie. Najpierw trzeba potwierdzić, że integracja nadal wspiera realną potrzebę biznesową.

Podsumowanie

Wyłączenie EWS w Exchange Online to konkretne ryzyko operacyjne, a nie wyłącznie temat dla developerów. Od października 2026 Microsoft zacznie etapowo blokować EWS, dlatego organizacje powinny teraz wykryć aktywne zależności, ustalić właścicieli i przygotować migrację do Microsoft Graph albo kontrolowane wycofanie integracji.

Najlepszy pierwszy krok to krótki audyt: raport użycia EWS, lista aplikacji, ocena krytyczności, mapowanie operacji do Graph i decyzja dla każdej zależności. Dopiero potem warto pisać kod lub zamawiać aktualizacje u dostawców.

FAQ: koniec EWS i migracja do Microsoft Graph

Źródła

• Microsoft Learn: Deprecation of Exchange Web Services in Exchange Online
• Microsoft Exchange Team: Introducing EWSAllowedAppIDs
• Microsoft 365 Developer Blog: Migrating EWS notifications to Microsoft Graph
• Microsoft Learn: Migrate Exchange Web Services apps to Microsoft Graph
• Microsoft Learn: Authentication differences between EWS and Microsoft Graph
• Microsoft 365 Developer Blog: EWS Code Analyzer and Usage Report

Informacje i harmonogram zweryfikowano 16 lipca 2026. Przed zmianą środowiska produkcyjnego sprawdź aktualną dokumentację Microsoft oraz stan konkretnych aplikacji i tenantów.