Data integration modernization

SSIS to Microsoft Fabric Migration Services

SQL Server Integration Services (SSIS) can continue to support critical financial loads, customer integrations, reporting, and warehouse refreshes. As dependencies and operational knowledge grow, organizations may reassess how these workflows are maintained and scaled.

Office Solution AI Labs helps assess and modernize SSIS workloads for Microsoft Fabric—mapping package behavior, identifying reusable logic, and selecting a controlled migration path for each workload. The goal is to preserve business outcomes, not convert every .dtsx file blindly.

SSIS to Microsoft Fabric migration overview

SSIS packages may depend on SSISDB projects and environments, connection managers, custom assemblies, SQL Server Agent jobs, credentials, file shares, third-party components, and operational procedures. Microsoft Fabric offers building blocks that can replace or complement parts of that solution, but the right mapping depends on what each package actually does.

Why organizations reassess SSIS

SSIS is a mature ETL technology and can remain appropriate when its execution model and operational controls meet current needs. Migration decisions should follow business and technical drivers—not an assumption that every legacy workflow must be replaced immediately.

Platform consolidation

Assess opportunities to reduce separately managed data integration and analytics environments.

Cloud data strategy

Move selected processing and storage patterns toward managed cloud services where they fit.

Analytics integration

Connect ingestion and transformation with Lakehouse, Warehouse, Power BI, and data science workloads.

Operational complexity

Review server upkeep, package deployments, configuration, and fragmented monitoring.

Skills and maintainability

Align implementation patterns with the organization’s future data engineering roadmap.

Governance and scale

Reassess data volume, compute, access, lineage, monitoring, and release practices.

Fabric is not automatically cheaper or faster for every SSIS workload. Capacity sizing, data movement, concurrency, transformations, licensing, and operations all affect the business case.

SSIS to Fabric: modernization, not file conversion

Map each existing pattern to a target component only after reviewing its behavior, connectivity, and operational requirements.

SSIS pattern	Potential Fabric target	Migration consideration
Package sequencing and orchestration	Fabric Data Factory pipeline	Rebuild control flow, dependencies, retries, schedules, and failure behavior.
Copying data between supported systems	Copy activity	Confirm connector support, authentication, throughput, and source limits.
Power Query-style data preparation	Dataflows Gen2	Validate transformation behavior and destination write patterns.
Complex transformations or custom logic	Fabric notebook / Spark	Reimplement and test expressions, null handling, data types, and error behavior.
SQL-based transformations	SQL scripts, stored procedures, or Warehouse/Lakehouse SQL	Confirm target engine compatibility and transaction semantics.
Lookup, merge, or conditional logic	Dataflow, SQL, Spark, or pipeline expressions	Choose based on scale, maintainability, and behavior—not a one-to-one name match.
SQL Agent job chains	Fabric pipeline schedules and dependencies	Recreate calendars, dependencies, failure notifications, and restart behavior.
Selected SSIS package execution	Invoke SSIS Package activity where eligible	Microsoft documents this as Preview; verify current support, constraints, and lifecycle.
On-premises source connectivity	Supported connectivity and gateway architecture	Assess network routes, gateway placement, credentials, and data residency.

Distinguish invocation, rehosting, and refactoring

Invoke or retain package execution

Keep selected SSIS logic running while orchestration or the surrounding architecture evolves. Microsoft documents an Invoke SSIS Package activity in Fabric Data Factory as a Preview feature; this does not convert package logic into native Fabric components.

Rehost SSIS

Move compatible package execution to a supported SSIS runtime such as Azure-SSIS Integration Runtime in Azure Data Factory. This is a transitional cloud-hosting strategy, not native Fabric package conversion.

Refactor into Fabric-native components

Redesign orchestration and transformations with Fabric Data Factory, Dataflows Gen2, notebooks, SQL, Lakehouse/Warehouse patterns, and supported connectors. Expect package-specific engineering and validation.

Our SSIS-to-Fabric migration services

We establish what exists before estimating conversion effort, then choose target patterns around operational requirements rather than forcing every package into the same Fabric artifact.

Inventory SSIS projects, packages, environments, SQL Agent schedules, connection managers, parameters, configurations, and dependencies.
Classify package complexity, business criticality, data volume, execution frequency, and recovery requirements.
Map control flow, data flow, transformations, scripts, connectors, and custom components to possible target patterns.
Rebuild selected workflows using Fabric Data Factory pipelines, Dataflows Gen2, notebooks, SQL, or a hybrid approach.
Design target data architecture across OneLake, Lakehouse, Warehouse, and operational source systems.
Assess identity, credentials, network connectivity, governance, and operational controls.
Plan reconciliation, parallel runs, deployment, cutover, rollback, and operational handover.
Evaluate migration acceleration with Pulse Convert, subject to package compatibility and validation.

Assessment output

A workload inventory, dependency map, risk register, target-pattern recommendation, and prioritized migration backlog.

A practical seven-phase migration lifecycle

Package count alone does not determine effort. Establish business context, dependencies, supportability, and acceptance criteria before organizing implementation waves.

1. Inventory and business context
Collect package and project exports, job definitions, configuration references, run history, source and target inventory, business criticality, and ownership. Identify active, redundant, duplicated, and retirement candidates.
2. Complexity and readiness scoring
Assess transformation complexity, custom code, connector availability, dependencies, data volume, frequency, recovery needs, and business risk. Use the score to prioritize work—not as an automatic effort estimate.
3. Select migration patterns
Assign each package to a suitable pattern: native Fabric rebuild, staged rehosting, eligible package invocation, redesign, replacement by an existing source-system capability, or retirement. Document assumptions and approvals.
4. Pilot and prove
Select a representative workload and implement it end to end, including connectivity, scheduling, logging, reconciliation, and operational support. Use measured findings to refine standards and estimates.
5. Wave-based implementation
Group packages by shared sources, transformation patterns, dependencies, or business domains. Reuse templates where they reduce maintenance and sequence dependent packages deliberately.
6. Validate and release
Complete technical and business acceptance, resolve high-severity defects, verify recovery behavior, and obtain explicit production approval before cutover.
7. Optimize and retire
Review capacity utilization, pipeline duration, data movement, failures, and support effort. Retire legacy jobs and infrastructure only after ownership, dependencies, retention, and rollback windows are cleared.

Migration scenarios to assess

On-premises SQL Server and SSIS estates

Plan a phased move while maintaining controlled access to operational databases, file shares, and private-network systems. Treat network and gateway architecture as first-class design items.

SSIS with SQL Agent orchestration

Map schedules, job chains, retry policy, proxy identity, alerts, and downstream dependencies along with the packages themselves.

Large package portfolios

Triage package families, common patterns, retirement candidates, and blockers. Prioritize by business value and risk—not package count alone.

Custom scripts and third-party components

Run technical spikes for custom assemblies, Script Tasks, vendor connectors, and specialized transformations; document replacement options and validation needs.

Incremental and CDC-oriented workloads

Redesign watermark logic, change tracking, CDC, and late-arriving updates against the actual source capabilities and intended consistency model.

Hybrid or transitional architecture

Retain selected SSIS execution where justified, with explicit boundaries, cost visibility, security controls, and a review or retirement plan.

SSIS and Microsoft Fabric: a decision comparison

This comparison is directional. Fabric is not a single replacement runtime for every SSIS feature, and the best target may retain SQL or other services where justified.

Dimension	Traditional SSIS estate	Fabric-oriented architecture
Execution	Package runtime on managed or self-managed SQL/SSIS infrastructure	Managed Fabric pipeline activities and workload-specific compute
Orchestration	SSIS control flow and often SQL Agent	Fabric Data Factory pipeline orchestration
Transformations	SSIS data flow, scripts, SQL, custom components	Dataflows Gen2, Spark notebooks, SQL, and supported pipeline activities
Storage	Often SQL Server, file systems, or other destinations	OneLake, Lakehouse, Warehouse, and supported external systems
Operations	Package deployment, runtime maintenance, job operations	Workspace/artifact deployment, capacity, and pipeline monitoring
Key risks	Legacy dependencies and operational knowledge	Semantic differences, connector limits, capacity design, and governance setup

How Pulse Convert can support migration acceleration

Pulse Convert is positioned by Office Solution AI Labs as an automation accelerator for SSIS-to-Fabric modernization. It can be evaluated for package analysis and conversion activities, repetitive mapping work, and migration artifacts for review.

Automation is an accelerator—not evidence that every package is supported or generated pipelines are production-ready without testing.

Step 1Select a representative package set and confirm export requirements.
Step 2Analyze package structures, dependencies, and conversion candidates.
Step 3Review mappings and identify unsupported or ambiguous components.
Step 4Validate target artifacts and business logic with engineers.
Step 5Run reconciliation and performance tests; record exceptions.
Step 6Use measured pilot outcomes to decide whether to expand automation.

Commercial claims and offers in vendor listings are not universal independently verified results. Confirm scope, exclusions, acceptance criteria, and contract terms directly before using them in a business case.

View the Pulse Convert Marketplace listing

Security, governance, and access design

Fabric security must be designed and configured explicitly. Do not assume a platform move automatically preserves SSIS package security semantics.

Workspace roles, least-privilege access, and data-sharing boundaries.
Credential storage, rotation, and supported service identities for each connector and activity.
Gateway hardening, patching, network egress, and private-source connectivity.
Sensitive package parameters and secrets kept out of notebooks and pipeline definitions.
Data classification, retention, audit requirements, and regulatory controls.
Separation of developer, operator, and approver responsibilities.
Deployment permissions and protection of operational logs.

Performance and cost: measure the workflow

Fabric capacity is shared across workloads. A migration changes where compute is consumed and data moves; it does not remove the need for workload management.

Data volume and growth, full versus incremental loads, and concurrency.
Source-system throttling and impact, plus movement across regions or network boundaries.
Spark startup and runtime, Dataflow refresh, and pipeline activity duration.
Capacity utilization, throttling, contention, and retry behavior.
Storage, retention, duplicate staging data, licensing, and capacity commitments.
Comparable service levels for freshness, recovery, availability, retention, and support.

Compare like-for-like service levels for freshness, recovery, concurrency, retention, availability, and support—not only server costs against a Fabric capacity estimate.

Common migration mistakes to avoid

Assuming every SSIS component has a direct Fabric equivalent.
Confusing package execution in Fabric with conversion into Fabric-native logic.
Migrating SQL Agent jobs without dependencies and failure behavior.
Overlooking Script Tasks, custom assemblies, third-party components, or external executables.
Replacing transformations without testing data types, precision, null semantics, and ordering.
Ignoring source-side load, network constraints, or duplicate writes during parallel runs.
Using one generic test for every package, regardless of business criticality.
Embedding credentials in code or exported configuration.
Retiring the original workflow before rollback and business acceptance are complete.
Estimating effort from package count alone or treating automation output as production proof.

What a scoped engagement may deliver

Deliverables are agreed during discovery and depend on package scope, access, source systems, licensing, and acceptance criteria.

SSIS inventory, package classification, and SQL Agent dependency map.
Complexity assessment, risk register, and prioritized migration backlog.
Target architecture, migration-pattern decisions, and source-to-target mapping.
Agreed Fabric pipelines, Dataflows Gen2, notebooks, SQL artifacts, or other target deliverables.
Environment and configuration guidance, plus reconciliation and test evidence.
Performance observations, tuning recommendations, and operational runbooks.
Deployment, cutover, rollback, training, and knowledge-transfer materials.
Documented deferred or unsupported package elements.

Microsoft guidance and related migration services

Microsoft documentation

Related modernization services

Frequently asked questions

What does SSIS to Microsoft Fabric migration mean?

It means assessing and moving SSIS-driven data integration workflows toward Microsoft Fabric. Depending on the package, this can involve rebuilding orchestration in Fabric Data Factory, implementing transformations in Dataflows Gen2, Spark notebooks, or SQL, changing destinations, and recreating operational controls. It is not necessarily a direct .dtsx file conversion.

Can SSIS packages run directly in Microsoft Fabric?

Microsoft documents an Invoke SSIS Package activity in Fabric Data Factory as a Preview feature. Check current availability, prerequisites, limitations, and preview status before planning production use. Native modernization and package invocation are different strategies.

Is Azure-SSIS Integration Runtime the same as Fabric?

No. Azure-SSIS Integration Runtime is an SSIS execution environment in Azure Data Factory. It can support a lift-and-shift approach for compatible packages, but it is not the same as rebuilding workloads as Fabric-native pipelines and transformations.

Will every SSIS package migrate automatically?

No. Package complexity, custom code, third-party components, connector availability, expressions, data types, and operational dependencies determine what can be automated and what needs redesign or manual engineering. Each package needs a supportability decision and validation.

What happens to SQL Agent jobs?

Schedules, job steps, dependencies, retries, proxies, notifications, and downstream triggers must be inventoried. Appropriate orchestration can be recreated in Fabric pipelines or retained in a transitional architecture; the plan should address operational behavior explicitly.

How are Script Tasks and Script Components handled?

Assess language, runtime, libraries, external dependencies, and business logic. Some logic may be rewritten as Spark, SQL, or another supported Fabric activity. There is no universal one-click equivalent for arbitrary custom code.

Can we migrate only selected packages?

Yes. A phased migration can prioritize packages by business value, complexity, risk, dependency order, and readiness. Some workloads may be retained, redesigned, or retired instead of migrated.

How do you validate migrated data?

Validation can include row counts, aggregates, business-key comparisons, hashes, data-quality checks, file controls, and parallel runs. Acceptance criteria should reflect data criticality and be agreed with data owners; successful activity status alone is not proof of parity.

Does Microsoft Fabric reduce migration cost?

It can change infrastructure and operational cost structures, but savings are not automatic. Capacity use, workload design, data movement, licensing, concurrency, and support requirements all matter. A measured pilot is a better basis than a blanket percentage.

What is Pulse Convert?

Pulse Convert is an Office Solution AI Labs migration accelerator marketed for SSIS-to-Fabric conversion. Review its output for coverage, correctness, unsupported elements, and production readiness. Request a scoped demonstration and package-level acceptance criteria.

How long does an SSIS migration take?

There is no reliable duration based only on package count. Timing depends on custom scripts, dependencies, reconciliation, private connectivity, regulated data, and other workload details; estimate it after inventory, pilot results, and wave planning.

What information is useful for an initial assessment?

Useful inputs include package or project inventory, SQL Agent job definitions, source and target systems, execution frequency, approximate volumes, custom components, failure points, business criticality, and target Fabric architecture. Do not send credentials or production secrets.

Start with an SSIS workload assessment

Build a clear view of what your SSIS estate does, what must remain unchanged, and which Fabric patterns are appropriate. Office Solution AI Labs can help validate a pilot and establish a wave-based modernization plan—without a blanket conversion promise.