Legacy-ETL ablösen – Informatica, ODI und Teradata nach SSIS/Azure migrieren

Positionierung

Legacy-ETL-Technologien wie Informatica PowerCenter, Oracle Data Integrator und Teradata waren über Jahrzehnte die Arbeitspferde der Datenbewegung in Grossunternehmen. Sie funktionierten zuverlässig, wurden aber auf Infrastrukturen aufgebaut, die sich seither fundamental verändert haben: AIX-Server, die durch Windows- und Linux-Cluster ersetzt wurden; Oracle-Datenbanken, die nach SQL Server oder Azure migriert wurden; Lizenzmodelle, die in einer Zeit entstanden, als Cloud-basierte Alternativen noch nicht existierten. Das Ergebnis sind Systeme, die technisch noch laufen, aber organisatorisch und wirtschaftlich zu einer zunehmenden Belastung geworden sind.

Ich bin mit diesen Technologien grossgeworden. Bei einem Logistikkonzern habe ich Informatica PowerCenter 8.6.1 und 9.1.0 im Produktiveinsatz betreut: Mappings, Maplets, Workflows, Worklets, Workflow Manager und Workflow Monitor, Restart-Logik für unterbrochene Läufe, SQL Overrides auf Source Qualifier- und Lookup-Transformationen, Parameterfiles für Multi-Mandanten-Betrieb und die AIX/KSH/Perl-Scheduling-Schicht, die die Workflows nächtlich aufrief. Ich kenne die Stärken dieser Architektur – und ich kenne ihre Grenzen und Kosten.

Oracle Data Integrator habe ich in einem Versicherungsumfeld erlebt, wo ODI-Interfaces Oracle-Quelldaten in Zieltabellen luden. Die ELT-Philosophie von ODI – Transformationen direkt in der Datenbank statt im ETL-Server – ist konzeptionell elegant, aber die proprietäre Knowledge-Module-Schicht und die Oracle-Abhängigkeit machen es schwer, ODI ausserhalb eines Oracle-Stack wirtschaftlich zu betreiben.

Teradata BTEQ-Skripte und FastLoad-Jobs habe ich sowohl im Logistikkonzern als auch in einem Gesundheits- und Sozialsektor-Projekt kennengelernt. Die Kurzform: BTEQ ist ein mächtiges, aber archaisches Werkzeug; FastLoad lädt Flatfiles mit beeindruckender Geschwindigkeit in Teradata-Tabellen, aber erfordert ein tiefes Verständnis des Teradata-eigenen Parallelitätsmodells.

Marktlage: Warum Legacy-ETL-Ablösung heute drängend ist

Die Frage, ob man Informatica PowerCenter oder Oracle Data Integrator ablösen soll, stellt sich für viele Unternehmen nicht mehr als strategische Option, sondern als wirtschaftliche Notwendigkeit. Die Lizenzkosten von Informatica PowerCenter lagen schon vor Jahren im fünfstelligen oder sechsstelligen Euro-Bereich pro Jahr – und sind seither nicht gesunken. Hinzu kommen Wartungsverträge, teure Supporteskalationen und die Notwendigkeit, spezialisiertes Personal vorzuhalten, das diese Werkzeuge bedienen kann.

Oracle Data Integrator ist an den Oracle-Stack gebunden. Wer ODI ohne Oracle-Datenbank betreiben will, steht vor einem konzeptionellen Problem: ODI ist architekturell als ELT-Werkzeug für Oracle ausgelegt. In Unternehmen, die ihren Oracle-Footprint im Rahmen einer SQL-Server- oder Azure-Migration reduzieren wollen, wird ODI zum Weiterbetrieb der letzten verbliebenen Oracle-Lizenz – was den Gesamtbetrieb teurer macht, nicht günstiger.

Teradata ist die teuerste Datenplattform im Markt. Für Unternehmen, die nur noch einen Teil ihrer Datenhaltung auf Teradata betreiben und den Rest bereits nach SQL Server oder Azure verschoben haben, ist der verbleibende Teradata-Block haufig der größte Einzelkostenblock der gesamten Dateninfrastruktur. Die Frage ist nicht ob, sondern wann und wie man diesen Block abbaut.

Technologie-Vereinheitlichung als Strategie

Neben den reinen Lizenzkosten ist Technologie-Vereinheitlichung ein eigenständiges Ziel. Unternehmen, die gleichzeitig Informatica, ODI, SSIS, ADF und Teradata betreiben, haben ein operatives Problem: Sie brauchen Spezialisten für jede dieser Technologien, können keine Werkzeuge und Skripte zwischen Teams teilen, und müssen Fehler in vier verschiedenen Paradigmen debuggen. Wer auf eine einheitliche Plattform – typischerweise SSIS für On-Premises und ADF für die Cloud – konsolidiert, senkt nicht nur Lizenzkosten, sondern auch Betriebskomplexität und Einarbeitungsaufwand für neues Personal.

• Informatica PowerCenter: Jährliche Lizenz- und Wartungskosten eliminieren
• Oracle Data Integrator: Oracle-Abhängigkeit auflösen, Stack vereinheitlichen
• Teradata: Teuerste Datenplattform durch SQL Server oder Azure ersetzen
• Konsolidierung auf SSIS/ADF: Einheitliche Plattform, breiterer Talentpool
• Risikoreduktion: Abkünftigungsrisiken alter Versionen beseitigen
• Moderne DevOps-Praktiken: CI/CD, Git, Deployment-Automatisierung einführen

Die Legacy-ETL-Landschaft typischer Grossunternehmen: Teradata, Informatica PowerCenter und ODI auf AIX-Infrastruktur – neben SSIS/Azure als kosteneffizientem Ziel. Lizenzkostenreduktion ist der primäre Migrationstreiber.

Informatica PowerCenter: Tiefenwissen aus dem Projektalltag

Informatica PowerCenter ist ein vollständiges ETL-Framework, das weit mehr ist als ein Datenintegrations-Werkzeug. Es umfasst einen Repository Service, Integration Service, Reporting Service und den Designer-Client mit seinen vier Editoren: Source Analyzer, Target Designer, Mapping Designer und Transformation Developer. Die Arbeit mit PowerCenter erfordert ein tiefes Verständnis dieser Architektur, um Lösungen zu bauen, die zuverlässig laufen, performant sind und bei Fehlern sauber neu gestartet werden können.

Mappings und Transformationen

Ein Informatica-Mapping beschreibt den Datenstrom von Quelltabellen oder -dateien über Transformationen bis zu Zieltabellen. Die Kernkomponenten sind Source Qualifier (lädt Quelldaten und erlaubt SQL Overrides), Expression Transformation (berechnet Ausdrucke zeilenweise), Aggregator Transformation (summiert, zählt, gruppiert), Lookup Transformation (lädt Referenzdaten aus DB oder Cache), Update Strategy (entscheidet Insert/Update/Delete pro Zeile), Router Transformation (verteilt Zeilen auf verschiedene Ausgänge) und Joiner Transformation (verbindet zwei Quell-Pipelines). Die Herausforderung liegt nicht im Kennen dieser Transformationen, sondern im sachgerechten Einsatz: Ein Aggregator mit zu vieler Arbeit im Mapping-Designer verlangsamt den gesamten Datenstrom; eine falsch konfigurierte Lookup-Transformation ohne Persistenz-Cache zieht bei jedem Datensatz eine Datenbankabfrage nach sich.

Workflows, Worklets und Restart-Logik

Während Mappings die Datentransformationslogik beschreiben, steuern Workflows die Ausführungsreihenfolge: Wann läuft welche Session? Welche Abhängigkeiten bestehen? Was passiert bei einem Fehler? Worklets sind wiederverwendbare Workflow-Fragmente – ein Konzept ähnlich Stored Procedures für Prozesslogik. Die Restart-Logik ist einer der kritischen Betriebsaspekte: PowerCenter kann unterbrochene Sessions an bestimmten Recovery-Punkten wieder aufnehmen, sofern die Sessions für Recovery konfiguriert wurden. Ich habe im Logistikkonzern Nacht-Läufe betreut, bei denen die Restart-Konfiguration entscheidend war – ein Reload der gesamten Session war bei Millionen von Zeilen keine akzeptable Fehlerbehandlung.

Der pmcmd-Kommandozeileninterpreter und Parameterfiles sind ebenfalls wichtige Betriebswerkzeuge. pmcmd erlaubt das Starten, Stoppen und Überwachen von Workflows von der Kommandozeile – und damit die Integration in externe Scheduler wie Autosys oder einfache Perl/KSH-Skripte. Parameterfiles machen Mappings mandantenfähig: Statt hartcodierter Quelltabellen oder Verbindungsstrings enthalten Parameterfiles austauschbare Werte, die pro Aufruf übergeben werden.

# Parameterfile fuer Informatica PowerCenter Workflow
# Definiert Verbindungs- und Laufzeitparameter fuer Mandant A
# Wird beim Workflow-Start per pmcmd uebergeben

[WF:WF_BESTELLUNG_LADEN]
# Quellverbindung fuer den aktuellen Mandanten
$$QUELL_DB_VERBINDUNG=TERADATA_PROD_MAND_A
# Zielverbindung SQL Server DWH
$$ZIEL_DB_VERBINDUNG=SQLSERVER_DWH_PROD
# Datumsbereich fuer Delta-Load (Format YYYY-MM-DD)
$$DELTA_VON=2024-01-01
$$DELTA_BIS=2024-01-31
# Batch-ID fuer Protokollierung
$$BATCH_ID=20240131_A

[SESS:S_BESTELLUNG_LADEN]
# SQL Override auf Source Qualifier - laedt nur den aktuellen Mandant
$$SQ_SQL_OVERRIDE=SELECT BEST_NR, DATUM, BETRAG, MAND_ID FROM TD_BESTELLUNG WHERE MAND_ID = 'A' AND DATUM BETWEEN TO_DATE('$$DELTA_VON','YYYY-MM-DD') AND TO_DATE('$$DELTA_BIS','YYYY-MM-DD')

# --- pmcmd-Aufruf aus dem Perl-Scheduler ---
# Startet den Workflow mit dem obigen Parameterfile
# pmcmd startworkflow -sv IntegrationService -d Domain -u admin -p <pw> -f Folder -paramfile ./params/mand_a.par WF_BESTELLUNG_LADEN

Parameterfiles erlauben es, dasselbe Mapping für verschiedene Mandanten, Zeitbereiche oder Umgebungen (Test/Prod) zu verwenden, ohne den Mapping-Code zu ändern. pmcmd integriert PowerCenter in externe Scheduler.

Oracle Data Integrator: ELT-Konzepte und Migrationsstrategie

Oracle Data Integrator unterscheidet sich konzeptionell grundlegend von ETL-Werkzeugen wie Informatica oder SSIS: ODI verfolgt den ELT-Ansatz (Extract, Load, Transform), bei dem Transformationen nicht auf einem eigenen ETL-Server stattfinden, sondern direkt in der Zieldatenbank ausgeführt werden. Die Quelldaten werden zürst in Staging-Bereiche der Zieldatenbank geladen; dort generiert ODI SQL-Skripte (sogenannte Knowledge-Module-Ausführungen), die die Transformation übernehmen. Für Oracle-zu-Oracle-Szenarien ist das elegant; für heterogene Migrationsszenarien wird es zum Problem.

ODI-Konzepte: Interfaces, Knowledge Modules, Datenspeicher

Das zentrale ODI-Konzept ist das Interface: Ein Interface beschreibt, woher Daten kommen (Quell-Datastore), wie sie transformiert werden (Mapping-Ausdrücke und Joins) und wohin sie gehen (Ziel-Datastore). Knowledge Modules (KM) sind wiederverwendbare Code-Templates, die aus dieser Interface-Beschreibung konkrete SQL- oder PL/SQL-Skripte generieren: der Loading Knowledge Module (LKM) lädt Daten in den Staging-Bereich, der Integration Knowledge Module (IKM) führt die Zieltransformation aus. Für den Migrationsspezialisten bedeutet das: Nicht das Interface ist zu migrieren, sondern das erzeugte SQL, das durch das Interface und die KMs entsteht – das ist die eigentliche Transformationslogik.

In einem Versicherungsprojekt habe ich ODI-Interfaces gefunden, deren IKM-generiertes SQL hochgradig Oracle-spezifisch war: MERGE-Statements mit NOAPPEND-Hints, PL/SQL-Prozeduraufrufe innerhalb der KM-Ausführung, CONNECT BY-Hierarchiequeries und Oracle-spezifische Datumsformatierung. Das Ziel war eine Migration nach SSIS auf SQL Server. Die Herausforderung war nicht das ODI-Konzept zu verstehen, sondern das Oracle-PL/SQL in äquivalentes T-SQL zu übersetzen und sicherzustellen, dass die Ausgabe bit-identisch mit dem alten System war.

-- Originallogik: ODI Interface mit Oracle-PL/SQL IKM-Ergebnis
-- (vereinfachte Darstellung des generierten SQL aus dem IKM)
-- Quelle: Oracle-Staging-Bereich (AP$_VERTRAG)
MERGE INTO DWH_VERTRAG TGT
USING (
    -- Quell-Transformation im Oracle-Staging
    SELECT
        V.VERTRAG_NR,
        V.VERS_NR,
        TO_DATE(V.ABSCHLUSS_DATUM, 'YYYYMMDD') AS ABSCHLUSS_DT,
        NVL(V.PRAEMIE, 0)                       AS PRAEMIE_EUR,
        DECODE(V.STATUS, '1','AKTIV','0','STORNO','UNBEKANNT') AS STATUS_TXT
    FROM AP$_VERTRAG V
    WHERE V.BATCH_ID = :BATCH_ID
) SRC
ON (TGT.VERTRAG_NR = SRC.VERTRAG_NR)
WHEN MATCHED THEN
    UPDATE SET TGT.PRAEMIE_EUR = SRC.PRAEMIE_EUR,
               TGT.STATUS_TXT  = SRC.STATUS_TXT,
               TGT.AEND_DT     = SYSDATE
WHEN NOT MATCHED THEN
    INSERT (VERTRAG_NR, VERS_NR, ABSCHLUSS_DT, PRAEMIE_EUR, STATUS_TXT, ANLAGE_DT)
    VALUES (SRC.VERTRAG_NR, SRC.VERS_NR, SRC.ABSCHLUSS_DT,
            SRC.PRAEMIE_EUR, SRC.STATUS_TXT, SYSDATE);

-- SSIS/T-SQL-Aequivalent nach der Migration:
-- Der SSIS Dataflow laedt die Quelle, das Execute SQL Task fuehrt das T-SQL-MERGE aus.
-- SSIS OLE DB Source: Laedt aus SQL Server Staging (vorher per ADF oder Linked Server befuellt)
-- T-SQL MERGE auf SQL Server DWH:
MERGE INTO dbo.DWH_Vertrag AS TGT
USING (
    -- Staging-Abfrage auf SQL Server
    SELECT
        VERTRAG_NR,
        VERS_NR,
        -- Oracle TO_DATE -> T-SQL CONVERT mit Format 112 (YYYYMMDD)
        CONVERT(DATE, ABSCHLUSS_DATUM, 112)          AS ABSCHLUSS_DT,
        ISNULL(PRAEMIE, 0)                            AS PRAEMIE_EUR,
        -- Oracle DECODE -> T-SQL CASE
        CASE STATUS WHEN '1' THEN 'AKTIV'
                    WHEN '0' THEN 'STORNO'
                    ELSE 'UNBEKANNT' END              AS STATUS_TXT
    FROM dbo.Stg_Vertrag
    WHERE BATCH_ID = @BATCH_ID
) AS SRC
ON TGT.VERTRAG_NR = SRC.VERTRAG_NR
WHEN MATCHED THEN
    UPDATE SET TGT.PRAEMIE_EUR = SRC.PRAEMIE_EUR,
               TGT.STATUS_TXT  = SRC.STATUS_TXT,
               TGT.AEND_DT     = GETDATE()
WHEN NOT MATCHED THEN
    INSERT (VERTRAG_NR, VERS_NR, ABSCHLUSS_DT, PRAEMIE_EUR, STATUS_TXT, ANLAGE_DT)
    VALUES (SRC.VERTRAG_NR, SRC.VERS_NR, SRC.ABSCHLUSS_DT,
            SRC.PRAEMIE_EUR, SRC.STATUS_TXT, GETDATE());

Das wesentliche Migrationsproblem von ODI nach SSIS/T-SQL: Oracle-spezifische Funktionen (NVL, DECODE, TO_DATE, SYSDATE) müssen in T-SQL-Äquivalente (ISNULL, CASE, CONVERT, GETDATE) übersetzt werden. Die Logik ist identisch, die Syntax unterscheidet sich.

Teradata: BTEQ, FastLoad und SQL-Dialekt

Teradata ist eine Datenplattform, die für massiv-parallele SQL-Abfragen auf sehr grossen Datenmengen gebaut wurde. Ihr Parallelitätsmodell – automatische Verteilung von Zeilen auf Knoten über den Primary Index, parallele Abfrageausführung über AMPs (Access Module Processors) – ist beeindruckend leistungsfähig, erfordert aber ein Verständnis der Teradata-eigenen Konzepte: Primary Index, Partitioning, Spool-Space-Management und BTEQ-Skripterstellung.

BTEQ: Batch-Scripting auf Teradata

BTEQ (Basic Teradata Query) ist das primäre Batch-Skript-Werkzeug für Teradata. Es erlaubt das Ausführen von SQL-Sequenzen, das Behandeln von Fehlercodes, das Exportieren und Importieren von Daten und die bedingte Steuerung des Skriptablaufs. BTEQ läuft auf Unix/AIX, Windows und der Teradata-Konsole selbst und war in vielen Grossunternehmen der primäre Mechanismus für nächliche Batchverarbeitung vor der Einführung dedizierter ETL-Werkzeuge.

Im Logistikkonzern habe ich BTEQ-Skripte betreut, die nächtlich Bonusprogramm- und Qualitätssicherungsdaten luden, transformierten und in Reporting-Tabellen schrieben. Diese Skripte waren historisch gewachsen und folgten keiner einheitlichen Fehlerbehandlungskonvention – das ist typisch für BTEQ-Umgebungen. Die Migration erforderte zunächst ein vollständiges Inventar dieser Skripte, eine Abhängigkeitsanalyse und die Übersetzung in SQL-Agent-Jobs auf SQL Server.

.LOGON tdpid/tduser,tdpasswd;

-- Pruefe ob eine vorherige Session noch laeuft (Sperrtabelle)
-- .IF errorcode <> 0 THEN .QUIT 12;

SELECT 'BTEQ-Lauf gestartet: ' || CAST(CURRENT_TIMESTAMP AS CHAR(26));

-- Schritt 1: Zieltabelle bereinigen (Partitions-Delete statt TRUNCATE)
DELETE FROM DWH_BESTELLUNG_STG
WHERE BATCH_DT = CAST('${BATCH_DT}' AS DATE FORMAT 'YYYY-MM-DD');
.IF ERRORCODE <> 0 THEN .GOTO FEHLER;

-- Schritt 2: Daten aus Quelltabelle laden
INSERT INTO DWH_BESTELLUNG_STG
  (BEST_NR, BEST_DT, KUNDE_ID, BETRAG_EUR, BATCH_DT)
SELECT
    B.BEST_NR,
    B.BEST_DT,
    B.KUNDE_ID,
    -- Teradata-Dezimalformat: Punkt als Tausendertrenner vermeiden
    CAST(B.BETRAG AS DECIMAL(15,2)) AS BETRAG_EUR,
    CAST('${BATCH_DT}' AS DATE FORMAT 'YYYY-MM-DD') AS BATCH_DT
FROM PROD_BESTELLUNG B
WHERE B.BEST_DT = CAST('${BATCH_DT}' AS DATE FORMAT 'YYYY-MM-DD')
  AND B.STATUS_CD NOT IN ('X','S');
.IF ERRORCODE <> 0 THEN .GOTO FEHLER;

SELECT CAST(COUNT(*) AS VARCHAR(10)) || ' Zeilen geladen.' FROM DWH_BESTELLUNG_STG
WHERE BATCH_DT = CAST('${BATCH_DT}' AS DATE FORMAT 'YYYY-MM-DD');

.GOTO ENDE;
.LABEL FEHLER;
  SELECT 'Fehler bei BATCH_DT=${BATCH_DT}, ERRORCODE: ' || CAST(.ERRORCODE AS VARCHAR(5));
  .QUIT 99;
.LABEL ENDE;
  .LOGOFF;
  .QUIT 0;

Typisches BTEQ-Muster: Logon, fehlergesichertes DELETE vor dem INSERT, bedingte Sprungmarken (.IF ERRORCODE / .GOTO / .LABEL), explizites LOGOFF. Das Variablen-Substitutionsmuster (${BATCH_DT}) wird durch den aufrufenden Perl- oder KSH-Wrapper gesetzt.

Teradata FastLoad für Flatfile-Ladevorgänge

Während BTEQ für SQL-basierte Transformation und Steuerung verwendet wird, ist FastLoad das Teradata-Werkzeug für hochparalleles Laden von Flatfiles. FastLoad umgeht den Transaktionslog vollständig und lädt Daten direkt in leere Tabellen – was es um Größenordnungen schneller macht als INSERT-basierte Ladevorgänge, aber auch weniger flexibel: Eine Fehlerbehandlung auf Zeilenebene erfordert Fehler-Tabellen (ET-Tabellen). Im Gesundheits- und Sozialsektor habe ich FastLoad-Jobs betreut, die täglich Abrechnungsflatfiles mit Millionen von Zeilen in Teradata-Staging-Tabellen luden. Die Migration dieser Jobs auf SSIS Bulk Insert Task oder BCP war einer der einfachsten Teile der gesamten Legacy-Ablösung – der konzeptionelle Sprung ist gering, die Syntax ist verschieden.

Perl, KSH und AIX: Die Scheduling-Welt der Grossrechner-Ära

Für viele ETL-Umgebungen der frühen 2000er Jahre war AIX (IBM Advanced Interactive eXecutive, IBMs Unix) die primäre Serverbasis. Informatica PowerCenter, Teradata BTEQ und die gesamte Scheduling-Infrastruktur liefen auf AIX-Servern. Das Scripting erfolgte in Perl oder der Korn Shell (KSH), die Tagesplanung über Cron-Jobs oder kommerzielle Scheduler wie Autosys.

Diese Schicht – der Perl- oder KSH-Wrapper, der BTEQ-Skripte aufrief, Rückgabecodes prüft, Logdateien schrieb und bei Fehler eine Alertmail absetzte – ist bei Migrationen häufig die übersehenste Komponente. Dabei ist sie essentiell: Sie definiert die Ausführungsreihenfolge, die Parameterubergabe, das Fehlerverhalten und die Protokollierung. Bei der Migration muss diese Schicht vollständig inventarisiert und in SQL-Agent-Jobs oder Azure Data Factory Pipelines übergeführt werden.

#!/usr/bin/ksh
# KSH-Wrapper fuer Informatica PowerCenter und BTEQ Batchjobs auf AIX
# Aufruf: nightly_load.ksh YYYY-MM-DD
# Gibt 0 bei Erfolg zurueck, 99 bei Fehler (fuer Autosys-Integration)

BATCH_DT=${1:-$(date +%Y-%m-%d)}
LOGDIR=/opt/etl/logs
LOGFILE="${LOGDIR}/nightly_${BATCH_DT}.log"
BTEQ_DIR=/opt/etl/bteq
PMCMD=/opt/informatica/server/bin/pmcmd

# Hilfsfunktion: Fehlermeldung loggen und Skript abbrechen
fehler_exit() {
    echo "[FEHLER] $(date '+%Y-%m-%d %H:%M:%S') $1" >> "$LOGFILE"
    exit 99
}

echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') Nachtlauf gestartet fuer BATCH_DT=${BATCH_DT}" >> "$LOGFILE"

# Schritt 1: BTEQ-Skript ausfuehren (Teradata Staging laden)
# Substitution von BATCH_DT im BTEQ-Template
sed "s/\${BATCH_DT}/${BATCH_DT}/g" "${BTEQ_DIR}/load_bestellung.bteq" > /tmp/load_bestellung_run.bteq
bteq < /tmp/load_bestellung_run.bteq >> "$LOGFILE" 2>&1
RC=$?
if [ $RC -ne 0 ]; then
    fehler_exit "BTEQ load_bestellung.bteq fehlgeschlagen, RC=${RC}"
fi
echo "[OK] $(date '+%Y-%m-%d %H:%M:%S') BTEQ erfolgreich abgeschlossen." >> "$LOGFILE"

# Schritt 2: Informatica PowerCenter Workflow starten
# pmcmd gibt 0 bei Erfolg zurueck
$PMCMD startworkflow \
    -sv IntegrationService_PROD \
    -d Domain_PROD \
    -u etl_user \
    -p $(cat /opt/etl/secrets/.ipc_pw) \
    -f ETL_BESTELLUNG \
    -paramfile "${BTEQ_DIR}/params/mand_a_${BATCH_DT}.par" \
    WF_BESTELLUNG_LADEN >> "$LOGFILE" 2>&1
RC=$?
if [ $RC -ne 0 ]; then
    fehler_exit "Informatica Workflow WF_BESTELLUNG_LADEN fehlgeschlagen, RC=${RC}"
fi
echo "[OK] $(date '+%Y-%m-%d %H:%M:%S') Informatica Workflow abgeschlossen." >> "$LOGFILE"
echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') Nachtlauf erfolgreich beendet." >> "$LOGFILE"
exit 0

Typischer AIX/KSH-Wrapper: Parameterübergabe, BTEQ-Template-Substitution mit sed, Rückgabecodeprüfung, pmcmd-Integration für Informatica PowerCenter. Diese Schicht muss bei der Migration vollständig inventarisiert werden.

Migration der Scheduling-Schicht nach SQL Agent / ADF

Der KSH/Perl-Wrapper auf AIX hat auf SQL Server oder Azure keine direkte Entsprechung als Betriebssystem-Skript. Die Äquivalenz entsteht durch SQL-Agent-Jobs mit mehreren Schritten (T-SQL-Schritt, SSIS-Paket-Schritt, PowerShell-Schritt) oder durch ADF Pipelines mit bedingten Aktivitäten und Fehlerbehandlung. Der Schlüsselpunkt ist die Semantik zu erhalten: Ausführungsreihenfolge, Parameterubergabe, Fehlerbehandlung und Alerting müssen funktional äquivalent sein, auch wenn die Technologie eine andere ist.

Migrationsvorgehensmodell: Analyse bis Go-Live

Eine Legacy-ETL-Migration ist kein Big-Bang-Projekt. Wer versucht, alle Informatica-Workflows, ODI-Interfaces und BTEQ-Skripte gleichzeitig zu migrieren und mit einem Stichtag umzuschalten, riskiert unentdeckte Fehler und Produktionsprobleme. Mein Ansatz ist iterativ und phasiert: Zürst verstehen, dann übersetzen, dann vergleichen, dann ablosen.

Das Migrationsvorgehensmodell in fünf Phasen. Phase 4 (Ausgabevergleich) ist die qualitätssichernde Kernphase: Neue und alte ETL-Logik laufen parallel mit identischen Eingabedaten; die Ausgaben werden automatisiert verglichen.

Phase 1: Inventarisierung und Abhängigkeitsanalyse

Bevor eine einzige Zeile neuer Code geschrieben wird, erfasse ich den vollständigen Ist-Zustand: Alle Informatica-Mappings und Workflows (Repository-Export), alle ODI-Interfaces (Topology/Kontext-Export), alle BTEQ-Skripte (Dateisystem-Scan), alle Perl/KSH-Wrapper und ihre Aufrufbeziehungen. Aus diesem Inventar entsteht ein Abhängigkeitsgraph: Welche Workflows hängen voneinander ab? Welche Tabellen werden als Zwischen-Staging von mehreren Strecken verwendet? Dieser Graph bestimmt die Migrationsreihenfolge.

Phase 2: Äquivalenzanalyse

Jedes zu migrierende Objekt erhält ein Äquivalenz-Mapping: Informatica-Mapping → SSIS-Dataflow, ODI-Interface → SSIS-Dataflow oder T-SQL-Prozedur, BTEQ-Skript → SQL-Agent-Job. Für jeden Transformationsschritt wird die Entsprechung in der Zielplattform explizit definiert. Besondere Aufmerksamkeit gilt Sonderfällen: Oracle-spezifische SQL-Funktionen, Teradata-spezifische DATE-Typen und Formatierungen, Informatica-interne Funktionen ohne direktes SSIS-Äquivalent.

Phase 3: Aufbau in der Zielplattform

Mit dem Äquivalenz-Mapping als Grundlage werden SSIS-Pakete, T-SQL-Prozeduren und SQL-Agent-Jobs aufgebaut. Jedes neue Objekt ist in Git versioniert, folgt dem definierten Naming-Standard und enthält Logging, Fehlerbehandlung und Parametrisierung. Der Aufbau erfolgt iterativ – nicht alle Strecken gleichzeitig, sondern in der durch den Abhängigkeitsgraph vorgegebenen Reihenfolge.

Phase 4: Ausgabe-Vergleich mit identischen Eingaben

Phase 4 ist die qualitätskritischste Phase. Altes System und neues System laufen parallel mit denselben Eingabedaten. Die Ausgabetabellen werden automatisiert verglichen – zürst auf Zeilenanzahl, dann auf Hashwerte aggregierter Spalten, dann auf Einzelzeilen-Differenzen. Erst wenn der Ausgabe-Vergleich für alle Strecken fehlerfrei ist, wird die Migration freigegeben.

Phase 5: Go-Live und Lizenzabschaltung

Der Go-Live ist keine Stunde Null, sondern der Abschluss eines validierten Prozesses. Das Altsystem bleibt für eine definierte Nachlauffrist aktiv (typischerweise zwei bis vier Wochen), um bei unerwarteten Problemen zurückschwenken zu können. Erst nach bestädigter Stabilität wird die Legacy-Lizenz abgemeldet – das ist der Moment, an dem die Kosteneinsparung konkret wird.

• Vollständige Inventarisierung vor dem ersten Codezeile
• Abhängigkeitsgraph als Grundlage der Migrationsreihenfolge
• Explizites Äquivalenz-Mapping für jeden Schritt
• Git-Versionierung aller neuen Objekte von Anfang an
• Parallelbetrieb und Ausgabe-Vergleich als Qualitätsgate
• Definierte Rückrollmöglichkeit bis zur Lizenzabschaltung

Technologieäquivalenz: Legacy zu SSIS und Azure

Jede Legacy-ETL-Komponente hat ein Äquivalent in der modernen Plattform. Die folgende Tabelle zeigt die primären Entsprechungen – sowohl für On-Premises SSIS als auch für Azure Data Factory als Cloud-Zielplattform. Das Mapping ist nicht immer eins-zu-eins, aber immer vollständig: Für jedes Legacy-Konzept gibt es einen klaren Nachfolger.

Vollständige Technologieäquivalenz-Matrix: Jede Legacy-Komponente aus Informatica PowerCenter, ODI und Teradata hat ein definiertes Gegenstück in SSIS oder Azure Data Factory. Diese Matrix ist die Grundlage jedes Migrationsplans.

Informatica-Äquivalenzen im Detail

Der Informatica Source Qualifier entspricht dem SSIS OLE DB Source mit SQL-Abfrage. SQL Overrides im Source Qualifier werden zu parametrisierten Abfragen im SSIS OLE DB Source-Editor. Der Informatica Aggregator wird zu SSIS Aggregate Transformation oder – für komplexere Logik – zu einem T-SQL GROUP BY in einer Staging-Prozedur. Die Informatica Lookup Transformation entspricht dem SSIS Lookup Transformation mit Cache-Option (vergleichbar mit Informatica Connected Cache). Der Informatica Router entspricht dem SSIS Conditional Split.

ODI-Äquivalenzen im Detail

Ein ODI Interface mit LKM Oracle to Oracle entspricht einem SSIS Dataflow mit OLE DB Source und OLE DB Destination. Der IKM-Teil (INSERT/UPDATE-Logik) entspricht einem SSIS Execute SQL Task mit MERGE-Statement oder einem Upsert-Muster im SSIS-Dataflow mit SSIS Lookup + Conditional Split + OLE DB Command. ODI Procedures (frei editierbare PL/SQL-Blöcke) entsprechen SQL-Agent-Job-Schritten mit T-SQL-Aufrufen.

Teradata-Äquivalenzen im Detail

BTEQ-Logik (mehrstufige INSERT/SELECT-Sequenzen mit Fehlerbehandlung) wird zu SQL-Agent-Jobs mit T-SQL-Schritten. BTEQ-Variablensubstitution durch sed/Perl wird zu SQL-Agent-Job-Parametern oder SSIS-Paket-Parametern. Teradata FastLoad wird zu SSIS Bulk Insert Task, BCP oder SSIS Data Flow mit OLE DB Destination im Fast Load-Modus. Teradata Macros (wiederverwendbare parametrisierte SQL-Blöcke) entsprechen T-SQL Stored Procedures auf SQL Server.

• Informatica Mapping → SSIS Package (Control Flow + Data Flow)
• Informatica Workflow/Worklet → SQL Agent Job mit Job-Schritten
• Informatica Session Log → SSIS Logging (Event Handler + Logging-Provider)
• ODI Interface (LKM+IKM) → SSIS Dataflow + Execute SQL Task (MERGE)
• ODI Knowledge Module → SSIS Custom Component oder Script Task
• BTEQ-Skript → SQL Agent Job (T-SQL-Schritt) + SSIS-Paket
• Teradata FastLoad → SSIS Bulk Insert Task oder BCP
• Perl/KSH-Scheduler → SQL Agent Job mit Abhängigkeiten oder ADF Pipeline

Qualitätssicherung: Output-Vergleich mit identischen Eingaben

Der Output-Vergleich ist das Herzstuck der Migrationszertifizierung. Das Prinzip ist einfach: Beide Systeme – Legacy und Zielplattform – werden mit identischen Eingabedaten betrieben. Die Ausgabemengen, Aggregatwerte und Einzelzeilen werden verglichen. Wenn die Ausgaben übereinstimmen, ist die Migration korrekt. Wenn sie abweichen, zeigt der Vergleich exakt, wo die Abweichung liegt.

In der Praxis gibt es Herausforderungen: Legacy-Systeme auf Teradata oder Informatica können Sortierordnungen und NULL-Behandlung anders handhaben als SQL Server. BTEQ-Skripte können auf undokumentierte Teradata-Default-Verhalten beruhen, die SQL Server anders behandelt. Diese Abweichungen sind keine Fehler der Migration, sondern Unterschiede in der Plattform-Semantik, die explizit dokumentiert und mit dem Fachbereich abgestimmt werden müssen.

Automatisierter Vergleich mit T-SQL

Ich verwende T-SQL-Vergleichsprozeduren, die gegen das Legacy-Ergebnis und das Migrations-Ergebnis laufen. Zürst Zeilenanzahl-Vergleich, dann Aggregat-Hashes (CHECKSUM_AGG über aggregierte Spalten), dann Einzelzeilen-Differenzen über einen FULL OUTER JOIN mit NOT EXISTS-Prüfung. Der Vergleich wird für jeden Testlauf in einer Protokolltabelle festgehalten, damit ein vollständiger Prüfpfad entsteht.

Ein besonderer Aspekt ist die Behandlung von Fliesskommazahlen und gerundeten Werten: Oracle, Teradata und SQL Server runden unterschiedlich bei Grenzfällen. Ich definiere Toleranzschwellen für numerische Felder und protokolliere Abweichungen unterhalb der Toleranz separat. Nur Abweichungen oberhalb der Toleranz gelten als Migrationsfehler.

Lizenzkostenreduktion als zentrales Projektziel

Legacy-ETL-Lizenzen sind teuer – und die Kosten steigen, während die Nutzung sinkt. Informatica PowerCenter-Lizenzen werden pro Kern oder pro Server berechnet und beinhalten jährliche Wartungsgebuhren, die bei größeren Umgebungen schnell sechsstellige Jahresbeträge erreichen. Oracle-Datenbank-Lizenzen, die häufig nur noch wegen ODI benötigt werden, kosten ähnlich viel. Teradata ist die teuerste Einzelkomponente: Eine Teradata-Appliance inklusive Software und Wartung übersteigt die Kosten einer vergleichbaren SQL-Server-Umgebung um ein Vielfaches.

Der Return on Investment einer Migration lässt sich konkret berechnen: Einsparung Legacy-Lizenz pro Jahr minus Migrationskosten ergibt den Break-Even-Zeitraum. Für eine typische Informatica-PowerCenter-Umgebung mit drei bis fünf Servern liegt der Break-Even oft unter einem Jahr, weil die jährliche Einsparung die Migrationskosten übersteigt. Für Teradata-Umgebungen liegt der Break-Even bei mittleren Datenvolumina ebenfalls oft unter zwei Jahren.

Was SSIS im SQL-Server-Paket kostet: Nichts

SSIS ist im SQL Server Enterprise oder Standard Edition enthalten – keine gesonderte Lizenz, kein jährliches Renewal, kein Per-Core-Aufpreis. Wer bereits SQL Server betreibt und Informatica oder ODI ablost, zahlt für das Migrations-Ziel keine zusätzlichen Lizenzkosten. Das ist einer der starksten wirtschaftlichen Argumente für SSIS als Migrationsziel: Die Zielplattform ist bereits bezahlt.

Azure Data Factory: Variables Kostenmodell statt Fixlizenz

Azure Data Factory folgt einem Verbrauchsmodell: Es fallen Kosten für ausgeführte Pipeline-Aktivitäten, Datenbewegungsvolumen und Integrations-Runtime-Stunden an. Für Umgebungen mit täglichen Batch-Läufen und moderatem Datenvolumen liegen diese Kosten typischerweise deutlich unter den Fixkosten einer vergleichbaren Informatica- oder Teradata-Umgebung – und skalieren nach unten, wenn Ladevorgänge entfallen.

• Informatica PowerCenter: Lizenz- und Wartungskosten eliminieren
• ODI: Oracle-DB-Lizenz ablosen, die nur noch für ODI benötigt wird
• Teradata: Teuerste Komponente durch SQL Server oder Azure ersetzen
• SSIS: Bereits in SQL Server enthalten – kein zusätzlicher Lizenzaufwand
• Azure Data Factory: Verbrauchsbasiert statt Fixlizenz
• ROI-Berechnung: Break-Even oft unter einem Jahr

Azure als Zielplattform: SSIS vs. ADF

Bei jeder Migration stellt sich die Frage: SSIS on-premises oder Azure Data Factory? Die Antwort hängt von der bestehenden Infrastruktur, den Datenquellen und dem strategischen Weg des Unternehmens in Richtung Cloud ab.

Wann SSIS die richtige Wahl ist

SSIS ist die richtige Wahl, wenn die Quell- und Zielsysteme on-premises liegen und der Netzwerkverkehr den Azure-Umweg nicht rechtfertigt. SQL Server mit SSIS läuft auf vorhandener Infrastruktur, kann sofort produktiv gesetzt werden und erfordert keine Cloud-Migrationskosten. SSIS ist ausserdem dann vorzuziehen, wenn komplexe Datenflüsse mit vielen Transformationsschritten vorliegen, die in ADF umständlicher abzubilden sind – SSIS bietet hier eine reichhaltigere Transformation-Bibliothek.

Wann Azure Data Factory besser ist

ADF ist die richtige Wahl, wenn das Unternehmen bereits auf Azure-Cloud-Dienste setzt oder setzt: Azure SQL Database, Azure Synapse, Blob Storage, Data Lake Storage. ADF integriert sich nahtlos in diese Dienste und vermeidet den Umweg über einen on-premises SSIS-Server. ADF erlaubt ausserdem Cloud-native Features wie Elastic Scaling, integriertes Monitoring mit Azure Monitor und native Parameterisierung über Azure Key Vault – Aspekte, die on-premises SSIS in dieser Form nicht bietet.

SSIS in Azure via Integration Runtime

Ein Kompromiss ist der SSIS-Azure-Lift-and-Shift über die Azure-SSIS Integration Runtime in ADF: Bestehende SSIS-Pakete laufen in Azure, ohne umgeschrieben werden zu müssen. Das ist eine attraktive Option für Unternehmen, die ihre SSIS-Pakete nach Azure verschieben wollen, ohne den SSIS-Entwicklungsaufwand zu verdoppeln. Langfristig ist eine Migration auf native ADF-Aktivitäten zu empfehlen, weil die Azure-SSIS Integration Runtime vergleichsweise teuer ist.

• SSIS on-premises: Für reine On-Premises-Strecken, sofortige Nutzung
• SSIS in Azure-IR: Lift-and-Shift von SSIS-Paketen in die Cloud
• Azure Data Factory: Für Cloud-native Szenarien mit Azure-Diensten
• Hybrid: SSIS und ADF können koexistieren und sich ergänzen
• Azure Synapse Analytics: Grosse Datenmengen, Data-Warehouse-Workloads
• Langfristig: Native ADF für Cloud-Neuentwicklungen bevorzugen

Typische Leistungen im Überblick

Das Spektrum meiner Legacy-ETL-Leistungen reicht von der initialen Bestandsaufnahme bis zum produktiven Go-Live der Migrationslosung. Je nach Projektphase und Bedarf übernehme ich einzelne Bereiche oder den vollständigen Migrationspfad.

• Inventarisierung: Informatica-Repository-Export, ODI-Topology, BTEQ-Datei-Scan, Perl/KSH-Mapping
• Abhängigkeitsanalyse und Priorisierung der Migrationsreihenfolge
• Äquivalenz-Mapping: Legacy-Komponenten zu SSIS/ADF-Konstrukten
• SSIS-Entwicklung: Datenflüsse, Control Flows, Fehlerbehandlung, Logging, Deployment
• T-SQL-Entwicklung: MERGE-Prozeduren, Staging-Logik, SQL-Agent-Jobs
• Azure Data Factory: Pipelines, Datasets, Linked Services, Trigger, Key Vault
• Output-Vergleich: T-SQL-Vergleichsprozeduren, Differenzreport, Freigabe-Dokumentation
• Go-Live-Begleitung: Parallelbetrieb, Überwachung, Lizenzabschaltungs-Koordination
• Dokumentation: Technische Spezifikation, Betriebs-Handbuch, Übergabe ans interne Team

Die Migrationsarbeit kann als vollständiges Projekt (von der Analyse bis zum Go-Live) oder als gezielte Unterstützung einzelner Phasen stattfinden. Für Unternehmen, die bereits mit der Migration begonnen haben und auf Probleme gestossen sind, kann ich gezielt dort einsteigen, wo Unterstützung benötigt wird – ob bei der Äquivalenzanalyse, der SSIS-Entwicklung oder der Output-Vergleichs-Automatisierung.

Remote-Arbeit ist bei Legacy-ETL-Migrationen gut möglich, sofern der Zugriff auf die relevanten Systeme (Informatica Repository, ODI-Topology, Teradata, SQL Server, Azure) sichergestellt ist. Für die initialen Inventarisierungsphasen und die Go-Live-Begleitung ist persönliche Anwesenheit oft wertvoll, weil der Kommunikationsaufwand in kritischen Phasen hoch ist.

Anonymisierte Referenzprojekte

Häufige Fragen zur Legacy-ETL-Migration