Lift-and-Shift to Azure
The packages keep working the way they work today. That is the point.
When the SQL Server instance has to move and the packages are fine, the cheapest good answer is to take the packages with you unchanged. SSIS still ships inside SQL Server, and the Azure-SSIS integration runtime has been generally available for years. A rewrite that adds no capability adds only risk.
Where the packages land
Azure-SSIS integration runtime, provisioned in Azure Data Factory, with the SSISDB catalog hosted on Azure SQL Database or SQL Managed Instance. Packages are invoked from Data Factory pipelines, or from SQL Agent where the catalog is on Managed Instance.
SQL Managed Instance where the surrounding estate — SQL Agent jobs, linked servers, cross-database queries, CLR — matters as much as the packages do.
Which one is right is an assessment answer, not a preference. It usually turns on what else lives on the instance besides SSIS.
What the work actually is
Resolving blockers. This is the majority of the effort and the part assessment tooling does not do.
- Third-party and custom components installed onto the integration runtime nodes through a custom setup.
- 32-bit-only providers — most often the Access Database Engine driver behind an Excel or Access source — either installed on the runtime or replaced.
- On-premises sources reached through a self-hosted integration runtime configured as a proxy, or through a network path into your environment.
- Protection levels: packages encrypted with a departed user's key have their credentials re-entered once and re-homed into parameters and Key Vault.
Migrating the SSISDB catalog. Either a redeploy of the .ispac projects or
a backup and restore, depending on whether the catalog's database master key
password can still be found. The two routes keep different things; we
write about the trade-off in detail,
and it is one of the first questions we ask.
Re-mapping schedules. SQL Agent jobs become schedule, tumbling window or event triggers, with the step chains preserved as activity dependencies. The behaviour change that catches people is overlap: SQL Agent will not start a job that is already running, and a Data Factory schedule trigger will. We find the jobs that actually overlap today and interlock them explicitly.
Parallel running. Both estates load the same days into two places, and we reconcile row counts, column sums and NULL counts per table per day, automated into the pipeline rather than into a spreadsheet. We do not sign off a cutover without a clean run that spans a month-end.
Cutover. Scheduled with the batch window, with the old estate left readable but not running for one more cycle.
What we do not do here
We do not rewrite packages during a lift-and-shift, even the ugly ones. Mixing a platform move with a logic change makes a reconciliation difference impossible to attribute, and attribution is the entire value of the parallel run. Packages that deserve rewriting are a separate, later engagement with its own verification.
Cost control afterwards
An Azure-SSIS integration runtime bills for the time its nodes are running, not for the packages you execute. Most estates run in a nightly window and should not have a runtime up at noon. Start and stop schedules, node sizing and the parallel-execution settings are part of the handover, not an afterthought — and they are the difference between a migration that saves money and one that quietly does not.
Where it starts
With an estate assessment, or with yours if you already have one. Engagements are billed hourly; scope and timeline are agreed in an initial conversation.