Legacy-Modernisierung: Warum Rewrites scheitern

Die Realität der deutschen Wirtschaft

Der Empathie-Beweis: Warum Legacy existiert

Es ist leicht, über SAP-Monolithen, 20 Jahre alte Oracle-Datenbanken oder Navision-Instanzen zu lachen, die noch auf Servern im Keller laufen. Die "Silicon Valley"-Mentalität diktiert uns: "Das ist alt, das ist Müll, weg damit."

Aber wir müssen verstehen, warum diese Systeme noch da sind. Sie sind nicht dort, weil die IT-Abteilung faul ist. Sie sind dort, weil sie funktionieren. In diesen Systemen stecken 15 Jahre Prozesswissen, Millionen von Datensätzen und Business Rules, die das Unternehmen am Leben halten. Einem Mittelständler zu sagen, er soll sein Herzstück herausreißen, nur weil der Tech-Stack nicht mehr "trendy" ist, ist nicht nur arrogant – es ist geschäftsschädigend.

Die "Vibe Coding" Illusion

Hier kollidiert die Realität mit der aktuellen AI-Euphorie. Es gibt eine neue Welle von Entwicklern – ich nenne sie die "Vibe Coding Bros" – die glauben, man könne mit genug Prompts ein 50-Millionen-Euro-Unternehmen einfach "neu bauen".

Die Realität sieht anders aus:

• Daten-Schwerkraft: Du migrierst nicht mal eben 2 TB an Kundendaten mit komplexen Relationen in eine NoSQL-Cloud-Datenbank, ohne Datenintegrität zu verlieren.
• Prozess-Tiefe: Die Logik, warum Kunde X 3% Rabatt bekommt, aber nur an Dienstagen, ist oft nirgendwo dokumentiert, außer im COBOL-Code von 1998.
• Menschlicher Faktor: Mitarbeiter sind auf diese Masken geschult. Ein komplettes Rewrite bedeutet Jahre an Umschulung und Frustration.

Ich sehe Agenturen, die 6-Monats-Projekte verkaufen, um alles neu zu schreiben. Das Ergebnis? Nach 2 Jahren und verbranntem Budget wird das Projekt stillschweigend beerdigt. Das ist kein Engineering, das ist Fahrlässigkeit.

Architektur statt Abrissbirne

Der Ausweg: Der Middle-Layer (Die "Anti-Rewrite" Strategie)

Wenn "Alles neu" keine Option ist und "Alles lassen" Stagnation bedeutet, was ist die Lösung?

Ich verkaufe keine Migration. Ich verkaufe eine Fassade.

Mein Ansatz ist radikal pragmatisch: Das Legacy-System bleibt, wo es ist. Wir akzeptieren es als "System of Record". Aber wir lassen keinen Menschen mehr direkt damit interagieren. Stattdessen bauen wir einen schlanken Orchestration Layer (Middleware) davor.

Wie das funktioniert:

1. Legacy als API: Wir behandeln die alte Datenbank oder das ERP-System als reine Datenquelle.
2. Die Übersetzung: Wir bauen eine Middleware (z.B. mit Next.js API Routes oder Supabase Edge Functions), die die kryptischen Daten des Legacy-Systems (XML, SOAP, CSV) in sauberes, modernes JSON übersetzt.
3. Modernes Frontend: Der User sieht nur noch eine moderne Web-App (React/Next.js). Er merkt nicht, dass im Hintergrund ein 20 Jahre alter Server die Arbeit macht.

Das ist der Sweetspot. Du lieferst dem Kunden in Wochen eine moderne UX, ohne das Risiko einer Datenmigration einzugehen. Das System im Hintergrund kann über die nächsten 5 Jahre langsam ("Strangler Fig Pattern") ausgetauscht werden – aber erst, nachdem der Business Value geliefert wurde.

(Hot Take): Wer heute noch versucht, komplexe Business-Logik im Frontend zu lösen oder direkt im Legacy-System herumzudoktern, hat Architektur nicht verstanden. Logic belongs in the Middleware.

Das Urteil

The Verdict: Die unsexy Goldmine

Warum stürzen sich alle auf "Vibe Coding" und neue Apps? Weil es einfach ist. Es ist sauber. Niemand muss sich mit SOAP-Headern oder VPN-Tunneln herumschlagen.

Aber genau deshalb liegt hier das Geld. Die deutsche Wirtschaft (Mittelstand) braucht keine neuen Apps, die niemand nutzt. Sie brauchen Brückenbauer, die ihre massiven Datenbestände in das Jahr 2024 retten, ohne den Betrieb lahmzulegen.

Das Playbook für deine Karriere:

1. Lerne nicht nur React, lerne Integration Patterns.
2. Verstehe SOAP, REST, XML und SQL besser als jeder andere.
3. Verkaufe Geschwindigkeit durch Middleware, nicht Perfektion durch Rewrites.

Du wirst nicht der coolste Developer auf Twitter sein. Aber du wirst derjenige sein, der das System rettet, während die anderen noch am Prompten sind.

Code ist eine Liability. Integration ist der Asset.