Microsoft stänger av EWS 2027, och det avslöjar hur många system som byggts på lånad tid

Den 1 oktober 2026 börjar Microsoft inaktivera Exchange Web Services i Exchange Online. Den 1 april 2027 är API:et helt borta. Mellan de datumen sker avvecklingen i faser, vilket i praktiken betyder att många organisationer får sina integrationer avbrutna vid en tidpunkt de inte själva bestämmer. Ersättningen heter Microsoft Graph och den täcker det mesta men inte allt. Problemet är sällan migreringen i sig. Problemet är att ingen vet vilka system som faktiskt använder EWS.

Nästan tjugo år av kod skrevs mot ett gränssnitt som ingen tänkte på

EWS lanserades runt 2006 och blev snabbt standardsättet att låta programvara prata med Exchange. Arkiveringssystem, tidrapporteringsverktyg, CRM-integrationer, mötesbokningspaneler i konferensrum, HR-system som skapar kalenderposter automatiskt. Allt det byggdes på EWS, ofta av konsulter som slutade för länge sedan, ofta i system som fortfarande fungerar och därför aldrig fått en översyn.

Microsoft slutade utveckla EWS redan i juli 2018. Då meddelade företaget att API:et inte skulle få några nya funktioner, vilket är den första fasen i varje avveckling. År 2023 kom beskedet att oktober 2026 blev startdatum för inaktivering, enligt Microsofts egen officiella avvecklingsplan. Sedan hände något som ändrade tempot, nämligen intrånget i januari 2024, det som brukar kallas Midnight Blizzard, som involverade EWS. Efter det utökades omfattningen från att gälla tredjepartsappar till att omfatta Microsofts egna produkter också, alltså Outlook, Office, Teams och Dynamics 365.

Åtta år från besked till avstängning är gott om tid. Det är också precis så lång tid att den som fick beskedet 2018 hunnit byta jobb två gånger.

Graph täcker det mesta men inte kalendernotifieringar

Migreringen till Graph är rakare än många fruktar. De vanligaste scenarierna har direkta motsvarigheter och Microsoft har släppt EWS Usage Reports och en kodanalysator som pekar ut var beroendena sitter. Under 2025 tillkom även AI-assisterad migrationsvägledning.

Men det finns luckor och de sitter på irriterande ställen. Graph kan inte undertrycka mötesmeddelanden när kalenderhändelser skapas eller uppdateras, något EWS klarade. Det låter litet tills man tänker på ett system som synkroniserar tusentals kalenderposter per natt. Vid höga volymer kan de genererade notifieringarna pressa en postlåda mot de dagliga skickgränserna inom ett dygn. Inkrementell bearbetning av icke-e-postmappar, alltså kalender och uppgifter, har också haft problem som Microsoft åtgärdat men med efterverkningar. Import och export av postlådor via Graph var fortfarande i preview under 2025, något som Transvaults genomgång av migreringen också pekar på som en riskpunkt för organisationer med stora arkiv.

Det innebär att en organisation kan göra allt rätt, byta API enligt boken och ändå landa i en driftsituation som inte fanns tidigare. Testmiljön avslöjar det sällan eftersom volymerna där är för små.

Frontline- och kiosklicenser kan bli dyrare efter EWS-bytet

Här ligger fällan som kostar mest att hitta sent. Den tekniska lösningen, ersättnings-API:et och den användarlicens som krävs för att komma åt det stämmer inte nödvändigtvis överens. Microsoft har separat aviserat att åtkomsten till EWS övervakas för frontline- och kiosklicensiering, vilket särskilt drabbar organisationer med många deltidsanställda eller skiftpersonal på delade konton. Vård, handel, industri och kommunal verksamhet i Sverige använder den licenstypen i stor omfattning.

En utvecklare som får uppdraget ”byt EWS mot Graph” upptäcker inte att femhundra användare plötsligt behöver en dyrare licens. Det upptäcker inköp, när fakturan kommer.

Kartlägg exponeringen innan hösten 2026

Börja med att köra Microsofts användningsrapporter över hela tenanten och spara utfallet. Rapporten visar vilka applikationer som anropar EWS men den namnger dem sällan begripligt. Ett anrop från ”generic app” kan vara ett arkiveringssystem eller ett skript någon skrev 2014. Att koppla ihop appidentiteten med en faktisk systemägare är arbetet, inte att läsa rapporten.

Gå sedan igenom leverantörsavtalen. Fråga varje leverantör av system som rör post, kalender eller kontakter rakt ut om de kört sin Graph-migrering i produktion hos befintliga kunder, inte om den finns i roadmapen. Skillnaden mellan de svaren är ungefär ett år av väntetid.

Ta med inköp och licensansvariga i samma möte som utvecklarna. Det är den enda punkten på listan som brukar hoppas över och den enda som blir dyr i efterhand.

Och lägg planeringsdatumet före oktober 2026, inte före april 2027. Avvecklingen sker i faser och Microsoft avgör vilken tenant som hamnar i vilken fas.

Nästa avveckling är redan påbörjad, du vet bara inte vilken

EWS är inte ett undantag. Det är hur ett moget API dör hos varje stor plattformsleverantör: nya funktioner upphör, ett årtal annonseras, en säkerhetsincident flyttar fram tempot och sedan stängs det. Samma mönster har vi sett hos Google, hos betalleverantörer, hos molnleverantörernas äldre autentiseringsmetoder. TLS 1.2 fick nyligen samma behandling när IETF frös standarden, fast där gäller det en öppen standard och inte en enskild leverantörs beslut.

Skillnaden är avgörande. En öppen standard kan ingen enskild aktör stänga av. Ett leverantörsstyrt gränssnitt kan stängas av på ett datum som bestäms i ett annat land av en produktchef du aldrig kommer att träffa.

Praktiskt betyder det att varje integration mot ett proprietärt API bör ha en ägare med namn, ett dokumenterat syfte och en anteckning om vad som händer om gränssnittet försvinner. Inte som en policy i en pärm, utan som ett fält i systemförteckningen. Organisationer som infört den vanan hittar sina EWS-beroenden på en eftermiddag. De som inte gjort det får ägna hösten 2026 åt att gissa sig fram, samtidigt som mötesbokningen i konferensrummet slutar fungera.

Det är också ett argument för att hålla nere antalet ställen där ett externt gränssnitt anropas direkt i koden. Samma tanke som ligger bakom att flytta beroendehanteringen ut ur komponenterna: ju färre platser som känner till leverantörens API, desto färre platser behöver ändras när leverantören ändrar sig.

FAQ

Måste vi vara klara till 1 oktober 2026 eller 1 april 2027?

Planera mot oktober 2026. Avvecklingen sker i faser mellan de två datumen och Microsoft bestämmer ordningen, så april 2027 är ett slutdatum snarare än en deadline du kan räkna med.

Vad händer med en integration som inte migrerats i tid?

Anropen börjar helt enkelt misslyckas. Det finns ingen övergångsperiod med varningar i själva svaret, så ett system som synkroniserar kalendrar eller arkiverar post slutar fungera utan att någon nödvändigtvis larmar. Effekten märks ofta först när en användare rapporterar att en bokning inte dyker upp.

Kan administratörer stänga av EWS själva innan avvecklingen?

Ja. Microsoft har ett administrations-API i preview som låter administratörer inaktivera EWS på både organisations- och användarnivå. Det är ett bra sätt att testa vad som slutar fungera, förutsatt att du gör det på en avgränsad grupp först.

Täcker Microsoft Graph allt EWS gjorde?

Nej. De flesta scenarier har direkta motsvarigheter men undertryckning av mötesnotifieringar saknas och import och export av postlådor var fortfarande i preview under 2025. Kontrollera de specifika anropen dina system använder innan du planerar tidplanen.