Korrekt und vollständig unbrauchbar
Wir gingen in einer Märznacht um 23 Uhr live, elf Monate nach Unterzeichnung des Business Case. Jede Zahl stimmte — diesen Kampf mit den Daten hatten wir Monate zuvor bereits geführt und gewonnen. Jede versicherungstechnische Rückstellung, jede Schadenreserve, jeder Policensaldo entsprach auf den Rappen genau der Legacy-Plattform.
Am Dienstagmorgen hatte unser Call Center eine Warteschlange von vierhundert Personen, weil eine einzelne Schadenabfrage achtundvierzig Sekunden dauerte. Am Donnerstag lief unser nächtlicher Batch — Verlängerungen, Rückversicherungszession, der monatliche Regulierungsauszug unseres Compliance-Teams — seit drei Nächten nicht bis 6 Uhr morgens durch. Am Freitag war unsere Compliance-Leiterin fünf Stunden davon entfernt, der FINMA erklären zu müssen, warum eine termingerechte Meldung verspätet wäre, weil ein Batch-Job, der sonst neunzig Minuten dauerte, nach neun Stunden noch nicht fertig war.
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
Hier ist der Teil, den niemand in den Business Case geschrieben hat. Unser AS/400 lief seit gut vierzig Jahren mit derselben Kern-Policen- und Schadenplattform. In dieser Zeit hatte er etwas angesammelt, das kein Datenmigrationsprojekt je berücksichtigt: vierzig Jahre Index-Tuning.
Jeder Zugriffspfad auf diesem System — welche Felder zu indizieren waren, welche zusammengesetzten Schlüssel wichtig waren, wann ein Full Table Scan einem Index-Lookup vorzuziehen war, welcher Encoded Vector Index für welchen Reporting-Job erstellt werden musste — war empirisch entschieden worden, einen Produktionsvorfall nach dem anderen, von Personen, die grösstenteils nicht mehr im Unternehmen waren. Nichts davon stand in einem Designdokument. Alles davon lebte im DB2-Katalog, in Zugriffspfad-Statistiken, die niemand exportiert hatte, und im Muskelgedächtnis zweier DBAs, die längst in die Beratung gewechselt waren.
Wir hatten vierzig Jahre Daten migriert. Wir hatten nicht migriert, wie man sie schnell liest.
Was wir zuerst versuchten
Wir taten das Naheliegende: Wir dimensionierten die Zielinfrastruktur so, wie es jeder Anbieter-Kalkulator vorschlägt — 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 überausstatteten die Compute-Kapazität auf ungefähr das Dreifache des tatsächlich benötigten Workloads, in der Annahme, dass rohe Rechenleistung fehlende Indizierung ausgleichen würde. Für die wichtigsten Abfragen reichte es dennoch nicht, denn keine Rechenleistung behebt einen Full Table Scan über zweihundert Millionen Zeilen. Wir gaben sechsstellige Beträge für Infrastruktur aus, die wir nicht brauchten, und konnten trotzdem nicht mit Sicherheit sagen, ob wir für die Abfragen, die wirklich zählten, 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 auf das Laufzeitverhalten des AS/400 gerichtet, nicht nur auf seine gespeicherten Prozeduren. Er zog Zugriffspfad-Statistiken, Query-Optimizer-Protokolle und jahrelange RUNSTATS-Historie von der Legacy-Plattform und rekonstruierte etwas, das wir in keinem Dokument je gehabt hatten: eine empirische Karte genau jener Zugriffspfade, die echtes Produktionsgewicht trugen — für welche Abfragen, bei welchen Volumina, und wie sich das über vier Jahrzehnte mit unserem Bestandswachstum verschoben hatte.
Ein Performance-Bild, das ich endlich vertreten konnte
Diese Karte ermöglichte uns, beim zweiten Mal korrekt zu dimensionieren. Keine als Sizing-Tabelle verkleidete Schätzung — eine tatsächliche, belegte Antwort auf die Frage: „Was braucht dieses System, um für die Arbeitslast, die es tatsächlich trägt, schnell zu sein?" — aufgebaut auf vierzig Jahren realer Zugriffsmuster statt einer Faustformel des Anbieters.
Wir bauten die Indizierungsstrategie der Zielplattform um rund 340 Zugriffspfade auf, die die Daten als wirklich relevant ausgewiesen hatten — von mehreren Tausend nominellen Indizes, die sich über vier Jahrzehnte angesammelt hatten. Die mediane Schadenabfrage sank von achtundvierzig Sekunden auf unter zweihundert Millisekunden. Der Nacht-Batch, der auf über neun Stunden angewachsen war, 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 erneut. Ein System, das zu langsam ist, um in unter einer Minute abgefragt zu werden, ist eines, gegen das niemand Ad-hoc-Analysen fährt — so hatten unsere Schaden- und Pricing-Teams in drei Jahren stillschweigend aufgehört, Fragen zu stellen, die sie früher wöchentlich gestellt hatten. Betrugsmuster-Clustering. Verlängerungsverhalten nach Segment. Schadenkostenquoten nach Kanal, tagesaktuell statt quartalsendig.
Sobald der KI-Managed-Service sowohl die Logik als auch das Performance-Profil in der Hand hatte, gingen diese Daten von technisch vorhanden zu tatsächlich nutzbar über — in einfacher Sprache abfragbar, schnell genug zum Explorieren statt zum Einplanen. Wir fanden zwei Schadenbearbeitungssegmente, die seit achtzehn Monaten stillschweigend mit weit ausserhalb des Risikoappetits liegenden Schadenkostenquoten liefen — nicht unsichtbar, weil niemand hinsah, sondern weil das Hinsehen lang genug dauerte, dass niemand damit weitermachte.
Warum wir endlich auf der grünen Wiese bauen konnten
Das ist der Teil, der die Migration tatsächlich zum Funktionieren brachte. Sobald der KI-Managed-Service hinter der Legacy-Landschaft stand — nicht nur die Daten abstimmend, sondern das Tiefarchiv unter einer SLA bereitstellend, die garantierte, dass es verfügbar und schnell genug abfragbar bleibt, wenn jemand vierzig Jahre alte Geschichte benötigt — hörten wir auf zu versuchen, vier Jahrzehnte grösstenteils ungenutzter Daten zu migrieren und neu zu tunen.
Wir dimensionierten und indizierten die Zielplattform für das tatsächlich aktive Geschäftsbuch: laufende Policen, offene Schäden, das Haltezeitfenster, das unsere Regulatoren und unser eigener Betrieb wirklich mit Geschwindigkeit benötigen. Alles Ältere verbleibt beim KI-Managed-Service — abgestimmt, nach eigenen Massstäben indiziert, in Sekunden beantwortbar, wenn jemand fragt. Mein Infrastruktur-Team hat für das System geplant, das wir heute tatsächlich betreiben — nicht als systemförmiges Abbild von allem, was je auf dem AS/400 passiert ist.
Wir hatten kein langsames System geerbt. Wir hatten ein System ohne Erinnerung daran geerbt, wie es früher schnell war. Ich habe diese Plattform zweimal genehmigt — einmal für Korrektheit, einmal für Geschwindigkeit. Die zweite Genehmigung war die, die den vierhundert Personen in der Warteschlange tatsächlich etwas bedeutete. Sie lehrte mich: Eine Migration ist nicht beendet, wenn die Zahlen stimmen. Sie ist beendet, wenn niemand bemerkt, dass sie stattgefunden hat.