Korrekt — und vollständig unbrauchbar
Wir starteten den Go-live an einem Sonntagabend im März, elf Monate nach Unterzeichnung des Business Case. Alle Zahlen stimmten überein — diesen Kampf mit den Daten hatten wir Monate zuvor bereits ausgefochten und gewonnen. Jede technische Rückstellung, jede Schadenreserve, jeder Policensaldo entsprach der Legacy-Plattform bis auf den Rappen.
Am Dienstagmorgen hatte unser Callcenter eine Warteschlange von vierhundert Personen, weil die Abfrage eines einzelnen Schadensfalls achtundvierzig Sekunden dauerte. Am Donnerstag war unser Nachtbatch — Policenverlängerungen, Rückversicherungs-Zession, der Regulatorik-Extrakt, den unser Compliance-Team monatlich einreicht — drei Nächte in Folge um 6 Uhr morgens noch nicht abgeschlossen. Am Freitag war unsere Head of Compliance fünf Stunden davon entfernt, der FINMA erklären zu müssen, warum eine planmässige Einreichung zu spät eintreffen würde, weil ein Batch-Job, der normalerweise neunzig Minuten brauchte, nach neun Stunden noch immer lief.
Wir hatten nichts kaputt gemacht. Wir hatten ein technisch korrektes System gebaut, das für alle praktischen Zwecke unbrauchbar war.
Vierzig Jahre Tuning, das man nie sieht
Das ist der Teil, den niemand in den Business Case geschrieben hatte. Unser AS/400 hatte gut vierzig Jahre lang dieselbe Kern-Policen- und Schadenplattform betrieben. In dieser Zeit hatte er etwas angesammelt, das kein Datenmigrationsprojekt je einrechnet: vierzig Jahre Index-Tuning.
Jeder Zugriffspfad auf diesem System — welche Felder zu indexieren sind, welche zusammengesetzten Schlüssel zählten, wann ein Full Table Scan einem Index-Lookup vorzuziehen war, welcher Encoded Vector Index für welchen Reporting-Job aufzubauen war — war empirisch entschieden worden, einen Produktionsvorfall nach dem anderen, von Menschen, die grösstenteils nicht mehr im Unternehmen waren. Nichts davon existierte in einem Designdokument. Alles davon lebte im DB2-Katalog, in Zugriffspfad-Statistiken, die niemand exportiert hatte, und im Erfahrungsgedächtnis zweier Datenbankadministratoren, die längst in die Beratung gewechselt waren.
Wir hatten vierzig Jahre Daten migriert. Wir hatten nicht vierzig Jahre Wissen darüber migriert, wie man sie schnell liest.
Was wir zuerst versuchten
Wir taten das Offensichtliche: Wir dimensionierten die Zielinfrastruktur so, wie jeder Lieferanten-Kalkulator es verlangt — nach Datenvolumen. Terabytes rein, Compute und Storage raus. Das ist eine vernünftige Methode für ein System ohne Geschichte. Es ist die falsche Methode für eines mit vierzig Jahren davon.
Wir überprovisionierten Compute auf rund das Dreifache des tatsächlichen Bedarfs, in der Annahme, dass rohe Rechenleistung das fehlende Indexing kompensieren würde. Es reichte noch immer nicht für die Abfragen, die wirklich zählten — denn keine Menge Compute korrigiert einen Full Table Scan über zweihundert Millionen Zeilen. Wir gaben sechsstellige Beträge für Infrastruktur aus, die wir nicht brauchten, und konnten noch immer nicht mit Sicherheit sagen, ob wir für die tatsächlich relevanten Abfragen richtig dimensioniert hatten.
Einführung eines KI-Managed-Service
Was die Wende brachte, war die Rückholung desselben KI-Managed-Service, der unsere Daten abgestimmt hatte — diesmal für einen zweiten Durchlauf, der auf das Laufzeitverhalten des AS/400 gerichtet war, nicht nur auf seine Stored Procedures. Er extrahierte Zugriffspfad-Statistiken, Query-Optimizer-Logs und Jahre von RUNSTATS-Historie von der Legacy-Plattform und rekonstruierte etwas, das wir in keinem Dokument je besessen hatten: eine empirische Karte genau jener Zugriffspfade, die echtes Produktionsgewicht trugen — für welche Abfragen, bei welchen Volumen, und wie das sich über vier Jahrzehnte mit dem Wachstum unseres Bestands verschoben hatte.
Ein Performance-Bild, das ich endlich vertreten konnte
Diese Karte liess uns beim zweiten Anlauf korrekt dimensionieren. Keine verkleidete Schätzung als Sizing-Tabelle — eine tatsächliche, belegte Antwort auf die Frage: «Was braucht dieses System, um für die tatsächliche Last schnell zu sein?», gebaut aus vierzig Jahren realer Zugriffsmuster statt einer Faustformel des Lieferanten.
Wir bauten die Indexierungsstrategie der Zielplattform um rund 340 Zugriffspfade neu, die die Daten als tatsächlich relevant auswiesen — von mehreren tausend nominellen Indizes, die sich über vier Jahrzehnte angesammelt hatten. Die mediane Schadenabfrage sank von achtundvierzig Sekunden auf unter zweihundert Millisekunden. Der Nachtbatch, der sich auf über neun Stunden ausgedehnt hatte, kam auf rund neunzig Minuten zurück — genau dort, wo er auf dem AS/400 gewesen war.
Daten, die ich endlich befragen konnte
Der zweite Nutzen überraschte mich wiederum. Ein System, das man nicht in unter einer Minute abfragen kann, ist eines, gegen das niemand Ad-hoc-Analysen fährt — also hatten unsere Schaden- und Pricing-Teams in den drei Jahren still aufgehört, Fragen zu stellen, die sie früher wöchentlich gestellt hatten. Betrugsmuster-Clustering. Verlängerungsverhalten nach Segment. Loss Ratios nach Vertriebskanal, tagaktuell statt zum Quartalsende.
Sobald der KI-Managed-Service sowohl die Logik als auch das Performance-Profil in der Hand hatte, wurden diese Daten von technisch vorhanden zu tatsächlich nutzbar — in natürlicher Sprache abfragbar, schnell genug zum Erkunden statt zum Planen. Wir fanden zwei Schaden-Segmente, die achtzehn Monate still mit Loss Ratios weit ausserhalb des Risikoappetits liefen — unsichtbar nicht weil niemand schaute, sondern weil das Schauen lange genug dauerte, dass niemand damit weitermachte.
Warum wir endlich neu bauen konnten
Das ist der Teil, der die Migration tatsächlich zum Funktionieren brachte. Sobald der KI-Managed-Service hinter dem Legacy-Bestand stand — nicht nur die Daten abstimmend, sondern das tiefe Archiv unter einem SLA bereitstellend, der garantierte, dass es verfügbar und schnell genug zur Abfrage blieb, wenn jemand vierzigjährige Historie brauchen sollte — hörten wir auf, vier Jahrzehnte Daten zu migrieren und neu zu tunen, die wir grösstenteils nie anfassen.
Wir dimensionierten und indexierten die Zielplattform für den tatsächlich aktiven Bestand: laufende Policen, offene Schäden, das Aufbewahrungsfenster, das Regulatoren und Betrieb wirklich mit Geschwindigkeit benötigen. Alles Ältere liegt beim KI-Managed-Service — abgestimmt, auf seine eigenen Bedingungen indexiert, in Sekunden antwortfähig, wenn jemand fragt. Mein Infrastrukturteam hat für das System entworfen, das wir heute tatsächlich betreiben, nicht für ein systemförmiges Abbild von allem, was jemals auf dem AS/400 passiert ist.
Wir hatten kein langsames System geerbt. Wir hatten ein System geerbt, das keine Erinnerung mehr daran hatte, wie es einmal schnell gewesen war. Ich habe diese Plattform zweimal freigegeben — einmal für Korrektheit, einmal für Geschwindigkeit. Die zweite Freigabe ist die, die für die vierhundert Personen in der Warteschlange tatsächlich zählte. Sie lehrte mich: Eine Migration ist nicht abgeschlossen, wenn die Zahlen stimmen. Sie ist abgeschlossen, wenn niemand mehr merkt, dass sie stattgefunden hat.