The problem no one sees coming
Your SSIS estate works. Jobs run overnight, tables are populated, reports are generated. But does anyone truly know what is happening inside those packages?
The scenario is classic. An SSIS package fails in production. Nobody remembers who wrote it. The documentation is outdated or nonexistent. The fix takes days instead of hours.
This scenario is not hypothetical. It's one of the most common reasons companies contact us. And every time, the same finding: the problem is not Friday night's bug. The problem is that nobody had visibility into what the estate actually contained — which flows were critical, which were dead, where the dependencies lay.
What an automated audit reveals
When we scan an SSIS environment for the first time, we typically find that 30-40% of packages are dormant — they exist in the repository but haven't been executed in months or years.
Ghost packages
These are SSIS packages that sit in the directory, take up space, create confusion, and occasionally trigger false alerts. Nobody dares delete them because nobody knows if they are still needed.
Invisible dependencies
Package A feeds a table that is read by package B, which writes to a view consumed by a Power BI report. Change one link in this chain without understanding the full picture, and you risk cascading failures.
Rogue connections
Hardcoded connection strings with a server name that changed three years ago. Variables that reference paths on a developer's local machine. Configurations that only work on one specific SQL Agent job.
The absence of error handling
An SSIS package without an Event Handler is a package that fails silently. And in most estates we audit, error handling is inconsistent at best.
The reverse-engineering approach
The traditional estate audit relies on team interviews and manual code review. It's slow (2-4 weeks for 200 packages), subjective (the consultant sees what they're looking for, not what they don't know) and incomplete (nobody reads 500 XML files end to end).
The reverse-engineering approach is different. The Decinova scanner opens each DTSX file, parses its proprietary XML structure, and automatically extracts all information: sources, destinations, transformations, variables, event handlers. No manual documentation needed, no interpretation, no omissions.
The result is a 20 to 40-page report containing the complete flow map, dependency matrix, technical debt score, active vs dormant classification, and prioritised recommendations.
What’s the point of an audit if you don’t migrate?
A fair question — and the answer matters. The audit is not a commercial exercise. The report is yours regardless of what you decide to do next.
If you decide to maintain your SSIS estate, the audit becomes the foundation for structured maintenance: you know what exists, what is critical, and where the risks lie.
If you are considering migration, the audit is the only reliable way to estimate scope, complexity, and automated conversion potential.
In both cases, the first step is the same: understand what you have. Our free audit does exactly that, in 48 hours.