In vielen Azure-Umgebungen, die ich in den letzten Monaten betreut habe, laufen noch alte Application-Gateway-v1-Instanzen. Zwischen den moderneren Diensten fallen sie oft kaum auf. Seit feststeht, dass die Standard- und WAF-v1-SKUs am 28. April 2026 endgültig aus Azure verschwinden, hat die Migration von Application Gateway v1 eine feste Frist. Die paar Gateways zu kennen, die in der zentralen Doku stehen, genügt dafür nicht. In gewachsenen Umgebungen tauchen v1-Gateways immer wieder dort auf, wo niemand sie erwartet: manchmal als vergessene Test-Workloads, oft aber auch mitten im Produktivbetrieb.

Resource Graph spürt alle betroffenen v1-Gateways zuverlässig auf

Solange die Übersicht über sämtliche v1-Gateways fehlt, plant man jede Migration im Blindflug. Zum Glück lassen sie sich mit Azure Resource Graph direkt im Azure-Portal recht zuverlässig finden. Dazu öffnet man den Resource Graph Explorer und führt diese Abfrage aus:

resources
| where type =~ "microsoft.network/applicationgateways"
| where properties.sku.tier in~ ("Standard","WAF")

Die Abfrage liefert alle Application-Gateway-v1-Instanzen im aktuellen Directory, und zwar über sämtliche Subscriptions hinweg. Man braucht dafür mindestens Leseberechtigung auf die Subscriptions, in der Praxis meist über die Rolle „Reader“ oder „Contributor“. Die Treffer exportiert man am besten und gleicht sie mit den Teams ab, die die jeweiligen Workloads betreiben. In manchen Umgebungen lohnt sich zusätzlich ein Blick in ältere Dokumentation oder auf die Tags. So rutschen auch Gateways nicht durch, die vorübergehend abgeschaltet oder umbenannt wurden.

Praxistipp: Vergebt auf Gateways und den zugehörigen Ressourcen konsequent Azure-Tags wie „owner“, „env“ oder „criticality“. Das macht die Migration von Application Gateway v1 einfacher und zahlt sich auf lange Sicht auch bei Governance und Kostenkontrolle aus.

Die offizielle Abkündigung findet ihr unter Application Gateway v1 retirement, Hinweise zur Umstellung unter Migrate Application Gateway v1 to v2.

Das Clone-Skript liefert einen Ausgangspunkt, ein Neuaufbau ist oft sauberer

Für die eigentliche Migration bietet Microsoft inzwischen ein unterstütztes PowerShell-Skript an, das bestehende v1-Konfigurationen auf ein v2-Gateway überträgt. Es liest die aktuellen Einstellungen aus, legt eine neue v2-Instanz an und übernimmt Listener, Backend-Pools und Regeln. In meinen Projekten hat sich gezeigt, dass das Skript gut für den Einstieg taugt, aber selten ohne Nacharbeit auskommt. Individuelle Konfigurationen, Custom Health Probes oder komplexe Rewrite-Regeln muss man meist von Hand nachziehen. Stehen ohnehin größere Modernisierungen an, fährt man mit einem kompletten Neuaufbau über das Portal oder per ARM-/Bicep-Templates häufig besser.

Bei WAF-Gateways kommt ein wichtiger Unterschied hinzu. Die v2-SKU arbeitet ausschließlich mit WAF-Policies und nicht mehr mit der alten WAF-Konfiguration direkt am Gateway. Die bestehende WAF-Konfiguration muss deshalb entweder manuell als Policy nachgebaut oder automatisiert migriert werden. Besonders sorgfältig sollte man dabei die Ausnahmeregeln, die Custom Rules und die Logik für einzelne Anwendungsfälle übertragen. Für einen Testlauf mit produktionsnahen Daten und echtem Traffic sollte unbedingt Zeit im Plan stehen.

Bei IP-Adresse, Zertifikaten und DNS hakt es am häufigsten

Über einen Punkt wird in fast jedem Projekt diskutiert: Nach der Migration hat das Gateway in der Regel eine andere öffentliche IP-Adresse. Vermeiden lässt sich das nur, indem man die v1-IP löscht und direkt der v2-Instanz zuweist. Dafür nimmt man allerdings einen kurzen Ausfall in Kauf und braucht einen sauberen DNS-Cutover. Bei geschäftskritischem Traffic muss das Timing genau stimmen. Ich rate dazu, die DNS-TTLs vorab zu senken und das Wartungsfenster mit allen beteiligten Teams abzustimmen.

Auch das neue v2-Gateway braucht für seine HTTPS-Listener die passenden TLS-Zertifikate. Am besten legt man sie in Azure Key Vault ab, denn das erleichtert Zertifikatswechsel und Automatisierung. Viele ältere v1-Gateways arbeiten noch mit Zertifikaten, die direkt auf der Ressource hinterlegt sind. Spätestens jetzt ist der richtige Zeitpunkt, auf Key Vault umzustellen.

Zwischen Planung und Abschluss lauern immer wieder dieselben Fallstricke

Eine Migration ist nie nur ein Technikprojekt. In der Praxis begegnen mir häufig diese Schwierigkeiten:

  • fehlende oder veraltete Dokumentation der bestehenden Regeln und Probes
  • Abhängigkeiten von älteren Firewall- oder Netzwerkkonfigurationen (z. B. NSGs, UDRs, Private Endpoints)
  • nicht dokumentierte Custom-Skripte oder Extension-Integrationen
  • unzureichend getestete WAF-Ausnahmeregeln nach der Übernahme
  • fehlendes Monitoring während und nach der Migration

Monitoring und Logging gehören deshalb früh in die Planung, etwa über Azure Monitor und eigene Alerts. Dann fallen Ausfälle oder schleichende Fehler schnell auf. Wer regelmäßig mit Azure arbeitet, kennt das Muster: Bei Migrationen werden längst vergessene Abhängigkeiten oder alte Automatisierungen auf einmal kritisch.

Die Migration ist ein guter Anlass, die Governance aufzuräumen

Mein persönlicher Rat zum Schluss: Nutzt die Migration, um eure gesamte Application-Gateway-Landschaft zu konsolidieren und zu modernisieren. Oft lohnt es sich, bei der Gelegenheit auch Zertifikatsmanagement, Logging, Tags und Zugriffskonzepte auf den aktuellen Stand zu bringen. Wer alles sauber dokumentiert, etwa als ARM-Template oder in Bicep, tut sich bei künftigen Audits und Änderungen deutlich leichter.

Damit der grobe Ablauf einer typischen Migration greifbarer wird, habe ich das folgende Mermaid-Diagramm erstellt. Es zeigt die wichtigsten Schritte und wie die Ressourcen zusammenhängen:

flowchart TD
    v1gw["App Gateway v1"] --> config["Konfiguration erfassen"]
    config --> clone["Migration/Clone v2"]
    clone --> v2gw["App Gateway v2"]
    v2gw --> certs["Zertifikate in Key Vault"]
    v2gw --> wafpol["WAF Policy anlegen"]
    v2gw --> publicip["Neue Public IP"]
    publicip --> dns["DNS Cutover"]

Abbildung: Migration von Application Gateway v1 – vom alten Gateway zur v2-Instanz mit WAF-Policy, Key Vault und DNS-Umschaltung.

Weitere Beiträge zu Azure-Netzwerken, Migrationen und Governance findet ihr regelmäßig hier im Blog, zum Beispiel zur Governance in der Azure Landing Zone oder zur Kostenkontrolle in Azure. Wer jetzt anfängt, hat bis April 2026 genug Zeit für eine saubere und risikoarme Migration. Das gilt allerdings nur, wenn die kritischen Punkte früh auf dem Tisch liegen.