SSIS Run and Maintain

For estates that work, and that nobody currently owns.

The most common SSIS situation is not a migration. It is an estate that runs, that the business depends on nightly, and that nobody on the current team wrote. It keeps working until a source system changes a column, and then it is everyone's problem for two days.

What we cover

Nightly failure triage. A package fails, we find out why, and we fix it — rather than rerunning it and hoping. Most failures in a mature estate are schema drift, a source that was late, or a credential that expired, and all three have a real fix rather than a retry.

Performance tuning. Packages and the queries inside them: the data flow that is slow because of a blocking transformation, the lookup running in full-cache mode against a table that has grown, the OLE DB destination doing row-by-row inserts, and the source query that has needed an index since a schema change two years ago.

Schema-drift fixes. A source adds a column, changes a type, or renames something, and metadata-validating packages stop. We fix the package and, where it is worth it, make the pattern resistant to the next change.

Upgrade and patch work. SQL Server and integration runtime upgrades, component and driver updates, and the compatibility checking that goes in front of them.

Documentation. What each job actually does, what it depends on, what it loads, and how to debug it when it stops. This is the deliverable that ends the dependency on us, which is the point of it.

How it is staffed

Hourly time and materials, as a project engagement or as staff augmentation alongside your team. Staff augmentation is common here: a senior SSIS engineer working inside your process, your repository and your ticket queue, for as much or as little of the week as the estate needs.

Every engineer is senior and US-based, and works in your SSISDB and your SQL Agent rather than in a copy of them.

What we do not do

We do not use a maintenance engagement as a channel for a migration. If the estate is fine, the honest recommendation is that it stays fine and the engagement stays small. If something in it genuinely should move or be rebuilt, we will say so with the packages named — and you are free to have someone else do that work.

Where it starts

Usually with a short read of the estate: the job history, the failure pattern, and the packages that account for it. That is often enough to make the first month useful. Tell us what is breaking.

Tell us roughly how many packages you have, what version of SQL Server they run on, and what is prompting the move. A senior engineer replies within one business day.
Talk to an engineer