Home / Databases / SQL Server

DatabasesHow-toIntermediate

Move SSIS packages to Azure: Azure-SSIS Integration Runtime in Data Factory

Lift existing SSIS packages into Azure Data Factory with the Azure-SSIS Integration Runtime. Covers SSISDB on Azure SQL MI or Database, package deployment, connecting to on-premises sources, custom components, scheduling and cost control, plus when to rebuild instead.

Deepak Bhardwaj3 min read

Applies toSQL Server Integration Services 2012+ packages; Azure Data Factory, Azure SQL MI / Azure SQL Database

1. Lift or rebuild?

Situation Approach
Hundreds of working packages, tight timeline Lift to Azure-SSIS IR
A few simple copy packages Rebuild as native ADF pipelines
Heavy transformations, moving to a lakehouse Rebuild in Databricks / Fabric / dbt over time

Most programmes lift first, then rebuild the heavy or problematic packages later.

2. Create the Azure-SSIS IR

ADF → Manage → Integration runtimes → New → Azure-SSIS:

  • Location: same region as the SSISDB server and data.
  • Node size and count (start with D4-class, 2 nodes; scale later).
  • Edition: Standard or Enterprise (needed for some advanced components).
  • SSISDB: hosted on Azure SQL Database or Azure SQL MI (if you're moving databases to MI anyway, put SSISDB there).
  • Virtual network join if packages access on-premises or private-endpoint data sources.
  • Azure Hybrid Benefit for the SQL licence if you have SA.

3. Deploy packages

  • Project deployment model: deploy .ispac to SSISDB on Azure with Visual Studio (SSIS projects extension) or ISDeploymentWizard.exe.
  • Package deployment model (file system): store packages in Azure Files and run them from there, or convert to project deployment.
ISDeploymentWizard.exe /Silent /SourcePath:"C:\build\SalesETL.ispac" `
  /DestinationServer:"sqlmi-prod.abc123.database.windows.net" /DestinationPath:"/SSISDB/ETL/SalesETL" `
  /AuthenticationType:"ActiveDirectoryPassword" /User:"deploy@contoso.com" /Password:"..."

4. Connections and credentials

  • On-premises sources: VNet-joined IR over VPN/ExpressRoute, or configure the self-hosted IR as a proxy for the Azure-SSIS IR.
  • Replace Windows integrated security with Entra ID / managed identity where targets support it; store secrets in Key Vault and use environments/parameters.
  • File shares → Azure Files (mount with cmdkey in the setup script).

5. Custom components and drivers

Use a custom setup script (main.cmd in a Blob container) to install third-party components, ODBC/Oracle drivers, or certificates on IR nodes at start-up.

6. Scheduling

  • Replace SQL Agent schedules with ADF pipelines using the Execute SSIS Package activity and triggers.
  • Or keep SQL Agent on Azure SQL MI, which can run SSIS packages on the Azure-SSIS IR.

7. Cost control

The IR bills while it runs. Start it before the batch window and stop it after, from an ADF pipeline (web activity calling the ARM API) or Azure Automation.

8. Test

Run each package against test data on the IR; compare row counts and run times with on-premises. Watch packages that used local temp folders, xp_cmdshell, or mapped drives — they need changes.

Tip

Before the big lift, deploy every project to a test SSISDB on a small IR and run each package once. Packages that use local paths, xp_cmdshell, Windows-only drivers or unsupported components show up immediately, and fixing them before the move saves days of troubleshooting.