Microsoft Advertising SOAP-Ende 2027: REST-Migration jetzt planen
Microsoft Advertising gibt Entwicklern mehr Zeit für die Umstellung seiner API. Neue Funktionen und Erweiterungen sollten ursprünglich ab dem 1. Oktober 2026 nur noch über die REST API verfügbar sein. Diesen Zwischenschritt hat Microsoft gestrichen: SOAP und REST sollen bis zur vollständigen Abschaltung von SOAP am 31. Januar 2027 parallel mit neuen Funktionen versorgt werden.
Für PPC-Teams ist das vor allem eines: zusätzliche Migrationszeit, aber keine neue Zielarchitektur. Wer eigene Reporting-Skripte, Feed-Prozesse, Bid-Management-Lösungen oder andere Automatisierungen auf der Microsoft-Advertising-API betreibt, sollte die Verlängerung deshalb nicht als Anlass nehmen, die Umstellung aufzuschieben. Der harte Termin bleibt bestehen.
Was Microsoft geändert hat
Microsoft hatte im April 2026 angekündigt, REST zur Grundlage der künftigen Microsoft-Advertising-API zu machen. Der ursprüngliche Fahrplan sah zwei Stufen vor: Ab 1. Oktober 2026 sollten neue Features und Erweiterungen ausschliesslich über REST bereitgestellt werden. Die SOAP API sollte anschliessend am 31. Januar 2027 vollständig eingestellt werden.
Im September-Produktupdate hat Microsoft den ersten dieser beiden Termine geändert. Neue Funktionen und Erweiterungen bleiben nun bis zum Ende der SOAP API sowohl über SOAP als auch REST verfügbar. Das endgültige Abschaltdatum 31. Januar 2027 wurde dagegen nicht verschoben.
Das reduziert den kurzfristigen Druck. Eine SOAP-basierte Integration verliert im vierten Quartal 2026 nicht plötzlich den Zugriff auf neue Funktionen, nur weil sie noch nicht migriert wurde. Gleichzeitig verkürzt sich damit aber die Sicherheitsmarge vor dem eigentlichen Endtermin.
Die weiteren Änderungen aus demselben Update ordnet der Beitrag zu Microsoft Ads und HubSpot ein.
Warum Aufschieben riskant bleibt
Bei einer API-Migration besteht das Risiko selten nur darin, dass ein Endpoint anders heisst. Entscheidend sind die Prozesse, die an der Schnittstelle hängen.
Ein PPC-Team sollte deshalb zunächst inventarisieren, welche produktiven Abläufe Microsoft Advertising automatisiert ansprechen. Dazu können tägliche Reporting-Jobs, Budget-Pacing, Kampagnenerstellung, Bulk-Änderungen, Feed-Prozesse oder Datenimporte in BI-Systeme gehören. Besonders relevant sind Integrationen, die zwar seit Jahren stabil laufen, aber nur selten aktiv gewartet werden.
Je später die Migration erfolgt, desto weniger Zeit bleibt für Paralleltests. Genau diese Parallelphase ist wertvoll: SOAP und REST können vor der Abschaltung noch gegeneinander geprüft werden. Teams können beispielsweise kontrollieren, ob Reports dieselben Zeilen und Kennzahlen liefern, ob Mutationen identisch ausgeführt werden und ob Fehlerbehandlung, Authentifizierung und Rate Limits im produktiven Betrieb wie erwartet funktionieren.
Der zusätzliche Zeitraum bis Januar sollte daher eher als Testfenster verstanden werden als als neue Deadline für den Projektstart.
SDK-Nutzer und direkte SOAP-Integrationen unterscheiden
Microsoft nennt zwei Migrationspfade.
Wer ein Microsoft-Advertising-SDK verwendet, sollte die von Microsoft bereitgestellte SDK-Migrationsdokumentation nutzen. Damit lässt sich die Umstellung innerhalb der bestehenden Bibliothekslogik vorbereiten.
Bei Integrationen ohne SDK müssen REST-Endpunkte und Request-Formate direkt angepasst werden. Microsoft verweist hierfür auf seine REST-API-Referenz. Gerade bei historisch gewachsenen internen Skripten kann dieser zweite Fall mehr Aufwand verursachen, weil nicht nur die Transportebene, sondern möglicherweise auch eigene Wrapper, Fehlerbehandlung und Tests angepasst werden müssen.
Microsoft empfiehlt Nicht-SDK-Nutzern zudem zu prüfen, ob die Migration ein sinnvoller Zeitpunkt für den Wechsel auf ein SDK ist.
Was PPC-Verantwortliche jetzt konkret tun sollten
Der erste Schritt ist keine Codeänderung, sondern eine Bestandsaufnahme. Für jede Microsoft-Ads-Integration sollten Verantwortliche, verwendete API-Technologie und geschäftliche Kritikalität dokumentiert werden.
Danach sollte geprüft werden, ob die Anwendung SOAP direkt verwendet oder ob ein SDK die API-Kommunikation abstrahiert. Davon hängt der Migrationsweg ab.
Für produktionskritische Prozesse ist ein Paralleltest sinnvoll. Ein Reporting-Job kann beispielsweise für einen definierten Zeitraum über beide Schnittstellen laufen, ohne dass die REST-Variante bereits produktive Änderungen schreibt. Unterschiede bei Daten, Laufzeit oder Fehlern werden dadurch sichtbar, bevor SOAP abgeschaltet wird.
Bei schreibenden Automatisierungen sollte der Test kontrollierter erfolgen. Kampagnen- oder Budgetänderungen sollten nicht gleichzeitig über zwei Systeme produktiv ausgeführt werden. Stattdessen bieten sich Testkonten, begrenzte Testobjekte oder ein klar definierter Cutover an.
Zum Abschluss gehört auch die Betriebsseite: Monitoring und Fehlermeldungen müssen nach der Migration weiterhin funktionieren. Eine technisch erfolgreiche API-Anfrage reicht nicht, wenn ein nächtlicher Job bei Fehlern niemanden alarmiert.
Was sich für Agenturen und Tool-Anbieter ändert
Für Agenturen ohne eigene Microsoft-Advertising-API-Integration ist die Änderung meist nicht unmittelbar operativ. Wer ausschliesslich im Microsoft-Advertising-Interface arbeitet, muss wegen der SOAP-Abschaltung nichts migrieren.
Anders sieht es bei Agenturen mit eigenen Reporting- oder Automatisierungslösungen sowie bei Ad-Tech-Anbietern aus. Dort sollte die Abhängigkeit von SOAP jetzt explizit geprüft werden. Auch Drittanbieter sollten nach ihrem Migrationsstatus gefragt werden, wenn deren Ausfall Reporting, Budgetsteuerung oder Kampagnenbetrieb beeinträchtigen könnte.
Für DACH- und Schweizer Teams ist dabei weniger die regionale Verfügbarkeit entscheidend als die technische Abhängigkeit: Die API-Umstellung betrifft die verwendete Integration, nicht ein bestimmtes Werbemarkt-Setup.
Die Verlängerung ist ein Testfenster, kein Strategiewechsel
Microsoft hat den Übergang entschärft, aber nicht die Richtung geändert. REST bleibt die künftige Basis der Microsoft-Advertising-API, und SOAP soll am 31. Januar 2027 enden.
Die praktische Konsequenz ist deshalb nicht, die Migration bis Januar zu vertagen. Teams gewinnen vielmehr knapp vier Monate, in denen bestehende SOAP-Prozesse weiter vollständig unterstützt werden und parallel gegen REST getestet werden können. Wer dieses Fenster nutzt, reduziert das Risiko eines hektischen Cutovers kurz vor der Abschaltung.