Ecolab schrumpft Legacy-SQL um den Faktor sechs mit Datafolds KI-Migrationsagent und dbt
Ecolab verzeichnet nach der Migration seiner Legacy-SQL-Logik nach dbt mit einem KI-Migrationsagenten von Datafold rund sechsmal weniger Code und viermal weniger Datenverbindungen. Das geht aus einer Fallstudie von dbt Labs hervor. Vorgestellt wurde das Projekt auf dem dbt Summit 2026 von Ecolab-Tech-Lead Tomasz Kaczmarek und einem Datafold-Ingenieur.
- Ecolab meldet nach der Migration von Legacy-SQL nach dbt rund sechsmal weniger Code und viermal weniger Datenverbindungen.
- Datafolds Agent übersetzte die Logik in mehr als 40 dbt-Projekte und prüft jedes Modell per automatisiertem Data Diffing.
- Bei einer zentralen Dimension sank die Zahl der Modelle von 409 auf 170, rund 70.000 Codezeilen entfielen.
- Rund 90 Tabellen wurden in den ersten vier Wochen der Prüfung freigegeben.
- Der Cutover auf die neuen Modelle ist nicht Teil dieser Phase und folgt nach vollständiger Prüfung.
Ein Basismodell, das zu komplex wurde
Ecolab stellt Produkte für Hygiene, Lebensmittelsicherheit und Wasseraufbereitung her, die weltweit in Hotels, Restaurants, Krankenhäusern und Industriebetrieben zum Einsatz kommen. Das zentrale Datenmodell, das "Base Model", umfasst mehr als 400 voneinander abhängige Dimensionen und Fakten und wird aus mehr als 3.000 Quellsystemen gespeist. Es ist über Jahre hinweg Projekt für Projekt gewachsen. Laut der Fallstudie wurde es so komplex, dass Ecolab eigens eine "Firefighter"-Rolle schuf, die sich um Produktionsprobleme kümmert.
Das Altsystem legte Stage-Tabellen, Temp-Tabellen, Key-Mapping-Tabellen und Snowflake Streams über das Kernmodell, um verspätet eintreffende Daten und Surrogatschlüssel zu bewältigen. Orchestriert wurde das alles von Snowflake Tasks, die JavaScript-Stored-Procedures aufriefen. Da das System nur neue oder geänderte Zeilen neu verarbeitete, liefen ältere Datensätze unbemerkt auseinander. Daraus entstanden Datenqualitätsprobleme, die niemand vollständig erfasst hatte.
Ecolab wollte stattdessen transparente, gut dokumentierte und versionierte Transformationslogik, anstatt sie in einer Snowflake-Tabelle zu vergraben. Dazu gehörte auch der Wechsel von zweiwöchentlichen manuellen Releases zu automatischen Ad-hoc-Releases sowie der Verzicht auf lange Code-Freezes.
So arbeitet der Migrationsagent
Datafolds Agent kartiert zunächst die gesamte Lineage, die Codebasis und die Semantic Layer. Anschließend zieht er institutionelles Wissen aus Wikis und Meeting-Aufzeichnungen heran, um Kontext zu ergänzen, der nie schriftlich festgehalten wurde. Die Legacy-Logik wird in mehr als 40 getrennte dbt-Projekte mit klaren Zuständigkeiten übersetzt, wobei dbt Mesh die projektübergreifenden Teile übernimmt.
Jedes übersetzte Modell wird per automatisiertem Data Diffing gegen Produktionsdaten geprüft. Der Agent muss erwartete Abweichungen anhand des Legacy-Codes, des neuen Codes und der ursprünglichen Anforderungen begründen. Alles Ungeklärte läuft so lange durch den Agenten zurück, bis es aufgelöst ist.
Die bisherigen Ergebnisse:
- Bei einer zentralen Dimension sank die Zahl der Modelle von 409 auf 170, dabei entfielen rund 70.000 Codezeilen und 1.000 Datenverbindungen.
- Über die gesamte Migration hinweg verzeichnet Ecolab rund sechsmal weniger Code und viermal weniger Datenverbindungen als im Altsystem.
- Der neue Prozess wirkt bereits SOC-2-tauglich, dank Git-basierter Versionskontrolle sowie automatisierter Tests und Deployments, obwohl Compliance ursprünglich nicht das Ziel war.
Datenverantwortliche überzeugen und Lehren aus dem Projekt
Die Datenverantwortlichen waren zunächst skeptisch. Jede Abweichung von den Zahlen des Altsystems legte nahe, dass die neue Pipeline falsch sei, und sie fürchteten, ihre eigenen Nutzer könnten von "schlechten Daten" ausgehen. Als man ihnen statt einer schriftlichen Erklärung einen visuellen Data Diff auf Zeilenebene zeigte, schlug die Stimmung schnell um: Innerhalb der ersten vier Wochen der Prüfung wurden rund 90 Tabellen freigegeben.
Das Team teilte mehrere Erkenntnisse. Migrationen laufen eher agil als nach dem Wasserfallprinzip ab, weil das erste lauffähige dbt-Projekt sofort neue Wünsche zu Benennung und Struktur nach sich zieht. Kleine kosmetische Änderungen wie das Umbenennen einer Spalte sind für einen Agenten teuer, da jede mehrere Modellaufrufe verbrauchen kann. Deshalb lohnt es sich, sie zu bündeln, bis die Daten als korrekt verifiziert sind.
Kaczmarek sagte, er selbst sei anfangs ein Flaschenhals gewesen, weil er aus dem, was er "Vertrauensprobleme" nannte, alles von Hand prüfte. Er lerne noch, dem Prozess mehr dieser Last zu überlassen.
Wie es weitergeht
Der Cutover ist nicht Teil dieser Phase. Ecolab will die zugrunde liegenden Tabellen hinter seiner bestehenden Reporting-Schicht erst umschalten, wenn jede Dimension und jeder Fakt geprüft und freigegeben ist. Die Zahlen stammen von Ecolab selbst und wurden von dbt Labs berichtet; die endgültige Umstellung in der Produktion steht noch aus.
Für Teams mit großen, schlecht dokumentierten SQL-Landschaften beschreibt der Fall einen Ansatz, der automatisierte Übersetzung mit Verifikation auf Zeilenebene und menschlicher Prüfung kombiniert und den Prozess als iterativ statt als einmalige Konvertierung versteht.
