← Alle Publikationen

Legacy Modernisierung

KI-gestützte .NET Modernisierung: WebForms zu React mit Claude Code & AI Agents

Wie KI-Coding-Agenten wie Claude Code die Migration von WebForms-Anwendungen zu .NET Core und React beschleunigen. Praxisbericht mit konkreten Prompts, Workflows und ehrlicher Einordnung, wo die Grenzen liegen.

AI Coding Agents .NET Modernisierung WebForms React Claude Code Legacy Migration Strangler Fig Pattern Enterprise .NET

Sie haben eine WebForms-Anwendung, die seit 2008 läuft: 180.000 Zeilen Code, keine Tests, Deployment-Fenster nur nachts. Die klassische Rewrite-Kalkulation: 14-18 Monate, €850k-€1,2M, 6-8 Entwickler, hohes Scheiterrisiko. Genau dort, wo Big-Bang-Rewrites traditionell scheitern, verschieben KI Coding Agents die Mathematik.

Dieser Artikel zeigt anhand eines konkreten Migrationsprojekts, wo Claude Code, GitHub Copilot Workspace und Cursor AI echten Hebel liefern – und wo sie an Grenzen stoßen. Mit messbaren Zahlen aus einer realen WebForms-zu-React-Migration.

Für wen dieser Artikel relevant ist: CTOs, VPs Engineering und IT-Entscheider mit .NET-Framework-Legacy, die zwischen "weiter warten", "Big-Bang-Rewrite" und "KI-gestützter Strangler-Fig-Modernisierung" entscheiden.

Das Problem: WebForms-Modernisierung – komplex, riskant, teuer

Die Ausgangssituation

Ein realer Case: Eine geschäftskritische Banking-Lösung, entwickelt 2008 auf .NET Framework 3.5 mit ASP.NET WebForms:

Technische Charakteristika:

  • 180.000 Zeilen C# Code in Code-Behind-Files
  • 245 .aspx-Pages mit ViewState-basiertem State-Management
  • SQL Server 2008 mit 450 gespeicherten Prozeduren
  • Monolithische 3-Tier-Architektur (UI → Business Logic → Data Access)
  • UpdatePanels für "Ajax-Funktionalität"
  • Keine Unit Tests (typisch für WebForms-Ära)
  • Session-State in InProc-Mode (nicht skalierbar)

Business-Probleme:

  • Deployment nur nachts (Downtime erforderlich)
  • Mobile Experience katastrophal (nicht responsive)
  • Performance-Probleme bei Traffic-Spitzen
  • Rekrutierung neuer Entwickler unmöglich
  • Vendor-Lock-in: €180k/Jahr an externen Legacy-Dienstleister
  • Jedes neue Feature dauert 6-8 Wochen

Modernisierungsziel:

  • .NET 8 Backend (RESTful API)
  • React 18 Frontend mit TypeScript
  • PostgreSQL (Ablösung SQL Server zur Kostenreduktion)
  • Microservices-Architektur (schrittweise)
  • Cloud-ready (Azure Container Apps)
  • Comprehensive Test-Coverage (>70%)

Traditionelle Schätzung:

  • Dauer: 14-18 Monate
  • Kosten: €850k-€1.2M
  • Team: 6-8 Entwickler
  • Risiko: hoch – die Mehrzahl der Big-Bang-Rewrites scheitert oder sprengt den Rahmen

Warum WebForms-Migration so komplex ist

1. Verwoben mit dem Framework: WebForms ist kein MVC-Pattern. UI-Logik, Business-Logik und State-Management sind eng verzahnt:

// Typischer WebForms Code-Behind - schwer zu migrieren
protected void btnSubmit_Click(object sender, EventArgs e)
{
    // Validation direkt im Event-Handler
    if (string.IsNullOrEmpty(txtName.Text))
    {
        lblError.Text = "Name erforderlich";
        return;
    }

    // Business-Logik vermischt mit UI
    var customer = new Customer
    {
        Name = txtName.Text,
        Email = txtEmail.Text
    };

    // Direkter DB-Zugriff aus Code-Behind
    using (var conn = new SqlConnection(ConfigurationManager.ConnectionStrings["Main"].ConnectionString))
    {
        var cmd = new SqlCommand("INSERT INTO Customers...", conn);
        cmd.Parameters.AddWithValue("@Name", customer.Name);
        conn.Open();
        cmd.ExecuteNonQuery();
    }

    // State-Management via ViewState
    ViewState["CustomerId"] = customerId;

    // UI-Update
    GridView1.DataBind();
}

Problem: Code-Behind, Business-Logik, DB-Zugriff, State-Management – alles in einer Methode. Keine klare Trennung.

2. ViewState-Abhängigkeit: WebForms speichert State in ViewState (Hidden-Field im HTML). React hat ein komplett anderes State-Konzept.

3. Server-Controls: Buttons, GridViews, UpdatePanels – alles server-seitig gerendert. React ist client-seitig.

4. Postback-Paradigma: Jede Interaktion macht einen Roundtrip zum Server. React ist SPA (Single Page Application).

5. Fehlende Abstraktion: Keine Repositories, keine Services, keine DTOs. Code direkt gegen Datenbank.

Die Lösung: KI Coding Agents als Game-Changer

Was sind KI Coding Agents?

KI Coding Agents gehen weit über einfache Code-Completion hinaus. Sie sind autonome Systeme, die:

  • Verstehen: Komplexe Codebases analysieren und Zusammenhänge erkennen
  • Planen: Multi-Step-Refactorings orchestrieren
  • Implementieren: Code schreiben, testen, debuggen
  • Lernen: Aus Feedback verbessern und Patterns erkennen

Beispiele:

  • Claude Code (Anthropic): Terminal-basierter AI Agent mit Tool-Use
  • GitHub Copilot Workspace: Web-basierte Entwicklungsumgebung
  • Cursor AI: AI-first Code-Editor
  • Windsurf (Codeium): Flow-basierter AI Agent

Warum KI-Agenten perfekt für Legacy-Modernisierung sind

1. Pattern-Erkennung auf Steroiden: KI erkennt wiederkehrende Patterns in Legacy-Code und kann diese systematisch refactoren.

2. Multi-File-Refactoring: Modernisierung betrifft oft 50+ Dateien gleichzeitig. KI orchestriert diese Änderungen konsistent.

3. Automatisierte Test-Generierung: Legacy-Code hat oft keine Tests. KI generiert automatisch Unit- und Integration-Tests.

4. Boilerplate-Elimination: Migration produziert viel Boilerplate (DTOs, Repositories, API-Controller). KI erledigt das in Sekunden.

5. Dokumentation & Wissenstransfer: KI erklärt Legacy-Code und dokumentiert Migrations-Entscheidungen.

Praxisbeispiel: WebForms → React Migration mit Claude Code

Ich zeige Ihnen einen konkreten Workflow: Die Migration eines komplexen Customer-Management-Moduls von WebForms zu React mit .NET Core API.

Phase 1: Code-Analyse und Architektur-Design (Tag 1-2)

Ohne KI (traditionell): Entwickler verbringt 3-5 Tage mit manueller Code-Analyse, erstellt Architektur-Dokumente, skizziert API-Design.

Mit Claude Code:

# Claude Code im Terminal starten
claude-code

# Prompt für Analyse
> Analysiere die WebForms-Seite CustomerManagement.aspx und CustomerManagement.aspx.cs.
> Identifiziere:
> 1. Business-Logik (was macht der Code?)
> 2. DB-Zugriffe (welche Tabellen, welche Operationen?)
> 3. State-Management (ViewState, Session)
> 4. Validierungen
> 5. UI-Komponenten und deren Interaktionen
>
> Schlage eine moderne Architektur vor:
> - Clean Architecture (Domain, Application, Infrastructure, API)
> - REST API-Endpoints
> - React-Komponenten-Struktur
> - State-Management-Strategie (Redux vs. Context vs. React Query)

Claude Code Output (nach 2 Minuten):

## Analyse: CustomerManagement.aspx

### Business-Logik:
- CRUD-Operationen für Kunden (Create, Read, Update, Delete)
- Duplikat-Prüfung (Email-Adresse)
- Kunden-Kategorisierung (Neu, Aktiv, Inaktiv)
- Historisierung (Änderungen werden geloggt)

### Datenbank-Zugriffe:
Tabellen:
- Customers (CRUD)
- CustomerCategories (Read)
- CustomerHistory (Insert)

Gespeicherte Prozeduren:
- sp_GetCustomers (mit Paging)
- sp_InsertCustomer
- sp_UpdateCustomer
- sp_DeleteCustomer
- sp_CheckDuplicateEmail

### State-Management:
- ViewState: SortDirection, PageIndex
- Session: CurrentUser, Permissions

### Validierungen:
- Required: Name, Email
- Format: Email (Regex)
- Business-Rule: Email muss unique sein

### Vorgeschlagene Architektur:

## Backend (.NET 8)

### Domain Layer:
- Customer (Entity)
- CustomerCategory (Value Object)
- CustomerHistory (Entity)

### Application Layer:
- ICustomerService
- CustomerService
- DTOs: CustomerDto, CreateCustomerDto, UpdateCustomerDto

### Infrastructure Layer:
- EF Core DbContext
- CustomerRepository
- Mapping-Profiles

### API Layer:
Endpoints:
- GET /api/customers?page=1&pageSize=10&sortBy=name
- GET /api/customers/{id}
- POST /api/customers
- PUT /api/customers/{id}
- DELETE /api/customers/{id}
- GET /api/customers/categories

## Frontend (React + TypeScript)

### Komponenten:
- CustomerList (Table mit Paging + Sorting)
- CustomerForm (Create/Edit)
- CustomerDetails (Read-Only-View)

### State-Management:
Empfehlung: React Query
- Automatisches Caching
- Optimistic Updates
- Error Handling
- Retry-Logik

### API-Client:
- Axios mit TypeScript-Typen (generiert aus OpenAPI)

Zeitersparnis: 3-5 Tage → 2 Stunden

Phase 2: Backend-Migration – Domain & Application Layer (Tag 2-5)

Prompt an Claude Code:

Erstelle die Complete Clean Architecture für das Customer-Modul:

1. Domain Layer:
   - Customer Entity mit allen Properties aus der Customers-Tabelle
   - CustomerCategory Enum
   - CustomerHistory Entity
   - Domain Events (CustomerCreated, CustomerUpdated)

2. Application Layer:
   - ICustomerService Interface
   - CustomerService Implementation
   - DTOs (mit FluentValidation)
   - AutoMapper-Profiles

3. Infrastructure Layer:
   - EF Core DbContext
   - Entity Configurations
   - CustomerRepository (inkl. Paging, Sorting, Filtering)
   - Migration zur Erstellung der DB-Struktur

4. Unit Tests für alles (xUnit, Moq, FluentAssertions)

Nutze .NET 8 Best Practices, Null-Safety, und moderne C# Features.

Claude Code erstellt in 15 Minuten:

  • 12 C#-Dateien (Entities, Services, Repositories, DTOs)
  • EF Core Configuration und Migrations
  • 45 Unit Tests mit >85% Coverage
  • XML-Dokumentation für alle Public APIs
  • FluentValidation-Rules (Email-Validation, Duplicate-Check)

Entwickler-Rolle:

  • Review des generierten Codes (20 Min)
  • Anpassungen an Firmen-spezifische Konventionen (15 Min)
  • Lokales Testing (30 Min)

Traditionell: 3-4 Tage manuelle Implementierung Mit Claude Code: 1 Tag (inkl. Review & Testing)

Zeitersparnis: rund 70%

Phase 3: API-Entwicklung (Tag 6-7)

Prompt:

Erstelle RESTful API-Controller für das Customer-Modul:

Requirements:
- ASP.NET Core 8 Minimal APIs (kein Controller-basiert)
- OpenAPI/Swagger-Documentation
- Paging, Sorting, Filtering für GET /customers
- Validation mit FluentValidation
- Error-Handling-Middleware (Problem Details)
- Authentication/Authorization (JWT)
- API-Versioning (v1)
- Rate-Limiting
- CORS-Configuration

Zusätzlich:
- Integration Tests (WebApplicationFactory)
- Postman-Collection für manuelle Tests

Claude Code liefert:

  • Minimal API-Endpoints mit Route-Groups
  • OpenAPI-Configuration mit Examples
  • Error-Handling-Middleware
  • Authentication-Setup (JWT)
  • 25 Integration-Tests
  • Postman-Collection
  • README mit API-Usage-Examples

Besonderheit: Claude Code generiert realistische Testdaten und Edge-Case-Tests:

[Fact]
public async Task CreateCustomer_WithDuplicateEmail_Returns409Conflict()
{
    // Arrange
    var existingCustomer = new Customer { Email = "john@example.com", Name = "John Doe" };
    await _context.Customers.AddAsync(existingCustomer);
    await _context.SaveChangesAsync();

    var newCustomer = new CreateCustomerDto
    {
        Email = "john@example.com", // Duplicate!
        Name = "Jane Doe"
    };

    // Act
    var response = await _client.PostAsJsonAsync("/api/v1/customers", newCustomer);

    // Assert
    response.StatusCode.Should().Be(HttpStatusCode.Conflict);
    var problem = await response.Content.ReadFromJsonAsync<ProblemDetails>();
    problem.Title.Should().Contain("Email bereits registriert");
}

Traditionell: 2-3 Tage Mit Claude Code: 4-6 Stunden Zeitersparnis: rund 75%

Phase 4: Frontend-Migration – React Components (Tag 8-12)

Prompt:

Erstelle eine moderne React-Frontend-Anwendung für das Customer-Management:

Stack:
- React 18 + TypeScript
- Vite (Build-Tool)
- TanStack Router (Routing)
- React Query (API-State)
- TanStack Table (Data-Grid mit Paging/Sorting)
- React Hook Form + Zod (Formulare + Validation)
- Tailwind CSS (Styling)
- shadcn/ui (UI-Components)

Features:
- CustomerList mit Server-Side-Paging, Sorting, Filtering
- CustomerForm (Create/Edit) mit Inline-Validation
- CustomerDetails-View
- Error-Handling & Toast-Notifications
- Loading-States & Skeletons
- Optimistic-Updates
- TypeScript-Types generiert aus OpenAPI

Tests:
- Vitest + React Testing Library
- Component-Tests für alle UI-Components

Claude Code Workflow:

Schritt 1: Projekt-Setup (5 Min)

# Claude Code führt aus:
npm create vite@latest customer-management -- --template react-ts
cd customer-management
npm install @tanstack/react-query @tanstack/react-router react-hook-form zod
npm install -D tailwindcss vitest @testing-library/react
# ... weitere Dependencies

Schritt 2: OpenAPI → TypeScript-Types (2 Min)

# Claude Code generiert Types aus Backend-OpenAPI-Spec
npx openapi-typescript http://localhost:5000/swagger/v1/swagger.json -o src/types/api.ts

Schritt 3: API-Client-Setup (10 Min) Claude Code erstellt typsicheren API-Client:

// src/api/customersApi.ts
import { api } from './client';
import type { CustomerDto, CreateCustomerDto, UpdateCustomerDto, PagedResult } from '../types/api';

export const customersApi = {
  getCustomers: async (params: {
    page?: number;
    pageSize?: number;
    sortBy?: string;
    sortDirection?: 'asc' | 'desc';
  }): Promise<PagedResult<CustomerDto>> => {
    const response = await api.get('/customers', { params });
    return response.data;
  },

  getCustomer: async (id: string): Promise<CustomerDto> => {
    const response = await api.get(`/customers/${id}`);
    return response.data;
  },

  createCustomer: async (data: CreateCustomerDto): Promise<CustomerDto> => {
    const response = await api.post('/customers', data);
    return response.data;
  },

  updateCustomer: async (id: string, data: UpdateCustomerDto): Promise<CustomerDto> => {
    const response = await api.put(`/customers/${id}`, data);
    return response.data;
  },

  deleteCustomer: async (id: string): Promise<void> => {
    await api.delete(`/customers/${id}`);
  },
};

Schritt 4: React Query Hooks (15 Min)

// src/hooks/useCustomers.ts
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
import { customersApi } from '../api/customersApi';
import { toast } from 'sonner';

export const useCustomers = (params: CustomersQueryParams) => {
  return useQuery({
    queryKey: ['customers', params],
    queryFn: () => customersApi.getCustomers(params),
    staleTime: 30000, // 30 seconds
  });
};

export const useCreateCustomer = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: customersApi.createCustomer,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['customers'] });
      toast.success('Kunde erfolgreich erstellt');
    },
    onError: (error) => {
      toast.error('Fehler beim Erstellen des Kunden');
      console.error(error);
    },
  });
};

// ... weitere Hooks

Schritt 5: UI-Komponenten (3-4 Stunden) Claude Code generiert:

  • CustomerList mit TanStack Table (Paging, Sorting, Filtering)
  • CustomerForm mit React Hook Form + Zod-Validation
  • CustomerDetails-Card
  • Loading-Skeletons
  • Error-Boundaries
  • Toast-Notifications

Schritt 6: Component-Tests (2 Stunden)

// src/components/CustomerForm.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { CustomerForm } from './CustomerForm';

describe('CustomerForm', () => {
  it('shows validation errors for invalid email', async () => {
    render(<CustomerForm />);

    const emailInput = screen.getByLabelText(/email/i);
    await userEvent.type(emailInput, 'invalid-email');
    await userEvent.tab(); // Trigger blur

    await waitFor(() => {
      expect(screen.getByText(/gültige email-adresse/i)).toBeInTheDocument();
    });
  });

  it('submits form with valid data', async () => {
    const onSubmit = vi.fn();
    render(<CustomerForm onSubmit={onSubmit} />);

    await userEvent.type(screen.getByLabelText(/name/i), 'John Doe');
    await userEvent.type(screen.getByLabelText(/email/i), 'john@example.com');
    await userEvent.click(screen.getByRole('button', { name: /speichern/i }));

    await waitFor(() => {
      expect(onSubmit).toHaveBeenCalledWith({
        name: 'John Doe',
        email: 'john@example.com',
      });
    });
  });
});

Traditionell: 5-7 Tage für Frontend-Development Mit Claude Code: 2 Tage Zeitersparnis: rund 65%

Phase 5: Daten-Migration (Tag 13-15)

Herausforderung: Historische Daten von SQL Server 2008 → PostgreSQL, mit Schema-Änderungen.

Prompt an Claude Code:

Erstelle eine Daten-Migrations-Pipeline:

Source: SQL Server 2008 (Customers-Tabelle)
Target: PostgreSQL 16 (neue Schema-Struktur)

Requirements:
1. ETL-Script (C# Console-App) mit:
   - Bulk-Read von SQL Server (Dapper)
   - Data-Transformation (alte → neue Schema-Struktur)
   - Bulk-Insert zu PostgreSQL (Npgsql)
   - Error-Handling & Retry-Logic
   - Progress-Tracking
   - Dry-Run-Mode

2. Validation-Script:
   - Record-Count-Vergleich
   - Data-Integrity-Checks
   - Sample-Data-Verification

3. Rollback-Script (falls Migration fehlschlägt)

Migration-Strategy: Inkrementell (10.000 Records/Batch)

Claude Code erstellt:

  • ETL-Console-App mit Bulk-Operations
  • Data-Transformation-Logic (mit Unit-Tests)
  • Validation-Scripts
  • Rollback-Scripts
  • Detailliertes Logging mit Serilog
  • PowerShell-Wrapper für einfache Ausführung

Beispiel-Output:

Migration gestartet: 2025-01-22 14:30:00
Source: 245.000 Customers (SQL Server)
Target: PostgreSQL

Batch 1/25: 10.000 Records | ✓ OK | 2.3s
Batch 2/25: 10.000 Records | ✓ OK | 2.1s
...
Batch 25/25: 5.000 Records | ✓ OK | 1.8s

Migration abgeschlossen: 14:42:15
Total: 245.000 Records migriert
Dauer: 12min 15s
Fehler: 0
Validierung: ✓ PASSED

Record-Count: Source=245.000 | Target=245.000 | Match=100%

Traditionell: 3-4 Tage (inkl. Testing) Mit Claude Code: 1 Tag Zeitersparnis: rund 70%

Messbare Ergebnisse: Vorher/Nachher-Vergleich

Projekt-Metriken

Die folgenden Werte stammen aus dem beschriebenen Projekt – die Größenordnungen decken sich mit dem, was ich in vergleichbaren Migrationen sehe:

Metrik Traditionelle Schätzung Mit Claude Code Effekt
Dauer 14-18 Monate rund 6 Monate mehr als halbiert
Team-Größe 6-8 Entwickler 3-4 Entwickler etwa halbiert
Kosten €850k-€1.2M unter €500k etwa halbiert
Test-Coverage 15-20% (realistisch erreichbar) über 75% vervielfacht
Dokumentation minimal, veraltet schnell durchgängig, KI-generiert qualitativer Sprung

Code-Produktivität

Aufgabe Zeit traditionell Zeit mit Claude Code Ersparnis
API-Endpoint inkl. Tests 3-4h 30min ~85%
React-Component inkl. Tests 4-6h 1h ~80%
Daten-Migration-Script 2 Tage 4h ~75%
Unit-Test-Suite für Modul 1 Tag 2h ~75%
DTO-Klassen + Validierung 4h 15min ~90%

Business-Impact nach 12 Monaten Produktiv-Betrieb

  • Deployment-Frequenz: von einmal pro Monat auf mehrmals pro Woche
  • Time-to-Market neue Features: von 6-8 Wochen auf 1-2 Wochen
  • Performance: P95-Response-Zeit von rund 850ms auf deutlich unter 200ms
  • Mobile Experience: Bounce-Rate von rund zwei Dritteln auf unter 20%
  • Betriebskosten: von €180k auf unter €50k pro Jahr (in-house statt Vendor)
  • Developer-Zufriedenheit: in internen Umfragen deutlich gestiegen – das Team arbeitet wieder an einem Stack, für den sich auch neue Entwickler gewinnen lassen

Best Practices für KI-gestützte Modernisierung

1. KI ist Partner, nicht Ersatz

Falsch: "KI macht alles, ich schaue nur zu"

Richtig: "KI beschleunigt, ich kuratiere, validiere und treffe Architektur-Entscheidungen"

Workflow:

1. Ich: Klare Anforderungen & Kontext geben
2. KI: Implementierung vorschlagen
3. Ich: Review, Anpassungen, Domain-Wissen einbringen
4. KI: Refactoring basierend auf Feedback
5. Ich: Finale Validation & Integration

2. Iterativ vorgehen, nicht Big-Bang

Prompting-Strategie:

Schlecht: "Migriere die gesamte Anwendung zu .NET Core und React" (zu komplex, KI wird verwirrt)

Gut: "Migriere das Customer-Modul. Zuerst Backend (Domain, Application, API), dann Frontend (React-Components), dann Tests." (Schritt für Schritt, klare Phasen)

3. Kontext ist König

KI braucht Kontext:

# Schlechter Prompt
"Erstelle einen API-Controller für Kunden"

# Besserer Prompt
"Erstelle einen API-Controller für Kunden.

Kontext:
- Wir nutzen .NET 8 Minimal APIs (nicht Controller-basiert)
- Clean Architecture: Controller ruft ICustomerService auf
- Paging mit Cursor-based-Pagination (nicht Offset)
- Error-Handling via Problem-Details
- Auth: JWT mit Role-based-Authorization (Admin, User)
- API-Versioning: v1
- OpenAPI-Docs mit Examples

Firmen-Konventionen:
- Async/Await für alle I/O
- FluentValidation statt Data-Annotations
- DTOs enden mit 'Dto'
- Services enden mit 'Service'
"

4. Tests zuerst generieren lassen

Pattern:

  1. KI generiert Implementierung
  2. KI generiert Tests
  3. Entwickler führt Tests aus → Feedback
  4. KI fixt basierend auf Test-Failures

Vorteil: Tests validieren KI-Output automatisch

5. Dokumentation automatisieren

Prompt-Suffix: "Für alle generierten Code-Dateien: Erstelle XML-Docs, README.md mit Usage-Examples, und ADR (Architecture Decision Record) für wichtige Entscheidungen."

Resultat: Keine manuelle Dokumentation mehr nötig

6. Legacy-Code erst erklären lassen

Vor Refactoring:

Analysiere CustomerManagement.aspx.cs und erkläre:
1. Was macht dieser Code?
2. Welche Business-Regeln sind implementiert?
3. Welche Edge-Cases werden behandelt?
4. Welche Abhängigkeiten existieren?

Vorteil: KI versteht Legacy-Code oft besser als Menschen (keine Assumption-Bias)

7. Security & Quality nicht vernachlässigen

Immer nach Generierung:

  • Security-Scan (z.B. SonarQube, Snyk)
  • Code-Review durch Senior-Entwickler
  • Penetration-Tests für APIs
  • Performance-Tests unter Last

KI generiert schnell, aber nicht perfekt

Herausforderungen und Lösungen

Challenge 1: KI-Halluzinationen

Problem: KI "erfindet" manchmal APIs oder Libraries, die nicht existieren.

Lösung:

  • Immer kompilieren und testen
  • Dependency-Versions explizit vorgeben im Prompt
  • Review generierter NuGet-Pakete

Challenge 2: Inkonsistente Code-Qualität

Problem: KI generiert mal sehr guten, mal mittelmäßigen Code.

Lösung:

  • Code-Quality-Gates in CI/CD (SonarQube)
  • Prompts mit Firmen-Conventions anreichern
  • Iteratives Feedback ("Verbesserung: Nutze Dependency-Injection statt new")

Challenge 3: Verständnis komplexer Business-Logik

Problem: KI versteht domänen-spezifische Regeln nicht immer.

Lösung:

  • Business-Regeln explizit dokumentieren
  • Domain-Experten in Review einbinden
  • Pair-Programming: Entwickler + KI

Challenge 4: Kosten bei intensiver Nutzung

Problem: KI-APIs können bei exzessiver Nutzung teuer werden.

Lösung:

  • Cost-Tracking und Budgets
  • Caching von häufigen Prompts
  • Lokale Modelle für einfache Tasks (z.B. Code-Formatting)

Ausblick: Die Zukunft der Legacy-Modernisierung

1. Autonomous Migration Agents: KI-Agents, die komplette Module eigenständig migrieren – der Mensch liefert nur noch Oversight.

2. Visual Migration Planning: KI analysiert Legacy-Code, visualisiert Architektur, schlägt Migrations-Pfade vor (interaktiv).

3. Continuous Modernization: KI modernisiert Code kontinuierlich im Hintergrund (Tech-Debt-Reduktion als Service).

4. Cross-Platform-Migrations: Nicht nur .NET → .NET, sondern auch Java → .NET, COBOL → Modern Stack.

5. Business-to-Code: Nicht-technische Stakeholder beschreiben Anforderungen, KI generiert komplette Features.

Empfehlungen für CTOs & IT-Entscheider

Jetzt handeln, nicht abwarten:

  • Starten Sie ein Pilot-Projekt mit einem eingegrenzten Modul (nicht der gesamten Anwendung).
  • Schulen Sie Teams gezielt in Prompting-Patterns und KI-Output-Review – das sind erlernbare Skills.
  • Etablieren Sie Governance: Welcher KI-Code darf direkt in Production? Welche Review-Tiefe braucht generierter Code im Vergleich zu manuellem?
  • Messen Sie vom ersten Tag: Zeit pro Feature, Test-Coverage, Bug-Rate nach Deployment.

Die Lücke zwischen Early-Adopters und Nachzüglern wächst. Unternehmen, die heute KI-gestützte Modernisierung beherrschen, haben ab 2027 einen strukturellen Kostenvorteil bei jeder größeren Transformation.

Fazit: Der Einstieg ist machbar, die Methodik entscheidet

Die Modernisierung von .NET Framework WebForms-Anwendungen war immer komplex, riskant und teuer. KI Coding Agents verändern diese Mathematik – aber sie sind kein Wundermittel.

Erfolgreiche Modernisierung erfordert weiterhin:

  1. Klare Architektur-Vision: KI beschleunigt die Implementierung, nicht die Entscheidung, wohin Sie wollen.
  2. Iteratives Vorgehen: Modul für Modul mit Strangler-Fig-Pattern, nicht Big-Bang.
  3. Menschliche Oversight: KI generiert, Senior-Entwickler kuratieren und validieren.
  4. Cultural Change: Teams müssen lernen, mit KI als Werkzeug zu arbeiten – nicht als Konkurrenz.

Der Hebel entsteht, wo Architektur-Kompetenz auf KI-Tooling trifft. Entwickler verbringen weniger Zeit mit Boilerplate und DTO-Mapping, mehr Zeit mit Architektur-Entscheidungen, Business-Logik und Integrations-Design.

Konkret für die nächsten 30 Tage:

  1. Wählen Sie ein klar abgegrenztes Modul Ihrer Legacy-Anwendung.
  2. Etablieren Sie eine Ziel-Architektur (Clean Architecture + REST API + React ist ein guter Default).
  3. Pilotieren Sie mit einem 2-3-köpfigen Team und Claude Code oder Cursor.
  4. Messen Sie Ergebnisse – und entscheiden Sie auf dieser Basis über das Roll-out.

Nächste Schritte

Nächster Schritt

Sprechen wir über Ihre Ausgangslage.

Vertraulich, unverbindlich, 60 Minuten – mit einer fundierten Einschätzung, ob und wie ich Ihnen helfen kann.