SSIS migration, run by an agent fleet.

What the Documenter reads

An SSIS package is an XML document on disk, but the Documenter doesn’t stop at the element names. The whole point of the assessment gate is to read the logic a package encodes, not just the labels Visual Studio gave it. A .dtsx file describes control flow, data flows, connection managers, variables, parameters and configurations; an .ispac bundles the project’s packages plus a manifest and parameter definitions. We parse both, then reconstruct what actually runs.

Two engines, documented separately

A package has two layers that execute on different engines, so the Documenter treats them as two graphs. The control flow is the orchestration layer: tasks such as Execute SQL Task, Script Task, Data Flow Task and Execute Package Task, plus Sequence, For Loop and Foreach Loop containers that each hold their own nested control flow. The Data Flow is the in-memory ETL pipeline, and it only exists inside a Data Flow Task, with its own instance of the data-flow engine per task. Reading them together would lose the seam where orchestration hands off to row-by-row processing.

Precedence constraints are the logic, not decoration

The edges of the control-flow graph are precedence constraints, and their properties carry the branching logic. The Documenter captures the value (Success, Failure, or Completion), the EvalOp (Constraint, Expression, Expression and Constraint, or Expression or Constraint), and the LogicalAnd flag that decides whether multiple incoming constraints are AND-ed or OR-ed. That last flag is the crux of merge logic: “run Task D only if A succeeded AND B failed AND C succeeded” is invisible unless you read it. Packages are never linked by precedence constraints, so cross-package orchestration is followed through the Execute Package Task instead.

Inside the Data Flow

A data flow is sources, transformations and destinations connected by paths. The Documenter records which transformations are synchronous (row-by-row, reusing the buffer, like Derived Column or Conditional Split) versus asynchronous (blocking or semi-blocking, like Sort, Aggregate or Merge Join), because the asynchronous ones are the performance pivot points and the ones whose buffer-based semantics (sorted inputs, error outputs, lineage-tracked columns) must be reproduced as set-based SQL or Spark transformations where there is no row-buffer model.

Expressions, variables and scope

SSIS has its own expression language, C-like rather than T-SQL, used in precedence constraints, derived columns, conditional splits, the For Loop container and property expressions. The Documenter resolves these because they dynamically set properties at runtime. It also records the things that bite on rebuild: variable names are case-sensitive; variables carry scope and can be EvaluateAsExpression = True; the User and System namespaces resolve with ::; and the evaluator never implicitly converts to Boolean, with True represented as -1 in the Visual Basic convention. Parameters are followed through their design default, server default and environment-reference chain in the SSISDB catalog.

The two highest-risk constructs

Two things are read with extra care because they hide business logic. Script Tasks and Script Components are .NET code in a ScriptMain class, reached through the Dts object and the ReadOnlyVariables / ReadWriteVariables lists; they have no declarative equivalent and must be re-implemented. Dynamic SQL (an Execute SQL Task with SQLSourceType = Variable, or a statement built in a Script Task) is not present statically, so the Documenter traces the variable construction to recover what executes. Both are surfaced at the assessment gate, before the build-test-run loop begins, so the effort is accountable up front.