Don't Rewrite SSIS. Read It.

Most cloud migration plans treat an existing SSIS portfolio as a liability to be liquidated. Hundreds of DTSX packages, years of business logic buried in derived columns and lookups, connection strings nobody fully documented. The standard advice is to rewrite all of it by hand in whatever the new target is: ADF pipelines, Databricks notebooks, Fabric. That is a multi-year project with a high chance of dropping logic on the floor, and it throws away work that already runs in production today.

‍

There is a different starting move. Instead of rewriting the packages, read them. BimlFlex can import your existing SSIS work, turn it into metadata, and let you regenerate that metadata against a modern target. The packages stop being a wall in front of the migration and become the input to it.

‍

Four ways in

‍

SSIS estates do not all live in the same place, so there is no single import path that fits everyone. Some teams have the original Visual Studio projects on a build server. Others only have the deployed artifacts. Plenty have nothing but the packages running inside the SSIS catalog on a production server, with the source long gone.

‍

BimlFlex covers all four of those situations. When you run the import, you pick the source that matches what you actually have:

‍

• DTProj from file system points at a Visual Studio integration services project on disk and pulls in the whole project.
• ISPAC from file system reads a deployed .ispac file, the packaged deployment artifact you would hand to a server.
• DTSX from file system takes one or more raw .dtsx package files directly, for when all you have is a folder of packages.
• Project from package catalog connects to a live SSIS catalog (server, catalog, folder, project) and reads the deployed project straight out of the database.

‍

That last option matters more than it looks. If the only surviving copy of a package is the one executing in production, you are not blocked. You point the importer at the catalog and it reads what is there. No hunting for a lost .dtproj, no rebuilding source from memory.

‍

You also get to control how much of the original package identity comes across: whether to preserve the original SSIS object names and IDs, whether to carry over annotations, and whether to bring in package-creation metadata. The goal is a faithful read, not a lossy approximation.

‍

Components, not just packages

‍

Reading a package shell is easy. The hard part of any SSIS importer is the inside of the data flow: the sources, destinations, and transforms, each with its own column mappings, expressions, and component-specific properties. A migration tool that only understands a handful of common components leaves you to hand-rebuild everything else, which defeats the point.

‍

BimlFlex round-trips a broad catalog of data flow components. The translation layer covers the SSIS source types you would expect (OLE DB, ADO.NET, ODBC, Oracle, Excel, Flat File, Raw File, XML), the matching destination types, and a deep set of transforms: Lookup, Merge Join, Conditional Split, Derived Column, Data Conversion, Aggregate, Sort, Union All, Pivot, Multicast, Slowly Changing Dimension, and many more. The long tail is covered too, including Fuzzy Lookup, Fuzzy Grouping, Term Extraction, CDC Splitter, and the Balanced Data Distributor.

‍

The point is not the length of the list. It is that the components carrying your business logic come across as structured metadata rather than as something you reverse-engineer by eye. A Conditional Split keeps its conditions. A Derived Column keeps its expressions. A Lookup keeps its join and its output columns. When the data flow is metadata, you can see it, query it, diff it, and regenerate it.

‍

The cloud paths come too

‍

A frequent objection: an SSIS portfolio is on-premises, so importing it just gets you on-premises logic back. That holds only if the importer is stuck in the 2012 world.

‍

It is not. The component coverage includes the Azure and big-data connectors that modern SSIS packages already use: Azure Blob sources and destinations, the Flexible File source and destination, HDFS file source and destination, and Azure Data Lake Store. When the importer sees an Azure Data Lake connection in a package, it recognizes it and translates it rather than dropping it. So if your team already started moving toward cloud storage inside SSIS, that work imports cleanly instead of being treated as an unknown.

‍

That is the bridge that makes this an on-ramp and not just an archaeology exercise. Your existing packages, including the parts already reaching into ADLS Gen2, come in as metadata. From there the migration question changes shape. It is no longer "how do we hand-rewrite this for the cloud." It is "we have the model, now which target do we generate."

‍

From package to model to target

‍

Once a package is metadata, BimlFlex treats it the way it treats any model: as the single source of truth that drives generation. The same model that came out of your SSIS import can be pointed at a different runtime and regenerated. This is the regenerate-don't-port principle BimlFlex applies across targets, and the SSIS importer is what gets a legacy estate into that model in the first place.

‍

This is why "read it" beats "rewrite it." A rewrite produces a one-time artifact that immediately starts drifting from the original. An import produces a model. The model is durable. You can keep generating SSIS from it while you plan, then regenerate the same logic for Azure Data Factory when you are ready to move, and the output is code you own on your stack.

‍

The model also gives you somewhere to do the cleanup that every migration needs. Packages accumulate cruft: dead branches, duplicated logic, naming that drifted over a decade. As metadata, that is visible and editable in one place instead of buried across hundreds of XML files. If you have read our take on authoring with templates for schema drift, SCDs, and orchestration, the same leverage applies here: once the estate is metadata, you design forward instead of patching XML.

‍

Where this fits a migration

‍

A cloud move usually has a discovery phase nobody enjoys, where someone reads through old packages to figure out what they do before anything can be planned. Importing the estate front-loads that. You get an inventory of every package as a model: every source, every destination, every transform, every connection, laid out as metadata you can actually read.

‍

That changes the risk profile of the whole project. We have written before about the benefits, risks, and automation shortcuts of cloud data warehouse migrations; the single biggest risk in any of them is silently losing logic in the rewrite. Importing instead of rewriting attacks that risk at the root. The logic is not retyped from a screenshot. It is read from the package and carried into the model, where you can verify it.

‍

None of this is magic, and it is worth being honest about the boundary. Custom script components and exotic third-party components are exactly that, custom, and they need a human to decide what the cloud equivalent should be. But the 80 percent that is standard sources, standard destinations, and standard transforms is the part that makes a hand-rewrite slow and error-prone, and that is the part the importer handles. If the idea of treating the platform model as the source of truth is new to you, the first principles of metadata-driven automation are the place to start.

‍

Your SSIS portfolio is not the obstacle to your cloud migration. Read correctly, it is the head start.