Unternehmen mit Anwendungen auf Basis von Exchange Web Services müssen prüfen, ob diese auf Exchange Online zugreifen und welcher Umstellungsweg vorgesehen ist. Microsoft hat die schrittweise Abschaltung von EWS in Exchange Online ab Oktober 2026 beschrieben; nach dem aktuell veröffentlichten Plan folgt die endgültige Abschaltung ab April 2027. Das betrifft nicht pauschal EWS auf lokalen Exchange-Servern.
Die wichtigste Aufgabe ist deshalb eine belastbare Anwendungsliste. Eine funktionierende Outlook-Anmeldung beweist nicht, dass Raumplanung, Archivierung, Fachsoftware oder andere Hintergrundprozesse von der Änderung unberührt bleiben. Manche Abhängigkeiten werden erst sichtbar, wenn ein seltener Arbeitsablauf ausgeführt wird.
1. Zuerst Cloud und lokalen Server unterscheiden
EWS ist eine Schnittstelle, kein eigenständiges Postfachprodukt. Für die Bewertung muss feststehen, welche Anwendung welche Postfächer und welchen Dienst anspricht. In einer hybriden Umgebung können unterschiedliche Zugriffswege nebeneinander bestehen. Die Bezeichnung „Hybrid“ beantwortet die Frage nach der Betroffenheit daher nicht allein.
Halten Sie fest, wo die tatsächlich verwendeten Postfächer liegen und wie die Anwendung darauf zugreift. Ein lokaler Programmserver kann beispielsweise trotzdem Daten aus Exchange Online lesen. Sein Standort macht die Schnittstelle nicht automatisch zu einem rein lokalen Zugriff.
Die aktuelle Microsoft-Ankündigung grenzt Exchange Online und Exchange Server ausdrücklich voneinander ab. Behandeln Sie diese Grenze sauber. Eine pauschale Aussage, dass jeder lokale Exchange-Server wegen dieser Cloud-Abschaltung migriert werden müsse, wäre falsch.
2. Nach Geschäftsfunktionen suchen, nicht nur nach Produktnamen
Beginnen Sie mit den Abläufen, bei denen E-Mail- oder Kalenderdaten verarbeitet werden. Dazu können Terminabgleich, Raumbuchung, Ablage, Ticketverarbeitung oder die Übernahme von Nachrichten in eine Fachanwendung gehören. Die Beispiele sind Suchhilfen und kein Beleg dafür, dass eine konkrete Anwendung EWS verwendet.
Fragen Sie Fachbereiche und Softwarebetreuer nach automatisierten Vorgängen. Wer bemerkt, wenn ein Kalender nicht aktualisiert wird? Welche Rückmeldung entsteht, wenn eine Nachricht nicht verarbeitet werden kann? Wer kennt Hersteller und Vertragskontakt? Gerade diese organisatorischen Angaben fehlen oft in rein technischen Übersichten.
Auch seltene Vorgänge zählen. Eine monatlich laufende Schnittstelle kann in einer kurzen Beobachtungsphase unauffällig bleiben. Dokumentieren Sie deshalb den normalen Ausführungsrhythmus und einen repräsentativen Testfall. „In den letzten Tagen kein Fehler“ ist kein vollständiger Funktionsnachweis.
3. Für jede Anwendung einen verantwortlichen Eintrag anlegen
Eine brauchbare Bestandsliste verbindet Technik und Verantwortung. Erfassen Sie Anwendung, Zweck, Hersteller, verantwortlichen Bereich, betroffene Postfächer, Zugriffsart und bekannten Umstellungsstand. Kennzeichnen Sie unbestätigte Angaben. Eine Vermutung darf nicht wie ein Herstellerbefund aussehen.
Trennen Sie außerdem die fachliche Bedeutung von der technischen Komplexität. Ein technisch kleiner Dienst kann geschäftlich sehr wichtig sein. Die Reihenfolge der Bearbeitung sollte berücksichtigen, was bei einem Ausfall passiert und welche Zwischenlösung tatsächlich möglich wäre.
Wenn mehrere Anwendungen denselben technischen Zugang verwenden, muss das sichtbar werden. Das bedeutet noch nicht, dass alle gemeinsam geändert werden sollten. Es zeigt vielmehr, wo eine scheinbar kleine Anpassung andere Abläufe beeinflussen könnte.
4. Den aktuellen Tenantstatus und die Herstellerinformation prüfen
Die Veröffentlichung von Microsoft beschreibt einen stufenweisen, teilweise administrativ steuerbaren Übergang. Welche Einstellung im konkreten Tenant gilt und ob eine Anwendung aktuell blockiert wird, muss tatsächlich geprüft werden. Ein alter Screenshot oder eine frühere Projektentscheidung kann dafür inzwischen unzureichend sein.
Lassen Sie verfügbare Nutzungsinformationen und die aktuellen Microsoft-Hinweise durch die zuständige Administration auswerten. Ordnen Sie technische Kennungen den bekannten Anwendungen zu. Ein Bericht ohne Zuordnung zum Geschäftsprozess ist nur ein Teil der Bestandsaufnahme.
Ein vorübergehender Weiterbetrieb ist kein abgeschlossener Migrationsplan. Falls eine Ausnahme benötigt wird, sollten Zweck, Umfang, Verantwortlicher und Ende nachvollziehbar festgelegt sein. Eine pauschale, unbefristete Freigabe aller Altzugriffe darf nicht die Prüfung des erforderlichen Ersatzes ersetzen.
5. Den Anbieter nach einem konkreten Zielweg fragen
„Wir unterstützen Microsoft 365“ ist keine ausreichende Antwort des Softwareherstellers. Fragen Sie, welche Produktversion den betroffenen Ablauf ohne EWS in Exchange Online unterstützt, welche Rechte benötigt werden und wie die Umstellung getestet werden soll. Lassen Sie sich bekannte Einschränkungen nennen.
Bei einer selbst entwickelten Schnittstelle ist zu prüfen, welche einzelnen Funktionen genutzt werden. Microsoft Graph ist für viele Szenarien der vorgesehene Nachfolger. Die technische Entsprechung muss jedoch für den tatsächlichen Ablauf bewertet werden. Ein Austausch des Schnittstellennamens im Konzept ist noch keine lauffähige Lösung.
Erfassen Sie offene Punkte, deren Klärung vom Hersteller oder einer Entwicklung abhängt. Dazu gehören etwa fehlende Funktionen, geänderte Berechtigungen und die Behandlung von Fehlern. Unsere Anwendungsentwicklung ist ein möglicher Einstieg, um den technischen Prüfbedarf eines individuellen Ablaufs zu besprechen.
6. Berechtigungen und Identitäten getrennt von der Funktion testen
Eine neue Schnittstelle kann andere Anwendungsrechte oder Authentifizierungsverfahren verwenden. Prüfen Sie, welche Daten der Ablauf wirklich benötigt und welche Zugriffe er nicht erhalten soll. Die Frage lautet nicht nur „funktioniert es?“, sondern auch „funktioniert es mit den vorgesehenen begrenzten Rechten?“.
Für die Abnahme sollten erfolgreiche und fehlgeschlagene Zugriffe vorkommen. Ein berechtigter Vorgang wird verarbeitet. Ein Zugriff außerhalb des vorgesehenen Umfangs wird nicht zugelassen. Fehler müssen nachvollziehbar sein, statt stillschweigend Daten auszulassen.
Vermeiden Sie Tests, die ausschließlich mit einem weitreichenden Administratorkonto durchgeführt werden. Sie können technische Probleme verdecken und sagen wenig über den späteren Betrieb aus. Zugangsdaten gehören außerdem nicht in ungeschützte Projekttabellen oder öffentliche Fehlerberichte.
7. Den ganzen Geschäftsprozess abnehmen
Ein erfolgreicher API-Aufruf ist ein technisches Zwischenergebnis. Entscheidend ist, ob der gewünschte Ablauf vollständig und korrekt abgeschlossen wird. Prüfen Sie Eingabe, Verarbeitung, Ergebnis und Rückmeldung an die zuständige Person.
Ein hypothetisches Beispiel: Eine Raumplanungsanwendung kann einen Termin lesen, verarbeitet eine spätere Änderung aber doppelt. Die Verbindung funktioniert, der Geschäftsprozess ist trotzdem fehlerhaft. Ein zweiter Test muss daher Änderungen und wiederholte Verarbeitung berücksichtigen. Das Beispiel ist keine Kundenreferenz.
Nehmen Sie außerdem Fehlerfälle auf: vorübergehende Nichterreichbarkeit, fehlende Berechtigung oder eine unerwartete Antwort. Legen Sie fest, wie ein Vorgang erneut ausgeführt werden kann und wie doppelte Verarbeitung vermieden wird. Die konkrete Umsetzung hängt von der Anwendung ab.
8. Umschaltung und Betriebsübergabe dokumentieren
Vor der Umstellung sollten Zielkonfiguration, Testnachweise und Ansprechpartner bekannt sein. Klären Sie, ob alte und neue Verarbeitung vorübergehend parallel laufen dürfen. Unkontrollierte Parallelität kann zu doppelten Einträgen oder widersprüchlichen Ständen führen.
Definieren Sie, woran eine erfolgreiche Umschaltung erkannt wird. Wer kontrolliert die erste produktive Ausführung? Welche Meldungen werden beobachtet? Wann wird die bisherige Verbindung fachgerecht außer Betrieb genommen? Ein deaktivierter Altzugang sollte nachvollziehbar zu einer bestätigten Umstellung gehören.
Die Exchange-Beratung von network4you kann helfen, den betroffenen Mail- und Anwendungskontext für ein Vorhaben einzugrenzen. Eine bestimmte Wiederherstellungs- oder Umstellungszeit ergibt sich daraus nicht; sie muss für die tatsächliche Umgebung bewertet werden.
Projektcheckliste
| Prüffeld | Ergebnis, das vorliegen sollte |
|---|---|
| Betroffenheit | Exchange-Online-Zugriff und verwendete Schnittstelle bestätigt |
| Verantwortung | Fachlicher Eigentümer und technischer Ansprechpartner benannt |
| Ersatzweg | Unterstützte Version oder konkret bewertete Entwicklung beschrieben |
| Rechte | Erforderliche und untersagte Zugriffe getestet |
| Prozess | Normalfall, Änderung, Wiederholung und Fehlerfall geprüft |
| Umschaltung | Kontrolle, Rückmeldung und Umgang mit Altzugriff dokumentiert |
Häufige Fragen
Betrifft die Abschaltung auch Exchange Server SE im eigenen Rechenzentrum?
Die genannte EWS-Abschaltung bezieht sich auf Exchange Online. Lokale und hybride Szenarien müssen anhand des tatsächlichen Datenzugriffs unterschieden werden. Eine Anwendung auf einem lokalen Server kann trotzdem Exchange Online verwenden. Der Standort des Programms allein entscheidet daher nicht.
Reicht es, EWS vorübergehend wieder zu aktivieren?
Eine mögliche Übergangseinstellung behebt nicht die notwendige Umstellung der Anwendung. Prüfen Sie aktuelle Microsoft-Vorgaben und den tatsächlichen Tenantstatus. Jede benötigte Ausnahme sollte einen klaren Zweck, einen Verantwortlichen und einen dokumentierten Ausstiegsplan haben.
Kann jede EWS-Anwendung einfach auf Graph umgestellt werden?
Das muss anhand der verwendeten Funktionen geprüft werden. Herstellerstand, benötigte Rechte und mögliche Funktionsunterschiede sind entscheidend. Ein Pilot sollte den vollständigen Geschäftsprozess abdecken. Eine pauschale Zusage ohne Kenntnis der Anwendung wäre nicht belastbar.
Was sollten wir beim ersten Kontakt mitteilen?
Nennen Sie Anwendung, Hersteller, betroffenen Ablauf, Postfachstandort und beobachtete Fehler. Offene Punkte sind ebenfalls hilfreich. Bitte senden Sie keine Kennwörter, Tokens oder vertraulichen Nachrichteninhalte. Für die erste Einordnung genügt eine verständliche Beschreibung.
Nächster Schritt
Vorhaben unverbindlich besprechen oder 089 7412060 anrufen. Ziel des ersten Austauschs ist, den betroffenen Ablauf und den erforderlichen Prüfbedarf einzugrenzen. Umfang, Termin und Konditionen werden für das konkrete Vorhaben geklärt.
Herstellerquellen
- Microsoft Exchange Team: EWS-Übergangs- und Abschaltplan
- Microsoft Learn: Migration von EWS zu Microsoft Graph
Quellenstand: 5. November 2026. Fristen, Tenantstatus und Funktionsunterschiede sind unmittelbar vor der Umsetzung erneut zu prüfen.
