Start › Blog

Migration mit KI 31. Juli 2026 10 Minuten

Wie ein Altsystem von 2017 in einem Monat serverlos wurde

Nicht „KI macht es schnell“. Sondern: KI macht es schnell, wenn die Leitplanken vorher stehen. Ein Erfahrungsbericht mit echten Zahlen – und mit den Stellen, an denen es beinahe schiefgegangen wäre.

Ausgangslage

Listenflohmarkt.org ist eine Plattform für kommissionsbasierte Flohmärkte – Kinderkleiderbasare und Ähnliches. Veranstalter legen Events an, Verkäufer bekommen nummerierte Listen, erfassen ihre Artikel und drucken Etiketten. Am Veranstaltungstag laufen Check-in, Kassenverkauf per Barcode, Check-out und Auszahlung.

Das System lief seit 2017: ein gewachsener PHP-Monolith mit MySQL-Datenbank auf einem gemieteten Server. Es funktionierte. Es war nur teuer im Verhältnis zur Nutzung – denn eine Plattform für Flohmärkte hat ein bemerkenswertes Lastprofil: monatelang praktisch null Zugriffe, dann an einem Samstag 50 bis 200 gleichzeitige Nutzer, die alle gleichzeitig Geld bewegen.

Für genau dieses Profil ist ein durchlaufender Server die schlechteste denkbare Betriebsform. Man bezahlt elf Monate Stillstand, um an zwölf Samstagen im Jahr nicht zusammenzubrechen.

Die Zahlen

Der Monat ist die Zahl, die am häufigsten Nachfragen auslöst. Zur Einordnung: Das ist nicht die Zeit für „ein Formular nachbauen“, sondern für den vollständigen Umbau eines Systems, das echtes Geld bewegt – inklusive Datenübernahme aus dem Altsystem, Sicherheitsprüfung, Testabdeckung und Inbetriebnahme.

Was tatsächlich gemacht wurde

Schritt 1: Die Fachlichkeit rekonstruieren, nicht den Code übersetzen

Der häufigste Fehler bei Migrationen ist, den alten Code Zeile für Zeile in eine neue Sprache zu übertragen. Dabei wandern alle Altlasten mit, nur teurer.

Der erste Schritt war deshalb, aus dem Bestand die Regeln herauszuziehen: Wie wird eine Provision berechnet? Was passiert bei einer Stornierung nach dem Check-out? Wie hängen Listen zusammen, wenn eine Familie mehrere führt? Das ist die Arbeit, bei der ein KI-Agent enorm hilft – er liest 40.000 Zeilen fremden Code schneller und ermüdungsfreier als jeder Mensch und beantwortet Fragen dazu.

Entschieden hat trotzdem der Mensch. Denn der Code sagt nur, was passiert – nicht, was passieren sollte. An mehreren Stellen war das Verhalten des Altsystems schlicht ein Fehler, den seit Jahren niemand bemerkt hatte.

Schritt 2: Zielbild und Leitplanken – vor der ersten Zeile

Bevor irgendetwas gebaut wurde, standen die Regeln fest, an die sich jeder Beitrag halten muss – ob von Mensch oder Maschine:

• Feste Bauform: jede Funktion nach demselben Muster, keine kreativen Sonderwege.
• Tests sind Pflicht, nicht Kür – inklusive Tests, die die Anwendung wie ein echter Nutzer bedienen.
• Ein Qualitätstor, das jede Änderung automatisch prüft: keine offenen Befunde, Mindestabdeckung durch Tests, keine Doppelungen.
• Ein Sicherheitsscan als Sperre vor dem Zusammenführen – Abhängigkeiten, Infrastrukturkonfiguration, versehentlich eingecheckte Zugangsdaten.
• Geld immer als ganzzahlige Cent, niemals als Kommazahl. Klingt banal, ist der klassische Weg zu Rundungsfehlern, die erst in der Auszahlung auffallen.

Schritt 3: Bauen, in kleinen prüfbaren Paketen

Danach lief die eigentliche Umsetzung agentengestützt: erkunden, bauen, prüfen. Erkundung parallel – mehrere Agenten lesen gleichzeitig verschiedene Bereiche und berichten, was es gibt. Umsetzung bewusst seriell und von Hand geführt, weil parallel arbeitende Agenten sich regelmäßig in denselben Dateien in die Quere kommen und die Aufräumarbeit teurer ist als der gesparte Durchlauf.

Der Anfang ist teuer. Danach wird es schnell billiger.

Das ist die Beobachtung, die für eine Aufwandsschätzung am wichtigsten ist – und die in den meisten Berichten über KI-gestützte Entwicklung fehlt, weil sie die schöne Erzählung stört: Der Aufwand verläuft nicht gleichmäßig. Er fällt.

In den ersten Tagen musste jemand danebensitzen

Solange die Projektstruktur erst entsteht, gibt es nichts, woran sich ein Agent orientieren könnte. Er trifft dann Entscheidungen, die für sich genommen vernünftig sind und trotzdem nicht zusammenpassen: dieselbe Aufgabe im einen Bereich so gelöst, im nächsten anders. Beides funktioniert. Zusammen ergibt es ein System, das niemand mehr überblickt.

In dieser Phase ist ein erfahrener Entwickler nicht optional. Er entscheidet nicht, ob etwas funktioniert – das tut der Test –, sondern welche von drei funktionierenden Varianten die Hausform wird. Diese Entscheidungen fallen früh, sie sind schwer umkehrbar, und sie sind genau die Sorte Frage, die eine Maschine plausibel, aber beliebig beantwortet.

Was einmal schiefging, wurde aufgeschrieben

Der zweite Grund für die fallende Kurve: Jeder Fehler wurde festgehalten, sobald er verstanden war – nicht in einem Protokoll, das niemand liest, sondern in den Regeldateien, die der Agent bei jeder Aufgabe erneut vorgelegt bekommt.

Zwei echte Beispiele aus diesem Projekt:

• Die Datenbank lehnte die Anmeldung ab, scheinbar wegen fehlender Rechte. Die Ursache war eine vorgehende Uhr in der Entwicklungsumgebung. Das kostete einen halben Tag Suche – einmal. Seitdem steht es in den Regeln, und die Fehlermeldung wird beim nächsten Auftreten in Sekunden richtig gedeutet.
• Ein Testlauf prüfte hartnäckig eine veraltete Programmfassung, weil im Hintergrund noch ein alter Entwicklungsserver lief. Auch das: eine verlorene Sitzung, danach eine feste Regel vor jedem Testlauf.

Das klingt banal und ist der eigentliche Unterschied zu einem menschlichen Team, in dem solches Wissen an Personen hängt und mit ihnen geht. Hier steht es in einer Datei, gilt ab sofort für jeden Beitrag und lässt sich nicht vergessen.

Je mehr steht, desto weniger Führung braucht es

Nach den ersten Wochen kippt das Verhältnis. Sobald es für jede Art von Aufgabe ein Beispiel im Projekt gibt, lautet der Auftrag nicht mehr „bau eine Auswertung, hier sind die Randbedingungen", sondern schlicht „bau die Auswertung wie die bestehende."

Ein Agent, der sich an vorhandenem Code orientieren kann, liefert deutlich zuverlässiger als einer, der eine Struktur erfinden muss – und muss dabei kaum noch korrigiert werden. Aus enger Begleitung wird stichprobenartige Abnahme.

Was schiefging – und was es aufgefangen hat

Das ist der Teil, der in Referenzberichten üblicherweise fehlt, und der einzige, aus dem man etwas lernen kann.

Die Hälfte der „neuen“ Funktionen war schon da

In zwei aufeinanderfolgenden Arbeitspaketen stellte sich jeweils heraus: Etwa die Hälfte dessen, was gerade neu gebaut werden sollte, existierte bereits – und war nur nicht angeschlossen. Eine Funktion, die niemand aufrief. Ein Parameter, den es seit Wochen gab. Ein Feld, das längst mitgeliefert wurde.

Die Lehre ist unspektakulär und teuer erkauft: Erst fragen „gibt es das schon?“, dann bauen. Das ist der größte Einzelhebel überhaupt – größer als jede Beschleunigung durch mehr Rechenleistung.

Fehler, die eine Maschine strukturell nicht sieht

Zwei Beispiele aus der Praxis, beide erst durch Tests gefunden, die die Anwendung wie ein echter Nutzer bedienen:

• Ein Bildschirm lud seine Daten, bevor die Anwendung überhaupt wusste, welche Veranstaltung gerade ausgewählt ist. In jedem Einzeltest korrekt, im echten Ablauf leer.
• Ein Eingabefeld lieferte dem Programm eine Zahl, wo es eine Zeichenkette erwartete – weil der Browser das bei Zahlenfeldern so macht. Ein Test, der den Wert direkt setzt, kann diesen Fehler prinzipiell nicht finden. Nur ein Test, der wirklich tippt.

Beides sind keine Fehler mangelnder Sorgfalt, sondern Fehler an einer Nahtstelle, die man nur im Zusammenspiel sieht. Ein KI-Agent findet sie nicht, weil er den Einzelbaustein korrekt baut. Ein Mensch übersieht sie aus demselben Grund.

Die Summe reißt Grenzen, die einzeln nie gerissen worden wären

Zweimal hintereinander lief das automatische Qualitätstor im ersten Anlauf auf Rot – beide Male an Schwellen, die kein einzelner Beitrag überschritten hätte: eine Funktion, die durch vier kleine Ergänzungen zu lang geworden war; eine Bedingung, die durch die Summe der Änderungen zu verschachtelt war.

Die Reparatur dauerte jeweils Minuten. Ohne das automatische Tor wäre keiner dieser Punkte aufgefallen – und in achtzehn Monaten hätte niemand mehr sagen können, wann genau das System unübersichtlich geworden ist.

Was das Ergebnis leistet

Die neue Architektur läuft ohne durchlaufenden Server und ohne durchlaufende Datenbank. Beides entsteht bei der Anfrage und verschwindet danach – daher die unter 5 € im ruhigen Monat.

Der interessanteste Teil ist der Kassenbetrieb: Er funktioniert vollständig ohne Internet. In Turnhallen und Gemeindesälen ist das Netz regelmäßig schlecht oder gar nicht vorhanden, und ein Kassensystem, das dann stehenbleibt, ist wertlos. Die Kasse arbeitet lokal weiter, schreibt jeden Vorgang mit und gleicht ab, sobald wieder Verbindung besteht.

Die drei Voraussetzungen – ohne die es nicht funktioniert

1. Ein prüfbares Zielbild. Wer nicht sagen kann, woran er erkennt, dass etwas richtig ist, kann es auch nicht abnehmen – weder von einem Dienstleister noch von einer Maschine.
2. Automatisierte Tests und ein Qualitätstor. Bei KI-gestützter Entwicklung verschiebt sich der Engpass vom Schreiben zum Prüfen. Wer nur die Erzeugung beschleunigt, hat den Engpass nicht beseitigt, sondern verlagert.
3. Jemand, der die Fachlichkeit wirklich kennt. Die Maschine kann den Code lesen. Sie kann nicht wissen, dass die Provision bei Vereinsveranstaltungen anders gerechnet wird, weil das 2019 mündlich so vereinbart wurde.