Migration | The .NET Blog

Die Monkey Work der Migration mit Agentic Platform Engineering beseitigen

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Removing the Monkey Work of Migration with Agentic Platform Engineering — eine Schritt-für-Schritt-Anleitung von Git-Ape (git agentic platform engineering tool), das ein echtes AWS-Terraform-Repo zu Azure migriert, mit Fokus auf Intent-Extraktion statt zeilenweiser Konvertierung.

Die Eingabe: contoso-migration

Die Quelle ist ein echtes Terraform-Projekt (contoso-migration), das eine Next.js-App auf AWS bereitstellt — EC2 für Compute, ALB für Load Balancing, S3 für Artefakte und IAM-Schlüssel für Identität. Kosten: ~34 $/Monat. Das Ziel ist nicht, dieselbe Infrastruktur auf Azure zu reproduzieren; es geht darum herauszufinden, was das Deployment eigentlich tun soll, und das mit nativen Azure-Diensten neu aufzubauen.

Schritt 1: Validierung und Authentifizierung

Git-Ape beginnt damit, alle erforderlichen CLI-Tools zu validieren — az, aws, gh, jq, git — und aktive Auth-Sessions zu bestätigen, bevor etwas angerührt wird. Keine Teilausführungen.

Schritt 2: Intent-Extraktion

Der Agent liest das gesamte Quell-Repository über die GitHub API und extrahiert den Deployment-Intent: Laufzeit (Node.js), Compute-Typ, Ingress-Muster, Artefakt-Handling, Identitätsmodell, Netzwerk und Monitoring. Dies ist der entscheidende Schritt — es wird ein semantisches Modell dessen erstellt, was das Deployment tut, nicht welche Terraform-Keywords es verwendet.

Schritt 3: Service-Mapping

AWS-Dienste werden auf Azure-Äquivalente abgebildet:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Integriertes App Service Load Balancing
IAM-Rollen/Schlüssel → Managed Identity
Terraform → Bicep + GitHub Actions

Schritt 4: Kritik-Agent

Vor der Ausgabegenerierung läuft ein Kritik-Agent und erkennt zwei blockierende Probleme:

Build-on-Startup-Antimuster — das ursprüngliche Terraform führte npm install && npm run build auf EC2 beim Start aus. Fix: In CI bauen, ein fertiges Artefakt deployen.
Unnötiger Blob Storage — S3 wurde für Artefakt-Staging verwendet, das mit korrektem CI/CD eliminiert werden könnte. Der Kritik-Agent hat es vollständig entfernt.

Schritt 5: Generierte Ausgabe

Das Ergebnis sind ~80 Zeilen Bicep statt der ursprünglichen 200+ Zeilen Terraform. Der Agent erstellte ein neues GitHub-Repo mit infra/main.bicep und .github/workflows/deploy.yml und entfernte alle AWS-spezifischen Dateien.

Vergleich der Sicherheitslage

Die Migration ergab auch eine bedeutende Sicherheitsverbesserung:

AWS-Original	Azure-Ausgabe
Nur HTTP	Nur HTTPS, TLS 1.2
SSH offen für 0.0.0.0/0	Keine SSH-Exposition
IAM-Zugriffsschlüssel	OIDC + Managed Identity
Kein Monitoring	Application Insights

Kosten: ~13 $/Monat vs. ursprüngliche 34 $/Monat.

Was dies von einem Syntax-Konverter unterscheidet

Der Kritik-Agent-Schritt ist das, was dies von einer mechanischen Übersetzung trennt. Er erkannte Muster, die auf AWS funktioniert hätten, aber auf Azure falsch wären — und korrigierte sie, anstatt sie zu replizieren. Die Ausgabe ist kein “AWS in Azure-Syntax”; es ist ein Azure-natives Deployment, das dasselbe Ziel sauberer erreicht.

Siehe die vollständige Anleitung für die vollständige Agent-Ablaufverfolgung und generierte Dateien.

GitHub Copilots Modernisierungs-Assessment ist das beste Migrationstool, das du noch nicht nutzt

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Eine Legacy-.NET-Framework-App auf modernes .NET zu migrieren ist eine dieser Aufgaben, von der jeder weiß, dass sie erledigt werden sollte, die aber niemand anfangen will. Es ist nie nur „ändere das Ziel-Framework." Es sind APIs, die verschwunden sind, Pakete, die nicht mehr existieren, Hosting-Modelle, die völlig anders funktionieren, und eine Million kleiner Entscheidungen darüber, was containerisiert, was umgeschrieben und was in Ruhe gelassen werden soll.

Jeffrey Fritz hat gerade einen tiefen Einblick in GitHub Copilots Modernisierungs-Assessment veröffentlicht, und ehrlich? Das ist das beste Migrationstooling, das ich für .NET gesehen habe. Nicht wegen der Code-Generierung — das ist mittlerweile Standard. Wegen des Assessment-Dokuments, das es erstellt.

Es ist nicht nur eine Code-Vorschlagsmaschine

Die VS Code-Erweiterung folgt einem Bewerten → Planen → Ausführen-Modell. Die Bewertungsphase analysiert deine gesamte Codebase und erstellt ein strukturiertes Dokument, das alles erfasst: was sich ändern muss, welche Azure-Ressourcen provisioniert werden müssen, welches Deployment-Modell verwendet werden soll. Alles Nachfolgende — Infrastructure as Code, Containerisierung, Deployment-Manifeste — leitet sich aus den Ergebnissen des Assessments ab.

Das Assessment wird unter .github/modernize/assessment/ in deinem Projekt gespeichert. Jeder Durchlauf erzeugt einen unabhängigen Report, sodass du eine Historie aufbaust und verfolgen kannst, wie sich deine Migrationsposition entwickelt, wenn du Issues behebst.

Zwei Wege zum Start

Empfohlenes Assessment — der schnelle Weg. Wähle aus kuratierten Domains (Java/.NET Upgrade, Cloud Readiness, Sicherheit) und erhalte aussagekräftige Ergebnisse ohne Konfigurationsaufwand. Ideal für einen ersten Blick, wo deine App steht.

Benutzerdefiniertes Assessment — der gezielte Weg. Konfiguriere genau, was analysiert werden soll: Ziel-Compute (App Service, AKS, Container Apps), Ziel-OS, Containerisierungsanalyse. Wähle mehrere Azure-Ziele, um Migrationsansätze nebeneinander zu vergleichen.

Diese Vergleichsansicht ist wirklich nützlich. Eine App mit 3 obligatorischen Issues für App Service könnte 7 für AKS haben. Beides zu sehen hilft bei der Hosting-Entscheidung, bevor man sich auf einen Migrationspfad festlegt.

Die Issue-Aufschlüsselung ist umsetzbar

Jedes Issue kommt mit einem Kritikalitätslevel:

Obligatorisch — muss behoben werden, sonst scheitert die Migration
Potenziell — könnte die Migration beeinflussen, braucht menschliche Beurteilung
Optional — empfohlene Verbesserungen, blockiert die Migration nicht

Und jedes Issue verlinkt zu betroffenen Dateien und Zeilennummern, liefert eine detaillierte Beschreibung dessen, was falsch ist und warum es für deine Zielplattform wichtig ist, gibt konkrete Behebungsschritte (nicht nur „repariere das") und enthält Links zur offiziellen Dokumentation.

Du kannst einzelne Issues an Entwickler weitergeben, und sie haben alles, was sie zum Handeln brauchen. Das ist der Unterschied zwischen einem Tool, das dir sagt „es gibt ein Problem" und einem, das dir sagt, wie du es löst.

Die abgedeckten Upgrade-Pfade

Für .NET spezifisch:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Jeder Upgrade-Pfad hat Erkennungsregeln, die wissen, welche APIs entfernt wurden, welche Patterns kein direktes Äquivalent haben und welche Sicherheitsprobleme Aufmerksamkeit erfordern.

Für Teams, die mehrere Apps verwalten, gibt es auch ein CLI, das Multi-Repo-Batch-Assessments unterstützt — alle Repos klonen, alle bewerten, App-spezifische Reports plus eine aggregierte Portfolio-Ansicht bekommen.

Meine Einschätzung

Wenn du auf Legacy-.NET-Framework-Apps sitzt (und seien wir ehrlich, die meisten Enterprise-Teams tun das), ist dies das Tool zum Starten. Allein das Assessment-Dokument ist die Zeit wert — es verwandelt ein vages „wir sollten modernisieren" in eine konkrete, priorisierte Liste von Arbeitspaketen mit klaren Wegen nach vorn.

Der kollaborative Workflow ist auch clever: Assessments exportieren, mit deinem Team teilen, importieren ohne erneut auszuführen. Architektur-Reviews, bei denen die Entscheider nicht diejenigen sind, die die Tools ausführen? Abgedeckt.

Zusammenfassung

GitHub Copilots Modernisierungs-Assessment verwandelt .NET-Migration von einem beängstigenden, undefinierten Projekt in einen strukturierten, nachverfolgbaren Prozess. Starte mit einem empfohlenen Assessment, um zu sehen, wo du stehst, und nutze dann benutzerdefinierte Assessments, um Azure-Ziele zu vergleichen und deinen Migrationsplan zu erstellen.

Lies den vollständigen Walkthrough und hole dir die VS Code-Erweiterung, um es an deinem eigenen Code auszuprobieren.