Im Grundlagenartikel „Databricks Migration einfach erklärt“ haben wir unseren KI-gestützten Migrationsansatz bewusst nur angerissen. Dieser Artikel liefert den technischen Deep-Dive: Wie arbeiten Migrate Agent und Deploy Agent zusammen, was bedeutet Harness Engineering konkret, und wie stellt automatisiertes Testing sicher, dass am Ende kein technisch funktionierender, aber fachlich falscher Code entsteht?
Warum reine Transpiler-Tools an ihre Grenzen stoßen
Databricks selbst investiert massiv in automatisierte Migrationswerkzeuge. Das eigene, kostenlose Tool Lakebridge soll laut Databricks bis zu 80 Prozent der Migrationsaufgaben automatisieren und die Umsetzungsgeschwindigkeit verdoppeln können (Databricks, Juni 2025). Das zeigt: Automatisierte Migration ist kein Nischenthema mehr, sondern ein Markt, in den der Plattformanbieter selbst erheblich investiert.
In unseren Projekten sehen wir allerdings, dass reine Transpiler-Ausgaben zwar funktionieren, aber selten produktionsreif sind: alte Namenskonventionen bleiben erhalten, moderne Databricks-Fähigkeiten wie Streaming werden nicht genutzt, und der erzeugte Code ist kaum wartbar. Genau hier setzt unser Ansatz an. Er kombiniert die reine Code-Übersetzung mit Unternehmenskontext, sogenanntem Harness Engineering, damit am Ende kein technisch funktionierender, aber fachlich unbrauchbarer Code entsteht.
Expertentipp von Laurenz, CTO bei Datasolut:
Verlassen Sie sich nicht auf ein einzelnes Migrationstool als Gesamtlösung. In unseren Projekten liefert der reine Transpiler-Output selten mehr als eine Rohübersetzung. Der eigentliche Wert entsteht erst, wenn ein Agent diese Rohübersetzung mit Ihren Namenskonventionen, Ihren Datenmustern und Ihren Datenschutzregeln anreichert.
Vom Hybrid-Ansatz zur technischen Umsetzung: Lift & Modernize
Im Grundlagenartikel haben wir die drei Migrationsansätze Lift & Shift, Neuentwicklung und Hybrid-Ansatz vorgestellt. Unser KI-gestützter Migrationsansatz ist die technische Umsetzung dieses Hybrid-Ansatzes, wir nennen ihn intern Lift & Modernize: Business-Logik bleibt erhalten, technische Schulden werden reduziert, und der Einsatz von Custom-Agenten automatisiert einen Großteil der Modernisierung auf moderne Databricks-Features wie Spark Declarative Pipelines und Hash-IDs.
Der Preis für Lift & Modernize ist ein etwas höherer initialer Setup-Aufwand gegenüber reinem Lift & Shift, der sich mit wachsender Zahl migrierter Mappings jedoch schnell amortisiert, weil sich einmal erfasster Kontext und einmal trainierte Muster über alle weiteren Mappings hinweg wiederverwenden lassen.
Die vier Bausteine unseres Migrationsansatzes
Ein funktionierendes Agentic-Migration-Setup besteht aus mehr als einem einzelnen Prompt. Unser Ansatz setzt auf vier Bausteine, zusammengefasst als Tools, MCP und Skills:
- Unternehmensinformationen: Namenskonventionen, bekannte Datenmuster, Datenschutzregeln und Dokumentation aus dem Altsystem.
- Custom-Agenten: Der Migrate Agent für Planung und Code-Migration sowie der Deploy Agent für automatisierten Datenabgleich.
- Databricks Agent Skills: Wiederverwendbare, strukturierte Fähigkeiten, mit denen sich unternehmensspezifisches Wissen konsistent in den Agenten-Workflow einbinden lässt (mehr zu Databricks Agent Skills).
- MCP-Server: Standardisierte Schnittstellen, über die die Agenten kontrolliert auf Quellsysteme, Metadaten und Zielumgebung zugreifen.
Der Workflow in fünf Schritten
Diese vier Bausteine greifen in einem Workflow aus fünf Schritten ineinander:
- Artefakte: Quellcode (SQL, Python, XML-Konfigurationen), vorhandene Dokumentation und Metadaten aus dem Altsystem werden gesammelt.
- Intermediate Representation: Die Artefakte werden in eine technologieneutrale Zwischenrepräsentation überführt, unabhängig vom Zielformat.
- Harness Engineering: Die Zwischenrepräsentation wird mit Unternehmenskontext angereichert, also Namenskonventionen, bekannten Datenmustern und Datenschutzregeln.
- Generierung: Der Agent generiert daraus lauffähigen Databricks-Code, etwa als Spark Declarative Pipeline.
- Validierung: Das Ergebnis wird automatisiert gegen die Quelldaten geprüft. Bei Abweichungen springt der Workflow zurück zur Generierung, bis die Qualitätskriterien erfüllt sind.
Diese fünf Schritte verteilen sich auf zwei spezialisierte Agenten, die jeweils einen klar abgegrenzten Teil der Migration übernehmen.
Migrate Agent: Planung vor Umsetzung
Der Migrate Agent arbeitet zweistufig. In der Planungsphase überführt er Quellcode und Metadaten in die gemeinsame Zwischenrepräsentation und wendet dabei vordefinierte Muster an, etwa ein Pattern für Fälle, in denen mehrere Quelltabellen gemeinsam eine Zieltabelle speisen und ihre Änderungen konsolidiert werden müssen. Am Ende der Planungsphase steht ein Report mit grafisch dargestellten Abhängigkeiten sowie ein Fragenkatalog für offene Punkte, die ein Mensch klären muss, bevor die Umsetzung startet.
So sieht das in der Praxis aus: Der Prompt ist denkbar einfach, etwa „Bitte migriere mir meine SQL-Prozedur aus dem Legacy-Ordner.“ Der Migrate Agent antwortet nicht sofort mit Code, sondern mit einem Planungsreport und gezielten Rückfragen, etwa zur Bestätigung des Ziel-Catalogs, zum Schema für den Raw Layer, zur Historisierungslogik einer Dimensionstabelle oder zur Frage, ob nach der Code-Generierung direkt deployt werden soll. Erst wenn diese Punkte beantwortet sind, beginnt die Ausführungsphase.
Machen Sie Databricks zu Ihrem Wettbewerbsvorteil
Mit unserer Databricks-Beratung entwickeln Sie eine skalierbare Architektur, realisieren produktive Use Cases und befähigen Ihr Team nachhaltig.
Der Agent folgt dabei einem Test-Driven-Development-Ansatz: Er schreibt zuerst Tests mit Beispieldaten und erst danach die eigentliche Transformationslogik. Das Ergebnis sind deploybare Spark Declarative Pipelines mit korrekten Tabellenreferenzen und vollständig konfigurierten Deployment-Dateien.
Deploy Agent: Automatisierte Qualitätssicherung
Sobald der Code steht, übernimmt der Deploy Agent das Deployment in einen Entwicklungs-Workspace und Sandbox-Catalog. Er führt den Code aus, prüft das Ergebnis über Quality Tests gegen Vergleichstabellen und festgelegte Regeln und schlägt bei Abweichungen automatisiert Code-Änderungen vor, bevor er erneut deployt. Offene Rückfragen betreffen dabei typischerweise das Was, das Wohin und die konkreten Target-Tabellen. Erst wenn der Datenabgleich im erwarteten Rahmen liegt, gilt ein Mapping als abgeschlossen.
Was das für Ihr Team bedeutet:
- Planung und Umsetzung sind bewusst getrennt, damit Fehlentscheidungen früh auffallen, statt erst nach fertigem Code.
- Test-Driven Development reduziert den Anteil der Fehler, die erst beim Deployment sichtbar werden.
- Der automatisierte Datenabgleich ersetzt manuelles Eyeballing von Tabellen, das in klassischen DWH-Projekten viel Zeit kostet.
Was der Ansatz in der Praxis bringt
Aus unserem bisherigen Migrationsprojekt ziehen wir vor allem eine Erkenntnis: Der größte Zeitgewinn entsteht nicht dadurch, dass die KI schneller tippt als ein Mensch, sondern dadurch, dass vormals passive Wartezeit produktiv wird. Während früher ein Entwickler auf ein Deployment warten musste, kann er heute parallel am nächsten Mapping arbeiten.
Metadatengetriebene Jobs mit wiederkehrenden Mustern profitieren davon am stärksten, hier lässt sich die Automatisierung nahezu vollständig ausschöpfen. Und: Je mehr Kontext das Team dem Migrate Agent zu Beginn mitgibt, desto weniger Rückfragen und Korrekturschleifen entstehen später im Prozess.
Human-in-the-Loop, also die gezielte menschliche Freigabe an den Schlüsselpunkten Planungsreport und Datenabgleich, erhöht dabei nachweislich die Qualität der migrierten Strecken, ohne den Geschwindigkeitsvorteil aufzuheben.
Warum Lakehouses die Daten-Architektur der Zukunft sind
In unserem Whitepaper erfahren Sie:
- Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
- Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
- Wie Sie ihr internes Team befähigen selbstständig KI Projekte zu implementieren.
Häufige Fehler beim Einsatz von KI-Agenten in der Migration
Fehler 1: Den Agenten in einem Schritt von Legacy zu Ziel springen lassen
Viele Teams versuchen zunächst, den kompletten Migrationssprung, von altem Mapping direkt zu fertigem Zielcode, in einem einzigen Agenten-Durchlauf zu erledigen. Das mag bei einfachen Fällen funktionieren, scheitert aber regelmäßig bei komplexeren Strecken, weil sich Fehler kaum zurückverfolgen lassen. Bauen Sie stattdessen überprüfbare Zwischenschritte mit eigenen Artefakten ein, wie im Fünf-Schritte-Workflow oben beschrieben.
Fehler 2: Zu wenig Unternehmenskontext mitgeben
Ein häufiger Denkfehler ist, dass ein leistungsfähiges Sprachmodell Legacy-Logik allein aus dem Code heraus versteht. Datenschutzspezifische Ausnahmen, historisch gewachsene Namenskonventionen oder informelle Datenregeln stehen selten im Code selbst. Ohne Harness Engineering produziert der Agent technisch funktionierenden, aber praktisch falschen Code.
Fehler 3: Den Proof of Concept am schwierigsten Modul ausrichten
Was in der Theorie wie ein guter Stresstest klingt, führt in der Praxis dazu, dass der Agent auf Komplexität optimiert und bei einfachen Strecken unnötig aufwendige Lösungen wählt. Ein repräsentativer Ausschnitt mit Überblick über die Gesamtmigration liefert belastbarere Ergebnisse.
Fehler 4: Teamvertrauen in den neuen Workflow unterschätzen
Was wir in der Praxis oft sehen: Technisch funktioniert das Agenten-Setup, aber das Team traut den Ergebnissen nicht und prüft weiterhin alles manuell nach. Das kostet einen Großteil des Geschwindigkeitsvorteils. Vertrauen entsteht durch nachvollziehbare Zwischenschritte, nicht durch Zusicherungen.
Fehler 5: Qualitätssicherung nicht mitskalieren
Sobald mehrere Mappings parallel migriert werden, wird die manuelle Abnahme zum Engpass, wenn die QS-Prozesse nicht ebenfalls automatisiert werden. Investieren Sie frühzeitig in automatisierten Datenabgleich, statt bei paralleler Migration auf manuellem Eyeballing zu bestehen.
Skalierung: Wann sich Parallelisierung lohnt
Sobald Planung und Implementierung zuverlässig laufen, lässt sich von einem Mapping pro Sprint auf mehrere parallel laufende Agenten-Instanzen wechseln. Zwei Dinge sollten Sie vorher klären: Erstens die API-Kosten der Parallelisierung gegen den Zeitgewinn kalkulieren. Zweitens prüfen, ob Ihr Team der Abnahmegeschwindigkeit der Parallelisierung überhaupt folgen kann, denn sonst verlagert sich der Engpass lediglich von der KI auf das Team.
Datasolut-Tipp: Ab welcher Anzahl parallel laufender Agenten-Instanzen wird die Abnahme durch das Kundenteam in Ihren Projekten typischerweise zum Engpass? Eine Faustregel oder Erfahrungswert aus der Praxis wäre hier sehr konkret und hilfreich.
Fazit
Ein guter Indikator dafür, dass ein Agenten-Workflow reif genug für den produktiven Einsatz ist: Er hört auf, sich wie ein Experiment anzufühlen. Unser KI-gestützter Migrationsansatz verschiebt den Engpass einer Legacy-Migration spürbar von der reinen Coding-Zeit zu Kontextaufbereitung, Vertrauen und Qualitätssicherung. Wer diese drei Faktoren ernst nimmt, kann die Projektlaufzeit gegenüber einer rein manuellen Migration erheblich verkürzen.
Mehr zu den grundsätzlichen Migrationsansätzen und typischen Szenarien lesen Sie im Grundlagenartikel „Databricks Migration einfach erklärt“. Wenn Sie klären möchten, ob dieser Ansatz zu Ihrer Legacy-Situation passt, sprechen wir gemeinsam in einem Erstgespräch darüber.
Ihr nächster Schritt mit uns!
Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.
Im kostenlosen Erstgespräch klären wir:
- Welche Rollen und Teams von welchem Paket am meisten profitieren
- Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
- Wie ein realistischer Zeitplan und die nächsten Schritte aussehen
Häufig gestellte Fragen zu unserem KI-Migrationsansatz
Harness Engineering bezeichnet das strukturierte Erfassen von Unternehmenskontext, Namenskonventionen, bekannten Datenmustern und Datenschutzregeln, bevor der Agent Code generiert. Der größte Hebel unseres Ansatzes liegt nicht in der reinen Code-Generierung, sondern darin, dass wir diesen Kontext vorab strukturiert erfassen. Je vollständiger dieser Kontext, desto schneller und sicherer läuft die eigentliche Migration.
Klassische Transpiler-Tools wie Lakebridge übernehmen die Umwandlung von Quellcode in eine erste Ziel-Syntax. Diese Rohübersetzung ist in der Regel syntaktisch korrekt, aber praktisch schlecht wartbar, weil alte Namenskonventionen erhalten bleiben und moderne Fähigkeiten wie Streaming ungenutzt bleiben. Unser Migrate Agent und Deploy Agent bauen auf einem solchen Transpiler-Schritt auf, reichern das Ergebnis über Harness Engineering mit Ihrem Unternehmenskontext an und übernehmen zusätzlich Planung, Testing und automatisierten Datenabgleich.
Der Migrate Agent schreibt zuerst Tests mit Beispieldaten und erst danach die eigentliche Transformationslogik. Dadurch werden Fehler früher sichtbar, statt erst beim Deployment aufzufallen. Der Deploy Agent ergänzt das um automatisierte Quality Tests gegen Vergleichstabellen, sodass jedes Mapping erst als abgeschlossen gilt, wenn der Datenabgleich im erwarteten Rahmen liegt.
Der Deploy Agent schlägt bei Abweichungen automatisiert Code-Änderungen vor und deployt anschließend erneut. Dieser Zyklus aus Deployment, Test und Anpassung läuft so lange, bis der Datenabgleich innerhalb der festgelegten Qualitätskriterien liegt. Offene Rückfragen an das Team betreffen dabei meist das Was, das Wohin und die konkreten Target-Tabellen.
Die Agenten arbeiten über MCP-Server, die kontrolliert auf Ihre Quellsysteme, Metadaten und die Zielumgebung in Databricks zugreifen, sowie über Databricks Agent Skills für wiederverwendbares Unternehmenswissen. Details zur konkreten technischen Einbindung in Ihre Umgebung klären wir im Erstgespräch, da das von Ihrer bestehenden IT-Landschaft abhängt.
Nein, das Prinzip aus Intermediate Representation, Harness Engineering und automatisierter Validierung ist grundsätzlich technologieneutral. Wie viel Anpassungsaufwand im Einzelfall entsteht, hängt aber davon ab, ob für Ihr Ausgangssystem bereits ein Transpiler-Schritt existiert oder die Zwischenrepräsentation erst aufgebaut werden muss.
