Last updated June 15, 2026 by Errin O'Connor, Founder & Chief AI Architect, EPC Group
Published 2026-06-15
SSIS to Fabric Data Factory migration in 2026 follows a six-phase enterprise methodology: Inventory, Classification, Architecture, Conversion, Validation, and Cutover. Realistic auto-conversion accuracy is 40-60% on production portfolios; the rest refactors manually. Fabric Data Factory — not standalone Azure Data Factory v2 — is the Microsoft-recommended target.
Key Facts
- SSIS is in long-term maintenance mode; Microsoft platform investment is in Fabric Data Factory, which ships new capability monthly.
- Realistic auto-conversion accuracy on a production SSIS portfolio is 40-60% — not the 70-90% vendor marketing cites. Plan budget for manual refactor on the rest.
- Four viable target architectures: Fabric Data Factory (default for ~70-80%), ADF v2 standalone (~15%), Synapse Pipelines (existing Synapse footprints only), Azure-SSIS Integration Runtime (5-10% lift-and-shift for hard deadlines).
- Effort sizing: low-complexity packages refactor in 12-24 hours; medium 24-60 hours; high 60-180 hours. Script Tasks are the single largest overrun driver.
- Parallel-run / parity window: 2-4 weeks for daily pipelines, 4-8 weeks for weekly, 2 full cycles for monthly. Regulated workloads add one extra cycle for compliance sign-off.
- EPC Group has executed 11,000+ Microsoft engagements, 216+ M&A tenant consolidations, and 6,500+ implementations — the operational depth behind this playbook.
- Microsoft Solutions Partner with six designations, 29 years in business, 70+ Fortune 500 clients.
- Errin O'Connor — Founder, Chief AI Architect, original Power BI / Project Crescent beta team member, and Microsoft Press author — leads the senior-architect bench delivering these engagements.
The state of SSIS in 2026 — what is still supported and what is not
SQL Server Integration Services is one of the most-deployed ETL platforms in the world. The footprint inside most large enterprises is measured in hundreds to thousands of packages, written over a decade, scheduled by SQL Server Agent jobs, and feeding the warehouses that finance, operations, and compliance run on every day. SSIS has not stopped working in 2026 — and Microsoft has not announced an end-of-life date.
What has changed is the direction of Microsoft's platform investment. SSIS continues to ship inside SQL Server (SSIS is part of the SQL Server 2025 release), and the Azure-SSIS Integration Runtime inside Azure Data Factory remains the supported lift-and-shift path. But the volume of new feature work in SSIS has slowed to a trickle since 2023, while the equivalent capabilities in Microsoft Fabric — and specifically in Fabric Data Factory — ship every monthly release: new connectors, new Mapping Data Flow transformations, tighter Purview integration, Copilot-assisted authoring, native OneLake landing, deployment-pipeline-based promotion, and Spark-runtime alignment with the rest of Fabric.
The honest read: SSIS will run for years. It is in long-term maintenance mode, not active development. The right enterprise posture in 2026 is to (a) stop writing new SSIS packages, (b) inventory the existing portfolio, (c) plan a multi-quarter glide path to Fabric Data Factory, and (d) hold a small number of high-value, low-change SSIS packages in lift-and-shift on Azure-SSIS IR for as long as it costs less to run them than to refactor them. This page is the playbook for executing that posture at enterprise scale.
EPC Group has executed this kind of platform-modernization work across 70+ Fortune 500 environments, in HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP-regulated industries, and across 216+ M&A tenant consolidations where SSIS modernization sat directly on the critical path of the deal-close calendar. The methodology below is what we run.
A note on Azure Data Factory v2 versus Fabric Data Factory — because the naming generates real confusion in enterprise steering committees. Azure Data Factory v2 is the standalone PaaS data-integration service that has existed since 2018; it remains supported, ships incremental updates, and is the right target for a narrow set of pure-orchestration workloads with non-Fabric destinations. Fabric Data Factory is the Data Factory experience inside Microsoft Fabric — it shares pipeline constructs and connectors with ADF v2, but it runs on Fabric capacity, lands data into OneLake, and shares lineage, security, and Copilot integration with the rest of the Fabric platform. Microsoft is unambiguously steering net-new investment to Fabric Data Factory. The decision matrix below addresses the four viable targets — including when standalone ADF v2 is still the right call.
A further note on scope. This playbook is sized for enterprise portfolios of 50 to 1,000+ packages. The same methodology scales down for smaller estates but the proportions shift — small portfolios skip the wave model and run a single cutover window; very large portfolios (1,000+ packages) require a domain-by-domain rollout that takes 12-24 months and is best run as a managed program with a dedicated PMO. EPC has executed both shapes; the engagement models in Section 8 below describe the three packaged ways we enter.
Choose your destination — four target architectures compared
Before you classify a single package, decide which target architectures are in play. There is no "one right answer" at the portfolio level — most enterprises land on Fabric Data Factory as the default for the majority of the portfolio, plus a secondary target (lift-and-shift on Azure-SSIS IR) for a defined subset with hard deadlines or low-change profiles. The four viable options:
Fabric Data Factory
The Microsoft-recommended modernization path for new SSIS workloads in 2026. Data Factory in Fabric runs inside the Fabric capacity, lands data into OneLake (Delta-Parquet), and shares governance, lineage, and security with the rest of Fabric (Lakehouse, Warehouse, Power BI, Real-Time Analytics).
Best when: You want a single platform for ingestion, lakehouse, warehouse, semantic model, and BI. You are already standardizing on Fabric for analytics. You want OneLake-native lineage in Purview and Direct Lake semantic models on top of the same data.
Watch-outs: Not every SSIS construct has a one-for-one Fabric equivalent — script tasks, custom .NET components, and tightly-coupled SSIS package configurations require refactor work. Fabric capacity unit (CU) accounting differs from SSIS server licensing; you must size the F SKU correctly to avoid throttling.
Verdict: Default destination for new SSIS modernization work in 2026. Recommended for 70-80% of SSIS portfolios where the platform target is unified analytics on Microsoft Fabric.
Azure Data Factory v2 (standalone)
The mature, standalone PaaS data integration service that predates Fabric Data Factory. ADF v2 is still actively supported and remains the right choice for pure data movement workloads where Fabric capacity is not justified or where the destination is a non-Fabric store (Azure SQL DB, Cosmos DB, Snowflake, third-party SaaS).
Best when: Pure data movement / orchestration with no downstream lakehouse or semantic model. You are landing data into Azure SQL Database, Synapse Dedicated SQL Pools, Cosmos DB, or a non-Microsoft analytics platform. You need self-hosted integration runtime for on-premises connectivity without committing to Fabric capacity.
Watch-outs: You will eventually face the Fabric Data Factory question again — Microsoft is steering the platform investment toward Fabric. ADF v2 standalone makes sense for the next 24-36 months but plan for a second migration to Fabric DF if your analytics footprint moves to Fabric.
Verdict: Right choice for ~15% of SSIS portfolios — primarily pure-orchestration workloads with non-Fabric destinations or strict capacity-isolation requirements.
Synapse Pipelines
Synapse Pipelines are functionally identical to ADF v2 inside a Synapse workspace. As Microsoft formally guides new builds to Fabric (Synapse Dedicated SQL Pools remain available; Synapse workspace creation is being phased out), Synapse Pipelines is a viable target only for existing Synapse footprints not yet ready to migrate to Fabric.
Best when: You already have a heavy Synapse footprint with dedicated SQL pools and you want to keep ingestion co-located with those pools during the Synapse-to-Fabric coexistence window. New SSIS workloads in this scenario can land in Synapse Pipelines today and re-route to Fabric DF later.
Watch-outs: Synapse Pipelines is a stop-gap, not a destination. Any workload you build here in 2026 will need a second migration to Fabric DF when you sunset the Synapse workspace. Plan that work into the roadmap.
Verdict: Use only for existing Synapse customers in the coexistence window. Not a recommended greenfield destination.
Azure-SSIS Integration Runtime (lift-and-shift)
Runs your existing SSIS packages unchanged on a managed SSIS cluster inside Azure Data Factory. Packages remain in SSISDB; SSDT, dtutil, and the SSIS catalog still work. Zero conversion — you point the runtime at your existing SSISDB and packages execute as-is.
Best when: You have hundreds of mature, working SSIS packages, a hard deadline to retire on-premises SQL Server, and no capacity to refactor in this cycle. Lift-and-shift buys you 18-36 months to refactor on a schedule that suits the business.
Watch-outs: You inherit the SSIS programming model, the SSISDB lineage model, and the licensing-style cost of Azure-SSIS IR — which is more expensive per hour than Fabric DF. This option does NOT modernize; it relocates. Don't confuse Azure-SSIS IR with Fabric DF in vendor conversations — they are different products.
Verdict: Use for the 5-10% of the portfolio that is too expensive to refactor today but must move off the on-prem SQL Server. Plan a refactor pass on a later cycle — don't treat it as a permanent destination.
The six-phase SSIS to Fabric Data Factory migration methodology
This is the methodology EPC Group runs on every SSIS modernization engagement. It is the same shape regardless of portfolio size — what changes is the depth of each phase and the number of waves in Phase 6. The total program duration for a 200-500 package portfolio is typically 6-9 months end to end; for 500-1,000 packages, 9-15 months. The methodology maps directly to the The EPC Group Lifecycle: phases 1-2 are Assess, phases 3-4 are Modernize, phase 5 is the gate into Govern, and phase 6 hands the workload to Operate.
Phase 1: Inventory
Goal: Build the authoritative catalog of every SSIS package, every dependency, every schedule, and every consumer in scope. Nothing modernizes until it is inventoried.
Activities:
- Extract the SSISDB catalog (catalog.projects, catalog.packages, catalog.environment_references, catalog.executions) for every production SSIS server in scope — including disaster-recovery instances.
- Pull SQL Server Agent job metadata (msdb.dbo.sysjobs, sysjobsteps, sysjobschedules) and map each job step that calls dtexec or the SSIS subsystem back to the package.
- Pull file-system SSIS packages (.dtsx, .dtsConfig, .ispac) from any deployment that pre-dates the SSISDB catalog. These are often orphan packages running from scheduled tasks or third-party schedulers.
- Catalog every connection manager and parameter — package-level, project-level, and environment-level — so the credential migration plan is not invented at cutover time.
- Catalog every custom component, third-party add-in, and Script Task. These are the highest-risk conversion items and the first ones product owners forget about.
- Build the dependency map: source systems, sink systems, downstream consumers (Power BI semantic models, SSRS reports, downstream warehouses, regulatory feeds). This is the impact-analysis dataset for the rest of the program.
Artifact: SSIS Inventory Workbook + dependency graph (Visio / Mermaid / Purview export)
Typical duration: 2-4 weeks for a portfolio of 200-800 packages
Phase 2: Classification
Goal: For every inventoried package, decide between three exits: lift-and-shift, refactor, or retire. Bad classification is the single most expensive mistake in SSIS modernization — refactoring a package that should have been retired wastes a quarter; lift-and-shifting a package that should have been refactored locks in another 18 months of technical debt.
Activities:
- Run the package classification decision matrix (see scoring section below) over every package. Score complexity (low / medium / high), business value (active / dormant / candidate for retirement), and conversion readiness (high / partial / blocked).
- Sample-validate the inventory: pull 10-20 packages from each complexity bucket and have a senior data engineer confirm the score. Self-scoring by the original developers is unreliable — they over-estimate complexity to protect their work.
- Identify the retire-candidate set early. Most SSIS portfolios contain 10-20% of packages that have not produced output in 90+ days, have no living consumer, or duplicate functionality in another package. Killing these before the migration starts saves the full conversion cost on each.
- Identify the lift-and-shift set: packages that are too expensive to refactor today, have stable upstream sources, and have a hard cutover deadline. These land on Azure-SSIS Integration Runtime with no code change.
- Identify the refactor set: packages that have ongoing development, sit on a strategic data product, or feed a downstream Fabric workload. These land on Fabric Data Factory with a re-design.
- Lock the classification in a signed-off decision register. Re-classification mid-program is allowed; ad-hoc reclassification by individual engineers is not.
Artifact: Classification Decision Register (per-package: target architecture, owner, retire-by date, refactor-by date)
Typical duration: 3-6 weeks (overlaps Phase 1 for large portfolios)
Phase 3: Architecture
Goal: Design the target landing zone — Fabric workspace topology, OneLake medallion layout, capacity sizing, security model, and CI/CD pattern — before a single package is converted. Skipping this phase is how SSIS modernization programs run twice the budget.
Activities:
- Design the Fabric workspace topology: domain-aligned workspaces (Finance, HR, Sales, Operations) vs centralized data engineering workspace. The right answer depends on operating model — federated data ownership wants domain workspaces; centralized engineering wants a single ingestion workspace.
- Design the OneLake medallion structure: bronze (raw landing, schema-on-read), silver (cleansed and conformed, schema-on-write), gold (business-ready, semantic-model-friendly). Map each Fabric DF pipeline to the medallion zone it writes to.
- Size the Fabric capacity (F SKU). The right F SKU is a function of concurrent pipelines, peak CU consumption, and downstream Direct Lake / report load. Over-sizing wastes 30-40% of capacity spend; under-sizing causes pipeline throttling and missed SLAs.
- Design the security and identity model: workspace roles, OneLake security (item-level), Purview sensitivity labels, managed identities for source-system connections, and Key Vault references for secrets. Never migrate connection strings in clear-text — replace with managed identities or Key Vault references during conversion.
- Design the CI/CD pattern: Fabric Git integration on every workspace, deployment pipelines for dev → test → prod promotion, parameter overrides per environment. A program without CI/CD ships unrepeatable migrations.
- Design the observability stack: Fabric monitoring hub, Log Analytics export, pipeline-run alerting (Power Automate / Teams), and the on-call rotation. The day you cut over, the rotation has to be ready.
Artifact: Target Architecture Document (workspace topology, OneLake medallion, F SKU sizing, security model, CI/CD pattern, observability)
Typical duration: 4-6 weeks (runs in parallel with Phase 2)
Phase 4: Conversion
Goal: Convert each classified package into its target architecture. Use auto-conversion tooling where it produces clean output; refactor manually where it does not. Track every conversion as a working item with an owner, a review gate, and a parity test.
Activities:
- Run Microsoft SSIS to Fabric Data Factory migration tooling (and equivalent partner tooling) over the auto-conversion set. Treat the output as a draft — never as a finished pipeline. Auto-conversion typically achieves 40-60% accuracy on real-world SSIS portfolios; the remaining 40-60% requires manual refactor.
- For Script Tasks and custom .NET components: re-implement in Fabric notebooks (PySpark / Spark SQL) or in Data Factory Mapping Data Flows. There is no one-for-one auto-conversion; this is a re-design opportunity.
- Map every package parameter and connection manager to its Fabric DF equivalent: pipeline parameters, dataset parameters, linked services backed by managed identities or Key Vault references. Document the mapping per package.
- Re-implement the SSIS deployment model in Fabric Git integration: source-control every pipeline, dataset, and linked service definition. The SSISDB catalog goes away; Git + deployment pipelines replaces it.
- For lift-and-shift packages: provision the Azure-SSIS Integration Runtime, restore SSISDB to Azure SQL DB (or Managed Instance), and validate package execution end-to-end before retiring the on-prem source.
- Code-review every converted pipeline against a senior-architect-authored review checklist (parameterization, error handling, retry policy, alerting, naming conventions, OneLake zone alignment, sensitivity labels). Self-review is not a review.
Artifact: Converted pipelines in Fabric Git, deployment-pipeline-ready, with documented parameter mappings and senior-architect review sign-off
Typical duration: 8-20 weeks (the long pole; varies with portfolio size and complexity mix)
Phase 5: Validation
Goal: Prove that the new Fabric Data Factory pipeline produces the same output as the legacy SSIS package — same rows, same values, same schedule, same downstream consumer experience. No package cuts over without parity evidence.
Activities:
- Run parallel execution: legacy SSIS package and converted Fabric DF pipeline both run on the same source data on the same cadence for a defined parity window (typically 2-4 weeks for daily pipelines, 1-2 cycles for monthly pipelines).
- Compare outputs row-by-row using checksum and row-count tests. For columnar parity, hash each row in source and target and compare the hash distributions. For aggregate parity, run agreed-upon downstream KPIs (revenue, headcount, claim counts) on both outputs and compare.
- Validate the data contract: schema, data types, nullability, primary keys, referential integrity. SSIS packages often hide implicit schema assumptions that break in Fabric — surface them in validation, not in production.
- Validate the RPO / RTO: when the source system has a failure, does the Fabric pipeline recover within the same window as the legacy SSIS job? Run a deliberate failure drill on at least one critical pipeline per domain.
- Validate the downstream consumer experience: does the Power BI semantic model refresh on the same cadence? Do the SSRS / paginated reports render the same numbers? Do the regulatory feeds pass the same validation gates? Surface consumer-side breakage in validation, not in production.
- Sign off the parity test with the data product owner. If they will not sign, the pipeline is not validated — go back to Phase 4.
Artifact: Parity Test Report per pipeline (row counts, checksum results, KPI comparison, RPO / RTO drill result, consumer sign-off)
Typical duration: 2-6 weeks per wave (parallel run during this window)
Phase 6: Cutover & retirement
Goal: Move the workload from the legacy SSIS package to the validated Fabric DF pipeline. Retire the SSIS package. Sunset SSISDB and the SSIS server when the portfolio is fully migrated.
Activities:
- Cutover one wave at a time (typically 10-30 packages per wave depending on complexity and consumer risk). Big-bang cutovers are how SSIS modernization programs fail visibly. Wave-based cutovers contain the blast radius of any single failure.
- Schedule cutovers in low-traffic windows with a documented rollback plan. The rollback is "re-enable the SSIS SQL Agent job and disable the Fabric DF schedule" — and it must be tested in a non-production environment before the cutover window.
- Communicate every cutover wave to the data product owners, the on-call rotation, and the downstream consumers at least 5 business days in advance.
- After cutover, run the SSIS package and the Fabric DF pipeline in parallel for one additional cycle (the "shadow run") — Fabric is the source of truth, but SSIS still runs as a safety net. Compare outputs one final time.
- Retire the SSIS package: disable the SQL Agent job, archive the package binary, document the retirement in the decision register. SSISDB rows are kept for audit but the package is no longer scheduled.
- Sunset the on-prem SSIS server and SSISDB at the end of the program — only after the full portfolio is converted, validated, cut over, and shadow-run-confirmed. Capture the SSISDB lineage history into Purview before sunsetting so the audit trail survives.
Artifact: Cutover runbook per wave, rollback runbook, post-cutover parity report, SSISDB lineage export to Purview
Typical duration: 4-12 weeks of cutover windows + 2-4 week SSISDB sunset
SSIS → Fabric Data Factory conversion patterns
Most SSIS packages are built from a small set of recurring constructs. The six below cover the vast majority of what converters encounter day-to-day. Memorize these mappings — they are the building blocks of every conversion in the program.
| SSIS construct | Fabric Data Factory equivalent | Conversion notes |
|---|---|---|
| Execute SQL Task | Script activity (T-SQL) inside a Fabric DF pipeline; for SET-based heavy lifts inside the Fabric Warehouse, use Stored Procedure activity against a Warehouse stored proc | Direct conversion in most cases. Parameter pass-through migrates as pipeline parameters. SQL Server-specific syntax (e.g., MERGE, OUTPUT, hints) may need a Fabric Warehouse syntax review — Fabric Warehouse SQL is not 100% identical to SQL Server T-SQL. |
| Data Flow Task | Mapping Data Flow (for transformations with mapping UI) OR a Notebook (PySpark / Spark SQL) inside the Fabric DF pipeline. For pure copy with no transformation, use the Copy activity. | The single most-converted component. Mapping Data Flow handles 70% of Data Flow Task scenarios out of the box; Notebook is the right escape hatch for the 30% that need code (complex window functions, ML-adjacent feature engineering, dynamic schema handling). |
| Lookup transform | Mapping Data Flow Lookup activity OR a join inside a Notebook | Mapping Data Flow Lookup supports cached / no-cache / partial-cache modes similar to SSIS. For very large lookup tables (50M+ rows), a Notebook broadcast join is often faster and cheaper in Fabric CU terms. |
| Conditional Split | Mapping Data Flow Conditional Split (direct equivalent) OR If Condition activity at the pipeline level for control-flow-level routing | Direct equivalent inside Mapping Data Flow. At the pipeline level, the If Condition activity routes between sub-pipelines based on an expression — useful for "did source change?" gating that SSIS Conditional Split was sometimes (mis-)used for. |
| Script Task (C# / VB.NET) | Notebook (Python / Spark SQL) OR an Azure Function called via the Azure Function activity | No auto-conversion. Re-implement the business logic in Python inside a Fabric Notebook (preferred — keeps everything inside Fabric) or, when the script wraps an external API or library that does not run in Spark, host as an Azure Function. Plan ~2-8 hours of refactor per non-trivial Script Task. |
| Sequence Container | Sub-pipeline (Execute Pipeline activity) OR ForEach activity for iterative containers | Containers used for grouping → Execute Pipeline activity. Containers used for transactional grouping (TransactionOption = Required) need explicit error handling in the parent pipeline — Fabric DF does not have a direct equivalent to SSIS transactions and you must design compensating actions. |
Effort sizing — how to estimate a 500-package SSIS portfolio
Effort sizing is where SSIS modernization programs are won or lost. The classification scoring matrix below is the working tool EPC senior architects use during Phase 2. The numbers are calibrated against real conversion work — not against vendor marketing.
| Complexity bucket | Scoring signals | Lift-and-shift hours | Refactor to Fabric DF hours |
|---|---|---|---|
| Low complexity | Single Data Flow, 1-3 source/sink connections, no Script Task, no custom components, no transactional grouping, fewer than 10 transformations. | 4-8 hours per package (lift-and-shift to Azure-SSIS IR) | 12-24 hours per package (refactor to Fabric DF) |
| Medium complexity | 2-5 Data Flows, 4-10 source/sink connections, parameterized package, simple Script Tasks (logging / file movement), 10-30 transformations. | 8-16 hours per package | 24-60 hours per package |
| High complexity | 5+ Data Flows OR Script Tasks with substantial business logic OR custom .NET components OR transactional sequence containers OR 30+ transformations OR dynamic SQL generation. | 16-32 hours per package | 60-180 hours per package |
Worked example — 500-package portfolio
A typical 500-package mid-market portfolio classifies roughly as follows after Phase 1-2 work:
- ~75 packages (15%) retire — no living consumer, no output in 90+ days, or duplicate functionality. Effort: 0 hours (decision + sign-off only).
- ~50 packages (10%) lift-and-shift to Azure-SSIS Integration Runtime — stable, low-change, hard deadline. Effort: ~50 packages × 12 hours average = 600 hours.
- ~225 packages (45%) refactor to Fabric DF — low complexity. Effort: ~225 packages × 18 hours average = 4,050 hours.
- ~115 packages (23%) refactor to Fabric DF — medium complexity. Effort: ~115 packages × 40 hours average = 4,600 hours.
- ~35 packages (7%) refactor to Fabric DF — high complexity. Effort: ~35 packages × 100 hours average = 3,500 hours.
Total conversion effort: ~12,750 hours — roughly 6-8 senior-architect-led FTEs running for 9-12 months once Phase 3 (Architecture) is complete and the first wave begins. Add Phase 1-3 effort (~1,500 hours) and Phase 5-6 effort (~2,000 hours). Total program: ~16,000 hours / 8-9 senior-architect FTE-quarters / 9-15 calendar months. These numbers are calibrated; treat them as a starting estimate, not a quote — every real portfolio shifts the mix.
Six pitfalls that derail SSIS modernization programs
Across the SSIS modernization programs EPC has executed, the same six failure modes account for the majority of cost overruns and missed go-live dates. Engineer them out at program start; they are predictable.
- Under-estimating Script Tasks and custom components. The single largest overrun driver. Plan 2-8 hours per non-trivial Script Task explicitly in the roadmap; do not bundle them into the "Data Flow Task" line item. Inventory every Script Task and every third-party SSIS component in Phase 1 — and price them in Phase 2.
- Trusting self-reported package complexity. Package developers reliably over-rate complexity to protect their work and under-rate it on packages they want to retire. Sample-validate 10-20% of every complexity bucket with a senior data engineer review before locking the classification register.
- Migrating clear-text connection strings. The conversion is the right moment to replace credential auth with managed identities (where supported) and Key Vault references (everywhere else). Carrying SSIS credential patterns forward leaks the same secrets into a new platform. Make this a mandatory code-review gate.
- Big-bang cutovers. Cutting over the whole portfolio in one weekend window is how SSIS modernization programs fail visibly. Wave-based cutovers (10-30 packages per wave) contain the blast radius and let the team refine the runbook between waves. Plan for it from Phase 3.
- Skipping the parity validation. Going live without row-count, checksum, and KPI parity against the legacy SSIS package is how downstream consumers find data drift after cutover — when it is expensive and reputationally damaging. The validation phase is not optional and the data product owner sign-off is not optional.
- Sunsetting SSISDB before exporting lineage. SSISDB execution history is referenced in audit and compliance frameworks (HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP). Drop the database without exporting the history to a Fabric Lakehouse cold-storage table and capturing the lineage in Purview, and you have a regulatory gap on your hands. Design the export in Phase 3, execute it in Phase 6.
Governance, lineage, and observability on Fabric Data Factory
One of the strongest reasons to land on Fabric Data Factory rather than ADF v2 standalone is that governance, lineage, and observability are native — not retrofitted. The modernization is the right window to fix the governance gaps that built up over a decade of SSIS development.
Purview lineage: Fabric Data Factory pipelines, OneLake items, and downstream Power BI semantic models surface end-to-end column-level lineage in Microsoft Purview automatically. Compare that with SSIS, where lineage was either captured manually, reverse-engineered from SSISDB, or simply absent. For regulated workloads, this alone is often the business case.
Fabric monitoring hub: every pipeline run, every activity, every error is visible in the tenant-wide monitoring hub with filtering, search, and alerting. Pair with Log Analytics export for long-retention audit and with Power Automate or Teams for on-call alerting.
OneLake security: item-level access control, workspace-level role assignment, sensitivity-label inheritance from upstream sources, and integration with Microsoft Entra ID. Combined with the credential-migration discipline above (managed identities + Key Vault references, never clear-text), the security posture after migration is materially stronger than the on-prem SSIS baseline.
CI/CD with Fabric Git: every workspace can be tied to a Git branch. Pipelines, datasets, and linked services are source-controlled. Deployment pipelines promote items dev → test → prod with parameter overrides per stage. SSIS deployments — historically a tangle of dtutil scripts, manual SSISDB project deployments, and one-off ALM tooling — are replaced by a clean, repeatable, audited pattern. EPC publishes the reference CI/CD pattern inside the Microsoft Fabric Training & Learning Hub as part of the engineer track.
Sensitivity labels and data classification: sensitivity labels applied to a OneLake item propagate forward to every downstream Fabric item that depends on it — the Lakehouse table, the Warehouse view, the Direct Lake semantic model, the Power BI report. That is a categorical improvement on SSIS, where data classification lived in spreadsheets and broke at every refactor. For regulated data (HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP), the classification story materially de-risks audit and right-of-access workflows. EPC applies the sensitivity-label inheritance pattern as part of every Phase 3 architecture design and validates it as part of every Phase 5 parity test.
Why EPC Group runs SSIS to Fabric migrations
EPC Group is the Microsoft Solutions Partner (29 years, founded 1997) that has executed 11,000+ Microsoft engagements, 6,500+ implementations, 1,500+ Power BI deployments, and 216+ M&A tenant consolidations — many of which carried SSIS modernization on the critical path of the deal-close calendar. Field-tested in regulated industries (HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP) and on 70+ Fortune 500 programs.
Errin O'Connor — Founder & Chief AI Architect, original Microsoft Power BI / Project Crescent beta team member, and Microsoft Press author — leads the senior-architect bench that delivers these engagements personally. No junior delivery, no hand-off to an offshore conversion shop. Every conversion is reviewed by a senior architect against the EPC review checklist before it ships into Fabric Git.
The methodology on this page is the same methodology we run on engagements ranging from 50-package mid-market SSIS portfolios to 1,000+ package M&A consolidation programs across multiple acquired tenants. It is built on top of the EPC Group Microsoft enterprise digital-transformation framework and the The EPC Group Lifecycle (Assess → Modernize → Govern → Operate → Enable).
Three ways to engage EPC Group on SSIS modernization
Fixed-fee, senior-architect-led, defined deliverables. Pick the engagement that matches where you are in the program.
SSIS Modernization Assessment
3-week fixed-scope, fixed-fee
Outcome: A complete portfolio inventory, a classification decision register (lift / refactor / retire per package), a target architecture sketch (Fabric workspace topology + F SKU sizing), and a costed migration roadmap with wave plan and timeline. Output is a board-ready deliverable.
Who fits: Right for a CIO / CDO who knows SSIS modernization is coming and wants the answer to "what does this actually cost and how long does it actually take" before committing to a multi-quarter program. Always the right first engagement.
SSIS → Fabric Migration Accelerator
90-180 days, fixed-scope per wave
Outcome: Senior-architect-led conversion of a defined SSIS portfolio (typically 50-300 packages per accelerator) into validated, parity-tested, cut-over Fabric Data Factory pipelines. Includes the target landing zone, the CI/CD pattern, the observability stack, and the operating runbooks. Multi-wave for portfolios above 300 packages.
Who fits: Right for an enterprise that has completed the assessment, signed off the target architecture, and is ready to execute. Not a place to start — book the Assessment first if you don't yet have a costed plan.
Managed Fabric Data Factory
Ongoing, monthly fixed-fee with quarterly review
Outcome: Production operation of the migrated Fabric DF estate by EPC senior architects — pipeline monitoring, incident response, capacity right-sizing, ongoing pipeline development for new sources, governance and security posture maintenance. Brings the EPC Group Lifecycle "Operate" stage to your Fabric Data Factory footprint.
Who fits: Right for an organization that wants senior-architect-level pipeline operations without staffing a Fabric platform team in-house — typical for mid-market and regulated enterprises where the Fabric expertise market is thinnest.
SSIS to Fabric Data Factory — frequently asked questions
The eight questions enterprise data leaders ask in every SSIS modernization scoping call — answered the way the senior architect on the engagement would answer them.
Can SSIS run forever — is Microsoft retiring SQL Server Integration Services?
Microsoft has not announced an end-of-life date for SQL Server Integration Services as of 2026. SSIS continues to ship with SQL Server (SQL Server 2025 ships with SSIS), and the Azure-SSIS Integration Runtime inside Azure Data Factory continues to be supported for lift-and-shift scenarios. That said: Microsoft's platform investment is unambiguously moving to Fabric Data Factory. New SSIS features have slowed to a trickle since 2023, while Fabric Data Factory ships new capabilities every monthly release. The right way to read the signal is: SSIS will keep running for years, but it is in long-term maintenance mode, not active development. Most enterprises we work with plan a 2-5 year glide path from SSIS to Fabric Data Factory — keeping SSIS alive for the long tail of low-change packages, and shifting all new ingestion development to Fabric DF starting day one.
What is the typical cost of running SSIS on-prem versus Fabric Data Factory?
Direct cost comparison is hard because the two licensing models are different in shape. On-prem SSIS costs include SQL Server licensing (per-core, Enterprise Edition for production SSISDB at scale), Windows Server licensing, the underlying VM or physical hardware, storage for SSISDB, the database administrator headcount to operate it, and the SSIS developer headcount to maintain it. Fabric Data Factory costs are folded into the Fabric capacity (F SKU) — a single capacity-unit (CU) bill covers Data Factory, Lakehouse, Warehouse, Power BI, Real-Time Analytics, and Data Science. There is no separate SSIS licensing, no separate SSISDB, no Windows Server. For a typical mid-market portfolio (200-500 SSIS packages, 1 production SSIS server + 1 DR), on-prem fully-loaded annual run-rate is commonly $200K-$600K when you include the operations headcount. The equivalent F SKU footprint (F64 or F128 depending on concurrency) runs $80K-$240K annually — but you must add the senior-architect operations layer if you don't have it in-house. The honest answer: Fabric DF is meaningfully cheaper at scale when the rest of the analytics estate is also on Fabric; it is a wash or slightly more expensive when it is the only Fabric workload.
What is the realistic auto-conversion accuracy from SSIS to Fabric Data Factory?
Vendor marketing routinely cites 70-90% auto-conversion accuracy. Field experience across the 6,500+ implementations EPC has executed says the realistic number for a non-trivial production SSIS portfolio is 40-60%. The gap is not the tooling — it is what the tooling cannot convert: Script Tasks with custom .NET code, third-party SSIS components, dynamic SQL generation, package-level transaction handling, custom logging frameworks, and the long tail of in-house design patterns that built up over the decade SSIS ran the warehouse. Auto-conversion is genuinely useful for the 40-60% that converts cleanly — it removes the boilerplate work — but it is not a path to a finished migration. Treat auto-conversion output as a starting draft for a senior data engineer, not as a deployment-ready pipeline. Plan the program budget on the assumption that 40-60% of the portfolio refactors manually, not on the assumption that auto-conversion replaces the conversion phase.
When does lift-and-shift to Azure-SSIS Integration Runtime make sense versus refactoring to Fabric Data Factory?
Lift-and-shift makes sense for three specific patterns. (1) The package is stable, low-change, and runs a workload nobody is asking to enhance — the cheapest exit is to relocate it untouched onto Azure-SSIS IR and let it run for the remainder of its useful life. (2) There is a hard deadline to retire the on-prem SQL Server (data-center exit, M&A divestiture, regulatory mandate) that does not allow time for refactor — lift-and-shift buys you 18-36 months. (3) The package is part of a portfolio segment scheduled for retirement, but not yet — lift-and-shift bridges the gap. Refactor to Fabric Data Factory makes sense when (1) the package sits on an actively-developed data product, (2) the downstream destination is OneLake / Lakehouse / Warehouse / a Power BI semantic model, (3) the package has known reliability or performance pain that the refactor solves, or (4) the package is touched frequently and will benefit from the Fabric CI/CD experience. The retire decision applies to about 10-20% of every SSIS portfolio we have inventoried — packages with no living consumer, duplicate functionality, or zero output for 90+ days. Make that call before either of the other two.
What is the right strategy for parameters and connection strings during conversion?
Never carry SSIS connection strings forward as clear-text strings in Fabric DF linked services. The conversion is the opportunity to replace credential-based connections with managed identity wherever the source system supports it (Azure SQL DB, Synapse, Fabric Warehouse, Cosmos DB, Azure Storage, Event Hubs) and to replace clear-text secrets with Key Vault references everywhere else (third-party SaaS APIs, on-prem databases via self-hosted integration runtime). SSIS package parameters and project parameters map to Fabric DF pipeline parameters and dataset parameters respectively. SSIS environments (which scope parameter values per dev / test / prod) map to Fabric deployment-pipeline parameter overrides — set the parameter value at the deployment-pipeline stage, not in the pipeline definition. Document the full mapping per package in the conversion artifact, and have a senior architect review the credential migration as a separate, mandatory review gate. Credential migration is where SSIS conversions leak secrets.
How do SSIS Script Tasks translate to Fabric Data Factory?
SSIS Script Tasks have no one-for-one auto-conversion in Fabric Data Factory because the SSIS Script Task hosts a full .NET runtime with arbitrary C# or VB.NET code — and Fabric DF does not have an embeddable .NET runtime in the pipeline. The two clean re-implementation paths are: (1) Notebook activity — re-write the Script Task logic in Python or Spark SQL inside a Fabric Notebook, called from the pipeline. This is the preferred path because everything stays inside Fabric with unified observability, security, and OneLake access. Typical effort is 2-8 hours per non-trivial Script Task. (2) Azure Function activity — host the original .NET code (or a Python port) as an Azure Function and call it from the pipeline via the Azure Function activity. This is the right path when the Script Task wraps an external API or library that does not run in Spark, or when the team has strong .NET skills and wants to preserve the existing code investment. Both paths require a real refactor pass — there is no shortcut. Plan the effort explicitly in the migration roadmap; under-estimating Script Task conversion is the single most common cause of SSIS migration overruns we see in practice.
How long is a typical parallel-run / validation window before cutover?
Parallel-run duration depends on the pipeline cadence and the business risk of the data product. Daily pipelines need 2-4 weeks of parallel run — that captures at least one full month-end close, one weekend cycle, and one weekday business cycle, and surfaces any time-window edge cases (e.g., daylight-saving boundaries, holiday calendars, source-system maintenance windows). Weekly pipelines need 4-8 weeks of parallel run. Monthly pipelines need at least 2 full monthly cycles. Real-time / streaming pipelines (which are unusual in SSIS portfolios but do exist) need a 1-2 week parallel run plus a deliberate failure-mode drill. Regulated workloads (HIPAA, FINRA, SOC 2, FedRAMP, CMMC) typically need an extra cycle for compliance team sign-off. Never let the parallel run drift past the planned window — long parallel runs cost double the platform fees and double the operations attention. If parity is not achieved in the planned window, the right move is to go back to the conversion phase and rework the pipeline, not to extend the parallel run indefinitely.
How do we handle SSISDB lineage and audit trail when we sunset SSIS?
SSISDB stores execution history, parameter values, and a partial lineage record going back to whenever the catalog was created. This is often referenced in audit and compliance frameworks (SOX, HIPAA, FINRA, FedRAMP, CMMC), and you cannot simply drop the database. The right pattern is: (1) before SSIS sunset, export the full SSISDB execution history to a Fabric Lakehouse table as cold-storage audit data — this is queryable indefinitely at a small cost. (2) Capture the SSIS package-to-source-to-destination lineage in Microsoft Purview as static lineage entries representing the legacy SSIS workload; this preserves the audit lineage even after the packages are gone. (3) Forward-going lineage is captured natively by Fabric Data Factory and surfaced in Purview — no manual export required. (4) Keep the SSISDB backup in archival storage (Azure Blob cool / archive tier) for the retention period required by your regulatory regime (typically 7 years for FINRA / SOX, longer for FedRAMP and CMMC). The audit story is solvable — but it has to be designed in Phase 3 (Architecture) and executed in Phase 6 (Cutover & retirement), not improvised at the end of the program.
Continue reading
Ready to scope your SSIS to Fabric Data Factory migration?
Book the 3-week SSIS Modernization Assessment. Fixed-scope, fixed-fee, senior-architect-led. You walk away with a classified portfolio, a target architecture, a costed roadmap, and a wave plan — board-ready in three weeks.