SSIS Estate Assessment
Every package read, classified, and put in order of risk.
An SSIS estate is usually described in round numbers — "about four hundred packages" — and the round number is where planning stops. An assessment replaces it with a list.
What we inventory
- Every package: control flow and data flow components, precedence constraints, event handlers, checkpoints, transactions, and protection level.
- Every connection manager: what it points at, whether the target still exists, which credential it carries and where that credential lives.
- Every Script Task and Script Component: what the code actually does, and whether it is a string cleanup, a real algorithm, or something that has been dead since a source system was retired.
- Every third-party and custom component: vendor, version, licence, and whether a path exists on the target platform.
- Every SSISDB project, folder, environment and environment reference, including the parameter values that are the real configuration of the system.
- Every SQL Agent job with an SSIS step: schedule, step chain, on-failure actions, proxy accounts, notification operators, and observed run times from the job history.
What we work out from it
Dependencies and lineage. Which packages feed which tables, which tables feed which reports, and which jobs are waiting on a clock rather than on each other. This is where the estate's real shape appears, and it is usually not the shape on the diagram.
Blockers. Third-party components with no target equivalent, 32-bit-only providers, data sources with no network path from the destination, and packages encrypted with a user key belonging to somebody who has left. Assessment tooling reports most of these. We cost the resolution of each one.
A classification per package. Retire, lift-and-shift, or rewrite, with the reason recorded next to it. Retire is consistently larger than teams expect: loads that feed tables nothing has read in a year are common in any estate that has outlived a reporting platform.
A risk register. Ranked by what happens if it fails and how likely that is, not by how old the code is.
What you get
A document with a row per package and a defensible answer in the last column, a sequenced migration plan with the retire list first, the risk register, and a walkthrough session with the engineers who did the work.
It is written to be executable by your own team. If you would rather we executed it, lift-and-shift and selective rewrite pick up where it stops — but the assessment stands on its own, and it is deliberately the kind of document you can take to a vendor who is not us.
How long it takes
It depends on estate size and how much of the SSISDB catalog is still intact. The shape of the work is: extract and parse the packages, read the catalog and job history, interview the people who still know things, then classify. Scope and timeline are agreed in an initial conversation, and the work is billed hourly.
Doing it yourself
You can, and some teams should. The inputs are the .dtsx files,
catalog.executions, msdb.dbo.sysjobhistory, and a fortnight of someone
senior's undivided attention. Our
decision checklist is the same
one we apply. If the fortnight is not available, that is what we are for.