Een API-uitfasering is een bedrijfscontinuïteitsbesluit

Een API-uitfasering hoort niet thuis in de categorie technische schuld. Zodra die route orders, geld of bewijs draagt, is het een bedrijfscontinuïteitsbesluit.

Dat is geen theoretisch risico. Op 17 oktober 2026 is Microsoft wereldwijd begonnen met het uitschakelen van Exchange Web Services in Exchange Online. Volledig uitgeschakeld is EWS volgens Microsoft in april 2027. Microsoft verwijst naar Microsoft Graph, maar noemt tegelijk resterende gaten en mogelijkheden die geen Graph-equivalent krijgen. Een vervangende API is dus niet automatisch een vervangend bedrijfsproces.

Mijn stelling is scherp: sluit een migratieticket pas wanneer per datastroom is besloten wat er met geld, bewijs en bedrijfscontinuïteit gebeurt. De ontwikkelaar mag de nieuwe route technisch werkend noemen. De eigenaar van de uitkomst moet bepalen of de organisatie haar kan vertrouwen.

Een API-uitfasering is een bedrijfscontinuïteitsbesluit omdat één endpointwijziging een order, betaling of dossier kan stilzetten zonder een duidelijke foutmelding. De migratie is pas klaar wanneer de impact, het bewijs, de eigenaar, de deadline, de omschakeling en de terugval expliciet zijn besloten.

Een deadline is pas nuttig met een eigenaar

Een leveranciersmail bevat meestal een datum, een naam van een oude API en een aanbevolen vervanger. Dat is informatie, geen besluit. De datum zegt wanneer de leverancier stopt. Hij zegt niet welke salarisrun, factuur, voorraadmutatie of klantbelofte bij jou geraakt wordt.

De IETF maakt in RFC 9745 een onderscheid dat in veel migratietickets ontbreekt. Een Deprecation-signaal waarschuwt dat een resource wordt uitgefaseerd, maar verandert op zichzelf het gedrag nog niet. Een Sunset-datum geeft aan wanneer de resource waarschijnlijk niet meer reageert. Die twee signalen hebben dus een andere betekenis. Een groene test op de oude route bewijst niet dat je nog tijd hebt nadat de sunset is begonnen.

EWS laat ook zien waarom een eigenaar nodig is. Microsoft biedt een gebruiksrapport dat per applicatie-id, SOAP-actie, aanroepvolume en laatste activiteitsdatum laat zien wie de oude route gebruikt. De gegevens worden wekelijks verzameld en kunnen tot tien dagen vertraging hebben. Het rapport is daarom een hulpmiddel om applicatie-eigenaren te vinden, geen bewijs dat je inventaris direct compleet is.

Diezelfde grens zie ik bij Exact. Een kleine XML-route ging op 1 oktober 2026 uit, terwijl een bredere groep XML-topics vanaf januari 2027 volgt. De gevolgen verschillen per datastroom, ook wanneer alle stromen onder dezelfde Exact-koppeling vallen. Een orderimport, een voorraadexport en een boekingsstroom hebben niet automatisch dezelfde eigenaar of dezelfde toegestane vertraging.

Daarom leg ik de deadline vast op het niveau waarop het bedrijf iets kan verliezen. Niet: “Exact migreren.” Wel: “verkoopfacturen blijven binnen één werkdag aantoonbaar in de administratie, met Finance als vrijgave-eigenaar.” Dat ene verschil maakt een technische aankondiging bestuurbaar.

De API is niet de bedrijfsuitkomst

Een HTTP-status 200 zegt dat een antwoord is teruggekomen. Hij zegt niet dat de order goed is geïnterpreteerd, dat het juiste bedrag is geboekt of dat een fulfilmentstatus nog betekenis heeft. API’s vervoeren gegevens. Bedrijven leven van de gevolgen van die gegevens.

Een concreet voorbeeld staat in de Shopify-migratie: een betaling kan als geslaagd worden opgeslagen terwijl de payout niet meer matcht, of een order kan aankomen terwijl een nieuwe fulfilmentstatus uit de vertaling verdwijnt. Dat verschil tussen een technisch antwoord en een sluitende geld- en fulfilmentketen is precies waarom ik een API-uitfasering niet als een endpointwissel beoordeel.

Per datastroom moet de vraag anders klinken. Bij orders gaat het om volledigheid, identiteit en opvolging. Bij betalingen gaat het om bedrag, valuta, providerobject en boeking. Bij voorraad gaat het om de bronhouder en de vraag of een mutatie absoluut of als delta wordt geïnterpreteerd. Bij dossiers gaat het om herleidbaarheid: kan iemand later nog aantonen welke bron, versie en beslissing tot het resultaat hebben geleid?

Ook een technisch positieve status is niet altijd een vrijgave. Bij Peppol kan een bericht technisch goedgekeurd zijn terwijl de zakelijke beoordeling nog ontbreekt. Een positieve technische status is nog geen zakelijke vrijgave. Een API-migratie die alleen de transportlaag controleert, kan dus groen worden terwijl de bedrijfsbeslissing nog rood is.

Bij geldstromen is dat verschil hard. Na een timeout weet je niet altijd of de andere kant de opdracht al heeft uitgevoerd. Een nieuwe poging met een nieuwe sleutel kan dan een tweede refund of boeking maken. Een timeout na een financiële actie eerst als onzekerheid behandelen is geen overdreven voorzichtigheid. Het is de minimale voorwaarde om herstel niet in een nieuwe mutatie te laten veranderen.

Bewijs maakt het besluit controleerbaar

Een migratiebewijs is meer dan een logbestand waarin staat dat de nieuwe adapter vijfhonderd requests heeft verwerkt. Ik wil kunnen herleiden welke zakelijke uitkomsten zijn geraakt, welke verschillen zijn verklaard en wie de uitzonderingen heeft beoordeeld. Anders is “de test is groen” vooral een uitspraak over de test.

Kubernetes hanteert voor uitgefaseerde API’s een vergelijkbare gedachte. De officiële migratiehandleiding verwijst naar clientwaarschuwingen, metrics en auditinformatie om gebruik van oude API-versies te vinden. De oproep om runtimegebruik met meerdere signalen te lokaliseren is relevant buiten Kubernetes: een codezoektocht vindt niet vanzelf een connector, script of leverancier die buiten je hoofdrepository draait.

Voor een kritieke datastroom bestaat het bewijs daarom uit een kleine keten. De bronreferentie moet terug te vinden zijn. De doelreferentie moet aantonen wat is aangemaakt of gewijzigd. Tellingen, bedragen en uitzonderingen moeten een verklaarde uitkomst hebben. De gebruikte route en versie moeten vaststaan. Ten slotte moet een mens met mandaat de vrijgave hebben vastgelegd.

Dat klinkt zwaarder dan een ticket sluiten, maar het voorkomt een veel duurdere discussie achteraf. Zonder bewijs weet niemand of een verschil door de migratie komt, al vóór de migratie bestond of nog op de oude route wacht. Dan verschuift de discussie van “mogen organisaties uitfaseren?” naar “welke werkelijkheid is nu de juiste?”

Terugval is geen knop

Het woord rollback doet vaak alsof je een schakelaar omzet en de oude situatie terugkrijgt. Bij een API die alleen leest kan dat soms dicht bij de waarheid komen. Bij orders, betalingen, voorraad of facturen is teruggaan een nieuwe bedrijfsbeslissing. De nieuwe route kan al iets hebben geschreven dat de oude route niet mag herhalen.

Microsofts actuele handleiding voor een migratie zonder downtime noemt daarom vóór de verkeerswissel een rollback-eigenaar en een goedgekeurde checklist. De terugvalvolgorde is niet “zet oud weer aan”, maar verkeer naar de oude route sturen, de nieuwe route pauzeren, zo nodig configuratie herstellen en daarna de oude omgeving opnieuw valideren voordat de normale verwerking wordt hervat.

Voor een datastroom met writes voeg ik daar een zakelijke grens aan toe. Ik wil weten welke laatste sleutel betrouwbaar is, welke invoer de nieuwe route al heeft verwerkt, welke gebeurtenissen nog onderweg zijn en wie beslist over reconciliatie of correctie. Zonder die grens kunnen oud en nieuw dezelfde order opnieuw zien. Dan wordt terugval een bron van dubbele mutaties.

Microsoft schrijft diezelfde verantwoordelijkheid ook uit voor de migratie van BizTalk naar Logic Apps: controleer contracten, mappings, volgorde, retries en foutgedrag, verwerk werk dat tijdens de overgang in vlucht is, definieer rollback en haal de oude component pas na validatie weg. Dat is een continuïteitsbesluit met technische uitvoering, niet andersom.

Om eerlijk te zijn: niet iedere API vraagt een bestuursvergadering

Het tegenargument is terecht. Een simpele leesactie voor een intern rapport hoeft geen zwaar vrijgaveproces te krijgen. Als een leverancier een compatibele vervanger levert, de gegevens geen geld of bewijs raken en een eigenaar een vertraging kan accepteren, is een uitgebreid migratiedossier verspilde tijd. Ook niet iedere koppeling verdient een aparte herstelarchitectuur.

Daar ben ik het mee eens. Mijn punt is niet dat ieder endpoint een directiebesluit nodig heeft. Mijn punt is dat “technisch opgelost” geen universele afsluitstatus mag zijn. De zwaarte van het besluit moet volgen uit de uitkomst die de datastroom kan veranderen. Een melding kan wachten. Een factuur, voorraadmutatie of salarisrun vraagt bewijs, mandaat en een terugvalgrens.

Juist een vervanger die bijna hetzelfde lijkt, verdient aandacht. Microsoft adviseert Graph voor EWS, maar noemt nog openstaande parity gaps en functies waarvoor geen Graph-equivalent wordt toegevoegd. Een aanbevolen vervanger is dus een nieuwe afhankelijkheid die je per gebruiksscenario moet beoordelen. De vraag is niet of Graph modern is. De vraag is of jouw applicatie dezelfde bedrijfsuitkomst kan blijven verklaren.

Wanneer ik een migratieticket pas sluit

Een ticket is voor mij pas gereed wanneer het dossier per datastroom zes antwoorden bevat. De combinatie sluit aan op het bredere migratieadvies om semantische gelijkwaardigheid, in-vlucht werk, rollback en ondersteuning na livegang expliciet te maken.

• Geld: welke bedragen, betalingen, facturen of voorraadwaarden kunnen veranderen, en wat is de acceptatiegrens?
• Bewijs: welke bron-, doel- en versiereferenties tonen aan dat de uitkomst klopt?
• Eigenaar: welke persoon of rol mag uitzonderingen beoordelen en vrijgave of stopzetting beslissen?
• Deadline: wanneer stopt de oude route werkelijk, en op welke eerdere datum moet het besluit vallen?
• Cutover: welk verkeer, welke records en welke writes gaan wanneer naar de nieuwe route, en hoe herken je de grens?
• Terugval: wat stopt er bij een fout, wat is al verwerkt en wie beslist tussen opnieuw proberen, reconciliëren of corrigeren?

Pas daarna is de nieuwe API een technische implementatie van een genomen besluit. Voor een kleine informatiestroom kan dat dossier kort zijn. Voor geld en bewijs kan het niet worden vervangen door een vinkje op “migratie uitgevoerd”.

Een endpoint kan verdwijnen zonder dat een bedrijf mag verdwijnen. Daarom behandel ik API-uitfasering als een besluit over continuïteit: techniek is pas af wanneer de verantwoordelijkheid, het bewijs en de terugweg even echt zijn als de nieuwe route.