SSIS の課題：クラウドへのリフト＆シフトは問題ではなく負債を移動させているだけ

SSIS は 20 年間にわたり SQL Server データウェアハウスを支え続け、その長大な歴史に見合う膨大な資産（エステート）を築き上げました。2026 年における真の論点は「SSIS から移行すべきかどうか」ではなく「どのように移行するか」です。しかし、多くの現場で選ばれているデフォルトの回答、すなわちクラウド VM や Azure-SSIS Integration Runtime 上でパッケージをそのまま動かし続ける「リフト＆シフト」は、高コストを生み出している根本的な問題を何一つ解決しないまま、ただ資産の置き場所を変えているに過ぎません。

クラウド VM でも解決しない 3 つの課題

• パッケージ負債： 何世代もの開発者によってテーブルごとに作られた何百ものパッケージがあり、Visual Studio で 1 つずつ開くことしかできません。詳しくは パッケージ負債に関する記事をご覧ください。
• デプロイの破綻： マージ不能な XML、手作業で管理される SSISDB の環境変数マッピング、初回ジョブ実行まで成否が分からないリリース体制がそのまま続きます。詳しくは デプロイと CI/CD に関する記事をご覧ください。
• プラットフォームの壁： SQL Server 間でのデータ移動に特化して設計されているため、他のクラウドプラットフォームへ接続するには高価なコネクタか、巨大なサーバーか、全面的な書き直しが必要です。詳しくは SQL Server の限界に関する記事をご覧ください。

リフト＆シフトは、これら 3 つの課題をそっくりそのままクラウドへと運び込みます。VM は自前で管理するインフラであり、Azure-SSIS Integration Runtime は時間課金されるマネージドクラスターです。どちらを選んでもパッケージ自体の問題はそのままです。また、マイクロソフトの次世代プラットフォームである Fabric Data Factory への移行も、新しいキャンバス上で手作業による再構築を強いられることに変わりはありません。

クラウド上で問題を再生産してはならない

データウェアハウスの移行は、システム全体をゼロベースで見直すことができる唯一無二の絶好の機会です。その貴重なリソースを手作業のロード処理の再ホストに費やしてしまえば、テーブルごとの個別パッケージ、マージ競合、単一プラットフォームへの縛りをクラウド上でも抱え続けることになります。一方で、データモデルを中心とした移行を選択すれば、以下の劇的なメリットが得られます。

• 圧倒的に迅速な移行： ソースのビジネスキーから直接モデルへマッピングするため、パッケージを 1 つずつ書き直す必要はありません。古いパッケージを動かしたまま段階的に移行できるため、ビッグバン移行のリスクを回避できます。
• 移行後のトラブル激減： 手書きの履歴保持ロジック、作成者しか読めないパッケージ、煩雑な環境マッピングテーブルは一掃されます。自動生成されるロード処理はすべて均一な構造に保たれます。
• 将来の変化に強いアーキテクチャ： 同一のモデルから SQL Server、Azure SQL、Fabric だけでなく、将来 Snowflake、Databricks、BigQuery が選ばれた場合でもネイティブコードを自動生成できます。プラットフォームの変更は単なるターゲット設定の変更に過ぎなくなります。

Datavault Builder による変革

Datavault Builder は、データウェアハウスをビジュアルなモデルとして一元管理し、ステージング、Vault、配信ロードを、デプロイ、ロールバック、ドキュメント、データリネージとともに、SQL Server、Azure SQL、Fabric 上でネイティブ自動生成します。

• パッケージを再ホストするのではなく、計画的に退役： モデルにマッピングされたソースから順にパッケージを退役させ、サーバー資源を解放します。
• ロールバックを含むリリーススクリプトの自動生成： 2 つの状態の差分からリリースが生成され、依存関係も自動解決されます。.ispac や SSISDB の手動マッピングは不要です。
• データベースエンジン内でのネイティブ実行： ターゲットエンジンに最適化された差分 SQL を実行します。中間 ETL サーバーも、バッファメモリの制限も、余計なライセンスも不要です。
• 多様なデータソースへの直接接続： データベース、ファイル、REST API、NoSQL、Python ソース、Kafka ストリームからのロードに対応します。
• 将来にわたる選択の自由： まずは SQL Server 上で ETL を近代化し、準備が整った段階で Fabric へターゲットを切り替えるなど、柔軟な移行計画を実現できます。

何から始めるべきか

まずは 2 つのリストを作成してください。1 つ目は、1 つのテーブルをステージングやウェアハウスにロードするためだけに存在しているパッケージのリストです。2 つ目は、移行対象のクラウドプラットフォームをターゲットにしているパッケージのリストです。前者は「モデルから自動生成すべき領域」であり、後者は「クラウドへの単純載せ替えで負債化する領域」です。まずはこの 2 つが重なる領域から着手してください。すでに Azure-SSIS Integration Runtime を利用している場合は、その月額コストを横に書き添えてみてください。それこそが、技術的負債を温存するために支払っている対価です。