Selective Rewrite to ADF or Microsoft Fabric

Some packages should be rewritten. Most should not. The work here is telling the two apart and then doing the first group properly.

Which packages earn a rewrite

• It fails often enough to be on someone's calendar.
• It is the long pole in the nightly batch, and the batch window is under pressure.
• It changes every quarter, so its maintenance cost is real and recurring.
• It does something the target platform does much better: an incremental load that should be a tumbling window trigger, a Foreach Loop over a landing folder that should be a storage event trigger, a Slowly Changing Dimension transformation that should be a MERGE.

Notice what is not on that list: age, and ugliness. A package that runs in four minutes, has not been edited since 2019, and has never woken anyone up does not need rewriting, however unpleasant the data flow looks when you open it.

What we build

Metadata-driven pipelines, not a package-shaped translation. A hundred near-identical extract packages become one parameterised pipeline and a control table — which is the actual win, and the reason a rewrite is worth doing at all when it is worth doing.

Restartability. Activity-level retry, idempotent loads, and rerun from the failed activity, so a transient failure at 02:00 is not a person's morning.

Logging and alerting that someone reads. SSISDB execution reports do not travel to Data Factory. We rebuild the operational view your team actually uses — what ran, what it loaded, what it cost, what failed and why — rather than leaving you with a run history and a hope.

Retirement of dead flows. Packages whose output nothing consumes are switched off, not ported. This is usually the largest single saving in the project.

Data Factory or Microsoft Fabric

Azure Data Factory is the settled choice: generally available for years, with the Azure-SSIS integration runtime alongside it for the packages that are staying. Microsoft Fabric is where new platform investment is going, and its pipeline service shares most of Data Factory's vocabulary — but the path for existing SSIS packages there is newer and less settled.

We will tell you which one fits, including when the honest answer is "not yet" for part of the estate. We are not paid by the platform.

How it is verified

The same way a lift-and-shift is: both versions load the same days, reconciled on row counts, column sums and NULL counts, with every expected difference signed off by name in advance. A rewrite that fixes a bug in the old package produces a difference, and an unexplained difference and an approved difference look identical in a diff — so we write them down.

Verification cost belongs in the estimate next to build cost. For a package feeding a regulatory submission it is frequently the larger number, which is often the reason such a package should be moved as-is instead.

What happens to the rest

It stays on SSIS, running on the Azure-SSIS integration runtime or where it already is, and we will keep it running if you want us to. A partly rewritten estate is a normal, healthy end state, not an unfinished project.