SSIS Pain Points: Why Lifting Packages to the Cloud Moves the Debt, Not the Problem

SSIS ran the SQL Server warehouse for twenty years and it has the estate to show for it. The question in 2026 is not whether to leave it but how, and the default answer, a VM or an Azure-SSIS Integration Runtime that runs the packages as they are, moves the estate without touching any of the three things that make it expensive.

Three problems a VM does not fix

• Package debt. Hundreds of packages, one per table, built by many hands, opened one at a time. See the article on package debt.
• Deployment. XML that merges badly, SSISDB environment mappings kept by hand, and releases that prove themselves on the first scheduled run. See the article on deployment and CI/CD.
• The platform edge. Built for SQL Server to SQL Server; anything else is a connector, a bigger server or a rewrite. See the article on SSIS beyond SQL Server.

Lift and shift carries all three to the cloud intact. A VM is infrastructure you manage; Azure-SSIS Integration Runtime is a managed cluster inside Data Factory with an hourly price. The packages are the same packages on either. Microsoft’s own destination, Fabric Data Factory, is a new canvas, which means rebuilding the estate by hand.

Do not recreate the problem in the cloud

A migration is the one moment when the whole estate is on the table anyway. Spending it on rehosting hand built loads means arriving in the cloud with a package per table, a merge problem and a design that still stops at one platform. Spending it on a model means:

• Faster to migrate. Sources are mapped from their business keys, not translated package by package. The old packages keep running until each source is mapped, so there is no big bang.
• Fewer problems afterwards. No hand-written historization, no package only its author understands, no environment mapping table. The generated loads have one shape.
• Future proof. The same model generates for SQL Server, Azure SQL and Fabric, and for Snowflake, Databricks or BigQuery if that decision is ever taken. The next platform move is a target change.

What changes with Datavault Builder

Datavault Builder holds the warehouse in a visual model and generates the staging, vault and delivery loads from it, with deployment, rollback, documentation and lineage, natively on SQL Server, Azure SQL and Fabric.

• Packages are retired, not rehosted. Each mapped source is a package that no longer needs a server, on premises or in Azure.
• Releases are generated, rollback included. A comparison of two states, the differences you choose, and the dependencies proposed for each. No .ispac, no SSISDB mappings.
• Loads run in the engine. Set based delta SQL inside SQL Server or Fabric. No ETL box, no data flow buffer, no extra license.
• Sources connect directly. Batch, delta and CDC from databases, files, REST APIs, NoSQL and Python sources, with streams such as Kafka as micro batches.
• The platform stays your choice. Modernize the ETL on SQL Server now, move the target to Fabric when ready, and keep the door open to any other warehouse.

Where to start

Two lists. The packages that only load one table into staging or the warehouse, and the packages whose target is the platform that is moving. The first is what a model should generate. The second is what the lift would carry across unchanged. Start where they overlap. If the packages already run on an Azure-SSIS Integration Runtime, add its node hours per month next to the second list. That is the price of preserving the debt.