Die Frage, die uns luxemburgische Mittelständler zu diesem Thema stellen, lautet fast immer: Ist Databricks besser als DataStage? Das ist die falsche Frage. Beide Plattformen verarbeiten Daten zuverlässig, und beide werden aktiv weiterentwickelt. Die Entscheidung fällt an ganz anderer Stelle – beim Abrechnungsmodell, beim Zustand Ihres Job-Bestands und bei der Frage, wer die Plattform hinterher betreibt.

Eine Migration lohnt sich, wenn Ihre Datenlast stark schwankt und Ihr Team bereits mit SQL und Python arbeitet. Sie lohnt sich nicht, wenn Sie einen stabilen, gleichmäßig ausgelasteten Bestand betreiben und Ihre ETL-Kompetenz an einzelnen DataStage-Spezialisten hängt.

Wer eine Migration prüft, sollte zuerst wissen, dass beide Plattformen sich zuletzt deutlich bewegt haben.

IBM hat DataStage nicht abgekündigt – im Gegenteil. Das Produkt ist weiterhin in drei Betriebsmodellen verfügbar: klassisch on-premises, innerhalb von Cloud Pak for Data und inzwischen als vollständig gemanagter Dienst mit cloudbasierter Entwurfsoberfläche bei getrennter Ausführungsebene, sodass die Daten dort bleiben können, wo sie liegen. Wer glaubt, unter Zugzwang zu stehen, weil das Produkt ausläuft, irrt.

Databricks wiederum hat sein Data-Engineering-Angebot unter dem Namen Lakeflow zusammengeführt: Lakeflow Connect für die Anbindung von Quellen, Lakeflow Jobs für die Orchestrierung, Lakeflow Designer für die Aufbereitung.

Ein Angebot, ein Blogartikel oder eine interne Dokumentation, die noch die alten Produktnamen verwendet, ist schlicht nicht mehr aktuell – ein brauchbarer Frischetest für jedes Beratungsangebot, das Ihnen auf den Tisch kommt.

Das ist die Frage, die über den Aufwand entscheidet, und sie wird fast immer zu spät gestellt.

In gewachsenen DataStage-Landschaften ist ein erheblicher Teil der Jobs faktisch tot: Sie laufen für Berichte, die niemand mehr öffnet, befüllen Tabellen, die keine Anwendung mehr liest, oder sind Duplikate aus einem Projekt, das vor Jahren abgebrochen wurde. Wer diesen Bestand ungeprüft migriert, zahlt für die Übersetzung von Logik, die nichts mehr leistet.

Bevor Sie irgendein Angebot einholen, erheben Sie deshalb drei Dinge:

• Laufzeiten: Welche Jobs sind in den letzten sechs Monaten tatsächlich gelaufen – und wie oft?
• Abnehmer: Welche Zieltabellen werden von einem Bericht oder einer Anwendung wirklich gelesen?
• Dubletten: Welche Jobs tragen eine identische oder fast identische Logik?

Der wichtigste Unterschied zwischen den Plattformen ist nicht technischer, sondern kaufmännischer Natur.

Databricks rechnet verbrauchsbasiert in sogenannten DBUs ab, sekundengenau, mit der Möglichkeit, über Nutzungszusagen günstigere Konditionen zu erhalten. Klassische ETL-Lizenzierung läuft dagegen über Kapazität: Sie zahlen für eine definierte Ausstattung, unabhängig davon, ob Sie sie ausschöpfen.

Welches Modell günstiger ist, hängt allein an Ihrem Lastprofil. Läuft Ihre Verarbeitung in Spitzen – Monatsabschluss, Saisongeschäft, Kampagnenauswertung – und liegt die Infrastruktur dazwischen brach, dann zahlen Sie im Kapazitätsmodell dauerhaft für den Spitzenbedarf. Die Umstellung bringt hier real Geld.

Läuft Ihre Verarbeitung dagegen gleichmäßig durch, kehrt sich der Effekt um: Verbrauchsabrechnung wird bei konstanter Grundlast selten günstiger, dafür schwerer planbar. Für einen mittelständischen Betrieb mit festem IT-Budget ist eine monatlich schwankende Rechnung ein echter Nachteil, den man in der Begeisterung über Elastizität gerne übersieht.

Wer diesen Weg geht, braucht von Tag eins Budget-Alarme und eine Kostenzuordnung je Fachbereich – sonst lernen Sie die Kostenseite erst bei der ersten unangenehmen Rechnung kennen.

Hier scheitern Migrationen im Mittelstand häufiger als an der Technik.

DataStage wird grafisch entwickelt. Databricks wird im Kern mit SQL und Python bedient – auch wenn inzwischen Oberflächen für die Aufbereitung ohne Code zur Verfügung stehen. Für ein Team, das jahrelang grafisch modelliert hat, ist das kein Werkzeugwechsel, sondern ein Berufswechsel.

Für einen Betrieb mit zwei oder drei Personen im Datenumfeld heißt das konkret: Sie brauchen entweder Budget für echte Qualifizierung – nicht ein Zweitagesseminar, sondern begleitete Projektarbeit über Monate – oder einen externen Betriebspartner. Rechnen Sie diesen Posten in die Migration ein. Eine Plattform, die nach der Umstellung nur noch von einem externen Dienstleister verstanden wird, hat Ihre Abhängigkeit nicht verringert, sondern nur verlagert.

Es gibt Konstellationen, in denen wir von einer Migration abraten – auch wenn das gegen unser eigenes Projektgeschäft spricht:

• Stabiler Bestand, gleichmäßige Last, funktionierender Betrieb. Eine Migration bindet über Monate Ihre besten Leute. Dieses Budget ist fast immer besser in Datenqualität oder im Fachbereich investiert.
• ETL-Kompetenz hängt an ein bis zwei Personen. Dann entscheidet nicht die Plattform, sondern Ihr Personalrisiko. Das lösen Sie durch Dokumentation und einen zweiten Kopf, nicht durch neue Technologie.
• Regulatorische Auflagen sind ungeklärt. Im luxemburgischen Finanzsektor ist die Auslagerung an Cloud-Dienste an aufsichtsrechtliche Anforderungen gebunden. Diese Prüfung gehört an den Anfang des Projekts, nicht ans Ende.
• Der eigentliche Schmerz liegt woanders. Sehr oft ist nicht das ETL-Werkzeug das Problem, sondern fehlende Datenverantwortlichkeiten, uneinheitliche Stammdaten oder Berichte, denen niemand traut. Eine neue Plattform behebt nichts davon.

Wenn die drei Fragen für eine Migration sprechen, hat sich ein abschnittsweises Vorgehen bewährt – statt eines Stichtagswechsels:

1. Bestandsaufnahme mit Stilllegung aller nicht mehr benötigten Jobs.
2. Ein fachlich abgegrenzter Bereich als Pilot, der echten Wert liefert, aber nicht geschäftskritisch ist.
3. Parallelbetrieb mit Abgleich der Ergebnisse – alt und neu müssen dieselben Zahlen liefern, sonst verlieren Sie das Vertrauen der Fachbereiche.
4. Schrittweise Übernahme weiterer Bereiche, mit jeweils dokumentiertem Abschluss.
5. Abschaltung der Altlandschaft erst, wenn die Fachbereiche der neuen Plattform tatsächlich vertrauen.

Der Parallelbetrieb kostet vorübergehend doppelt. Das ist der Preis dafür, das Projekt jederzeit anhalten zu können – und für einen Mittelständler ist diese Rückfalloption mehr wert als ein paar Monate gesparte Laufzeit.

Zwei Punkte, die in internationalen Vergleichen fehlen, für Betriebe hier aber entscheidend sind.

Datenresidenz. Prüfen Sie früh, in welcher Region die Verarbeitung stattfindet und wo die Metadaten der Plattform liegen – nicht nur die Nutzdaten. Für Betriebe mit Kunden im Finanzsektor oder im öffentlichen Bereich ist das kein Nebenaspekt, sondern oft das Kriterium, das die Architektur bestimmt.

Förderung. Digitalisierungsvorhaben von KMU sind in Luxemburg über staatliche Programme förderfähig, wobei Beratungs- und Konzeptionsleistungen in der Regel besser abgedeckt sind als laufende Betriebskosten. Programmnamen und Fördersätze ändern sich – den aktuellen Stand finden Sie bei guichet.lu. Wichtig ist der zeitliche Ablauf: Anträge müssen vor Projektbeginn gestellt werden. Wer erst migriert und dann fragt, bekommt nichts.

Die Migration von DataStage zu Databricks ist eine betriebswirtschaftliche Entscheidung, keine technische. Prüfen Sie Ihr Lastprofil gegen das Abrechnungsmodell, bereinigen Sie Ihren Job-Bestand vor jeder Angebotsanfrage, und rechnen Sie die Qualifizierung Ihres Teams als vollwertigen Projektposten ein. Wenn Ihre bestehende Umgebung stabil läuft und Ihre Last gleichmäßig ist, ist Bleiben die wirtschaftlich richtige Entscheidung – auch wenn es die unspektakulärere ist.

• IBM DataStage – Produktübersicht und Betriebsmodelle
• Databricks – Data Engineering und Lakeflow
• Databricks – Preismodell und DBUs
• guichet.lu – Finanzielle Beihilfen für Unternehmen