Letzte Woche saß ich mit dem IT-Leiter eines Maschinenbauers zusammen — 180 Mitarbeitende, drei Standorte, und eine WinForms-Anwendung aus dem Jahr 2009, die mittlerweile für so ziemlich alles herhalten muss: Auftragserfassung, Lagerführung, halb-automatisierte Rechnungsstellung. Der Mann fragte mich, ob sie das "jetzt einfach mit KI modernisieren" könnten, weil er das irgendwo gelesen habe. Ich habe tief durchgeatmet und gefragt: "Was genau hast du gelesen?" Natürlich: ein Microsoft-Blogartikel.
Das ist kein Vorwurf an Microsoft. Aber es erklärt, warum ich diesen Kommentar schreibe.
Was Microsoft ankündigt
Am 16. Juni 2026, 18–22 Uhr MESZ, veranstaltet der Microsoft Reactor ein vierstündiges Livestream-Event unter dem Namen .NET Day on Agentic Modernization. Die Zielgruppe sind explizit Engineering-Teams, die unter Lieferdruck stehen und trotzdem Legacy-Schulden abbauen wollen. Das Versprechen: weniger Aufwand für Legacy-Wartung, schnellere Cloud-Migration, KI-Funktionen in bestehenden Anwendungen — ohne alles neu zu schreiben.
Die Session-Themen klingen solide: GitHub Copilot zur Unterstützung von Modernisierungs-Workflows, .NET Aspire als schrittweiser Modernisierungspfad, Migration echter WinForms- und datenintensiver Line-of-Business-Anwendungen, und der Einstieg in agentic Funktionalität mit dem Microsoft Agent Framework und Microsoft Foundry. Die Speaker-Liste ist prominent — Leute wie David Pine, Klaus Loeffelmann und Bruno Capuano kennen ihr Handwerk. Das ist kein Marketing-Bingo, das ist ein technisches Event für Entwickler.
Wie das im KMU landet — ehrlich gesagt
Ich sage dir jetzt, was ich dem IT-Leiter aus dem Maschinenbau danach gesagt habe, und was ich bei ähnlichen Mandaten immer wieder sage.
Was davon lohnt sich wirklich:
GitHub Copilot für Modernisierungs-Workflows — das ist tatsächlich der größte Quick-Win, den ich in 2025/2026 in Projekten gesehen habe. Nicht weil Copilot magisch Legacy-Code versteht, sondern weil er einem Entwickler, der mit VB.NET aus 2008 konfrontiert wird und das nie gelernt hat, genug Kontext gibt, um nicht zwei Tage mit Lesen zu verbringen. Ich habe ein Projekt, wo ein einziger Senior-Entwickler damit ca. 30 % schneller durch unbekannten Legacy-Code kommt. Das ist messbar, das ist real.
.NET Aspire als "modernisieren ohne Neuschreiiben" — hier bin ich vorsichtig optimistisch. Aspire ist in erster Linie ein Orchestrierungs- und Observability-Layer. Wenn du eine WinForms-App hast, die in einem Monolith steckt, löst Aspire dein Architekturproblem nicht. Was es löst: Du kannst neue Services drumherum bauen und diese vernünftig beobachten, ohne sofort in Kubernetes-Komplexität zu versinken. Für KMU, die einen hybriden Weg gehen — alte Anwendung läuft weiter, neue Funktionen kommen als Services dazu — ist das ein sinnvoller Ansatz. Nicht für alle, aber für viele.
WinForms-Migration — ich bin gespannt, was die Sessions konkret zeigen. WinForms-Migration ist in der Realität oft kein technisches Problem, sondern ein Dokumentations- und Verständnisproblem. Die Anwendungen sind nicht schlecht gebaut; sie sind nur nie dokumentiert worden, weil "der Franz das ja weiß". Wenn der Franz seit vier Jahren in Rente ist, wird es kompliziert. Wenn GitHub Copilot dort hilft, undokumentierte Business-Logik zu extrahieren und zu beschreiben, bevor man anfängt zu migrieren — sehr wertvoll.
Was ich mit Vorsicht behandeln würde:
Microsoft Agent Framework und Microsoft Foundry — hier wird es für den typischen KMU-Kunden abstrakt. Agentic AI ist real und nützlich, aber die meisten Mittelständler, die ich berate, haben noch keine saubere API-Schicht um ihre Legacy-Daten. Bevor du einen Agenten baust, der autonom Aufgaben ausführt, brauchst du strukturierten Datenzugang. Das ist die eigentliche Hausaufgabe. Die "Agentic"-Funktionen sind das Dach, aber das Fundament fehlt oft noch.
Azure MCP und GitHub Copilot for Azure — nützliches Werkzeug, wenn du already in Azure bist. Wenn du noch on-premise läufst oder in einer Hybrid-Situation, ist das zuerst eine Grundsatzdiskussion über Cloud-Strategie, keine Tooling-Frage.
Was im Artikel fehlt (und bei Microsoft generell oft fehlt):
Die ehrliche Antwort auf die Frage: Wie viel Entwickler-Kapazität brauche ich, um das anzugehen? Microsoft-Events sind für Engineering-Teams konzipiert, die hauptberufliche .NET-Entwickler haben. Im KMU mit 30–150 Mitarbeitenden ist die IT oft 1–3 Personen, die alles machen: Helpdesk, Infrastruktur, Anwendungspflege. Für die ist ein vierstündiges technisches Livestream zwar lehrreich, aber die Frage "wer setzt das dann um?" bleibt unbeantwortet.
Außerdem: Lizenzkosten. GitHub Copilot kostet Geld. Microsoft Foundry hat ein Pricing, das sich nach Usage richtet. Für ein Unternehmen mit einem Entwickler ist das machbar. Für ein Team von fünf? Das summiert sich schnell auf Beträge, die den Budgetfreigabeprozess triggern.
Meine konkrete Empfehlung
Schau dir das Event an — oder schau dir die Aufzeichnung danach an, denn die wird kommen. Schreibe dir heraus, welche der gezeigten Patterns zu deiner konkreten Situation passen.
Aber tu das mit einer klaren Frage im Kopf: "Welches meiner Top-3-Probleme mit der bestehenden Anwendung wird dadurch lösbar?" Nicht "wie modernisieren wir generell", sondern konkret: Zu langsame Deployments? Keine Testabdeckung? Unbekannte Business-Logik? Fehlende Schnittstellen nach außen?
Wenn deine Antwort auf diese Frage "weiß ich nicht genau" ist — dann ist das Event zwar inspirierend, aber du brauchst zuerst eine ehrliche Bestandsaufnahme deiner Legacy-Situation, bevor du in Tooling investierst.
Die Kombination "Copilot + Aspire + schrittweise Migration" ist für viele KMU-Situationen tatsächlich ein sinnvoller Weg. Aber er braucht jemanden, der versteht, was der erste Schritt für dein spezifisches System ist — und der dir nicht erzählt, dass das in drei Monaten fertig ist.
Der vollständige Original-Beitrag von .NET Blog (MS): Join us for .NET Day on Agentic Modernization Livestream
Du willst wissen, was davon für deine konkrete Situation relevant ist — und was du getrost überspringen kannst? Dann lass uns 30 Minuten reden.
— Bernhard