SSIS-Schwachstellen: Warum das Verlagern der Packages in die Cloud nur die Altlasten mitnimmt

SSIS-Altlasten haben drei Probleme, die eine Cloud-VM nicht löst: ein Package pro Tabelle, das niemand öffnen will, Releases, die DevOps nicht erreicht, und ein Design, das bei SQL Server aufhört. Die Azure-SSIS Integration Runtime trägt alle drei unverändert in die Cloud. Ein Modell, das das Warehouse generiert, macht sie stattdessen überflüssig.

SSIS-Schwachstellen: Warum das Verlagern der Packages in die Cloud nur die Altlasten mitnimmt

Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen

Petr Beles Petr Beles Co-Founder · Veröffentlicht in Lösungen für ETL-Tool-Herausforderungen LinkedIn

SSIS hat das SQL Server Warehouse zwanzig Jahre lang betrieben und hat den Bestand, der das belegt. Die Frage im Jahr 2026 ist nicht, ob man es verlässt, sondern wie, und die Standardantwort, eine VM oder eine Azure-SSIS Integration Runtime, die die Packages so ausführt, wie sie sind, verschiebt den Bestand, ohne eines der drei Dinge anzufassen, die ihn teuer machen.

Drei Probleme, die eine VM nicht löst

Lift and Shift trägt alle drei unverändert in die Cloud. Eine VM ist Infrastruktur, die Sie verwalten; die Azure-SSIS Integration Runtime ist ein verwalteter Cluster innerhalb der Data Factory mit einem Stundenpreis. Die Packages sind auf beiden dieselben Packages. Microsofts eigenes Ziel, Fabric Data Factory, ist eine neue Zeichenfläche, und das bedeutet, den gesamten Bestand von Hand neu aufzubauen.

Das Problem nicht in der Cloud nachbauen

Eine Migration ist der Moment, in dem ohnehin alle bestehenden Strukturen auf den Prüfstand kommen. Wer ihn nur nutzt, um von Hand gebaute Loads neu zu hosten, kommt in der Cloud wieder mit einem Package pro Tabelle an, mit einem Merge-Problem und mit einem Design, das weiterhin bei einer Plattform aufhört. Ihn auf ein Modell zu verwenden heißt:

  • Schneller migrieren. Quellen werden über ihre Business-Keys gemappt, nicht Package für Package übersetzt. Die alten Packages laufen weiter, bis jede Quelle gemappt ist, es gibt also keinen Big-Bang.
  • Weniger Probleme danach. Keine handgeschriebene Historisierung, kein Package, das nur sein Autor versteht, keine Umgebungs-Mapping-Tabelle. Die generierten Ladelogiken folgen einer einheitlichen Struktur.
  • Zukunftssicher. Dasselbe Modell generiert für SQL Server, Azure SQL und Fabric, und für Snowflake, Databricks oder BigQuery, falls diese Entscheidung je getroffen wird. Der nächste Plattformwechsel ist ein Zielwechsel.

Was sich mit Datavault Builder ändert

Datavault Builder hält das Warehouse in einem visuellen Modell und generiert daraus die Staging, Vault und Auslieferungs-Loads, mit Deployment, Rollback, Dokumentation und Lineage, nativ auf SQL Server, Azure SQL und Fabric.

  • Packages werden stillgelegt, nicht neu gehostet. Jede gemappte Quelle ist ein Package, das keinen Server mehr braucht, on premises oder in Azure.
  • Releases werden generiert, Rollback inklusive. Ein Vergleich zweier Zustände, die Unterschiede, die Sie wählen, und die für jeden vorgeschlagenen Abhängigkeiten. Keine .ispac, keine SSISDB Mappings.
  • Loads laufen in der Engine. Mengenbasiertes Delta-SQL in SQL Server oder Fabric. Keine ETL-Engine, kein Data-Flow-Buffer, keine zusätzliche Lizenz.
  • Quellen verbinden sich direkt. Batch, Delta und CDC aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka als Micro-Batches.
  • Die Plattform bleibt Ihre Wahl. Modernisieren Sie das ETL jetzt auf SQL Server, wechseln Sie das Ziel nach Fabric, wenn Sie bereit sind, und halten Sie die Tür zu jedem anderen Warehouse offen.

Wo Sie anfangen

Erstellen Sie zwei kurze Auswertungen: Die Packages, die nur eine Tabelle ins Staging oder ins Warehouse laden, und die Packages, deren Ziel die Plattform ist, die umzieht. Die erste ist das, was ein Modell generieren sollte. Die zweite ist das, was der Lift unverändert mitnehmen würde. Beginnen Sie dort, wo sie sich überschneiden. Wenn die Packages bereits auf einer Azure-SSIS Integration Runtime laufen, legen Sie deren Node-Stunden pro Monat neben die zweite Liste. Das ist der Preis dafür, Ihre technischen Schulden zu konservieren.

Erleben Sie es live mit Ihren eigenen Datenquellen

Buchen Sie eine kostenlose Demo und bringen Sie den Connector mit, der Sie am meisten kostet, an Geld oder an Zeit.

Kostenlose Demo buchen

Wie Datavault Builder die Reibungsverluste in der Ingestion beseitigt

  • Ingestion ist eingebaut

    Batch-, Delta- und CDC-Ladevorgänge aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen. Dieselbe Plattform, die das Warehouse generiert, keine zweite Rechnung.

  • Ihr Schema, nicht das des Anbieters

    Quelltabellen werden auf ein Data-Vault-2.0-Modell gemappt, das Sie entworfen haben. Eine neue Spalte oder eine umbenannte Tabelle ändert ein Mapping, keine Kette von Skripten nach dem Load.

  • Nur Deltas bewegen sich

    Hubs, Links und Satelliten laden, was sich geändert hat. Vollständige Ladevorgänge bleiben im Staging, statt jede Nacht weiter unten neu verarbeitet zu werden.

  • Historie wird von Haus aus behalten

    Jede Änderung wird so festgehalten, wie sie eintrifft. Historien- und Stichtagsabfragen funktionieren also auch dort, wo die Quelle ihre eigenen Zeilen überschreibt.

  • Code, den Sie nie von Hand schreiben

    Laden, Historisierung und Lineage werden in Echtzeit aus dem Modell generiert und laufen nativ auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.

  • Eine Plattform, bis zu neun Tools weniger

    Modellierung, ETL, CI/CD, Dokumentation und Lineage an einem Ort. Das ist es, was 14,7 Minuten von der Anforderung bis zur Produktion möglich macht.

Ausgezeichnet von BARC im Data Fabric Survey 26

Sprechen Sie mit unserem Experten

Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrem Stack passt.

Matt Collett

Matt Collett

Sales Director

Was suchen Sie?

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Weitere Probleme in dieser Serie

  • Jenseits von SQL Server

    Stößt SSIS dort an seine Grenzen, wo Ihr Cloud-Warehouse beginnt?

    SSIS wurde gebaut, um Daten zwischen On-Premises SQL Server Instanzen zu bewegen. Wenn das Warehouse nach Fabric, Snowflake, Databricks oder BigQuery umzieht, sind die Optionen, die Packages auf eine Azure-SSIS Integration Runtime zu heben, Drittanbieter-Connectoren zu kaufen oder neu zu schreiben. Ein Modell, das nativ für die neue Plattform generiert, ist die vierte Option, und die einzige, die Ihre Altlasten nicht mitschleppt.

  • Deployment und CI/CD

    Ist SSIS der letzte Teil Ihres Stacks, der sich CI/CD verwehrt?

    Eine .dtsx Datei ist XML, das sich schlecht vergleichen und noch schlechter mergen lässt, arbeiten zwei Engineers an einem Package, endet das im Neuaufbau. Umgebungen leben in von Hand gepflegten SSISDB-Variablen-Mappings. Moderne DevOps-Praxis stößt beim SSIS-Projekt an ihre Grenzen. Releases sollten aus einem Modell generiert werden, pro Umgebung, mit dem Rollback inklusive.

  • Package-Altlasten

    Gibt es mehr SSIS-Packages als Entwickler, die sie noch durchschauen?

    Hunderte .dtsx-Packages, eines pro Tabelle, jedes in Visual Studio gebaut von dem, der gerade das Ticket hatte, mit Control-Flows und Data-Flows, die sich nur einzeln öffnen lassen. Um eine Spalte zu ergänzen, müssen Sie die Packages eines nach dem anderen öffnen. Die Lösung ist kein Package-Template, sondern ein Modell, das die Loads generiert, nativ auf SQL Server, Azure SQL oder Fabric.

Fragen und Antworten