Migrate database objects to Microsoft Fabric in phases without creating a new Warehouse for every run. Start with one business domain, add another when it is ready, or revisit an object after its source definition changes. You can also build on an existing Warehouse instead of replacing it.
Incremental migration for Microsoft Fabric Data Warehouse (Preview) lets you move workloads in manageable phases while keeping control of the destination. Select the objects required for the current workload, add more objects in later runs, and resolve naming conflicts when an incoming object already exists. The process migrates object definitions; it does not continuously synchronize changed rows.
You can start with an empty Warehouse, continue a previous migration, or use an existing Warehouse that was not created through migration. This flexibility lets teams preserve completed work while adding the next approved scope. It also supports deliberate consolidation into the Fabric destinations that match your architecture.
Choose the objects that belong in each migration
Enterprise migration plans often span several teams, applications, and business domains. Those groups do not always need to move together. Incremental migration lets you define the scope of each run. Instead of including every source object, select the objects needed for the workload you are moving.
For example, start with the schemas, tables, and views required by one business domain. Review the translated definitions and validate the dependent workload before expanding the scope. In a later run, return to the same Warehouse and add the next approved set of objects.
In the destination Warehouse, open the Migration tab and select Get more objects. Provide the source connection or upload a supported source input, and then select Choose more objects to migrate to define the next set.
Figure: Use Get more objects to start another migration run from the destination Warehouse.
Figure: Select source objects and review dependencies and naming conflicts before migration.
Before you start the run, review the complete object list populated in the selection dialog. The list flags naming conflicts and adds direct dependencies for selected objects. Confirm that every included object is necessary for the workload you intend to migrate.
- Filter source objects to show all objects, objects with naming conflicts, or objects without naming conflicts.
- Identify objects whose names already exist in the destination through warning indicators.
- Review each selected object’s direct dependencies before you start the migration. Migration Assistant includes those dependencies by default, so the final scope can contain more objects than you initially selected.
Review the source, destination, selected objects, and included dependencies in the summary. Confirm that every object belongs in the current scope and that naming conflicts have an owner. The Migration Assistant guide for connecting to a source system describes the workflow.
Build on an empty or existing warehouse
The destination does not have to come from an earlier migration or a specific migration mode. Choose the destination based on the workload, ownership model, security boundary, and naming plan. The following starting points are supported.
- An empty Warehouse: Begin with a destination you have prepared and migrate the first set of objects into it.
- A previously migrated Warehouse: Add more objects or revisit selected objects from an earlier run.
- A Warehouse that was not created through migration: Bring source objects into a Warehouse that already contains work created through other means.
You do not need to create another Warehouse just because you are starting another migration run. Reusing a destination can reduce unnecessary duplication and keep related objects together. Confirm, however, that the shared destination fits the workload and data-isolation requirements.
Re-migrate objects with control
Migration work often requires revisiting an earlier decision. A source definition can change after the first run, or a translated object might need correction after validation. Re-migration lets you return to that object without treating the entire source as a new migration.
When an incoming object's name already exists in the destination, Migration Assistant identifies a naming conflict. Objects without naming conflicts can be created immediately. Conflicting objects remain pending and are not created or replaced until you explicitly choose how to resolve each conflict.
For each conflict, compare the SQL definitions side by side: the existing definition on the left and the incoming translated definition on the right. Review the full definition, not only the highlighted difference, because connected changes can affect downstream objects. Then choose the action that fits the object.
- Keep existing: Retain the destination's current definition and discard the incoming translated definition.
- Keep incoming: Replace the existing definition with the incoming translated definition, confirming the action when prompted.
- Rename incoming: Create the incoming object under a different name while retaining the existing object.
Conflict handling makes re-migration an explicit decision. You can preserve work already completed in Fabric, accept a revised source definition, or keep both definitions under different names. Record the chosen action so that workload owners understand which definition is active.
Figure: Compare existing and incoming definitions before resolving a naming conflict.
Replacing an object changes its definition in the destination and may require you to reload data or revalidate dependent workloads. Before you replace a table, view, or procedure, identify the objects and processes that use it and plan the required follow-up work. For detailed behavior, refer to Resolve conflicts and fix objects.
Consolidate your data estate
Incremental migration lets you move selected objects from supported SQL Server databases, Azure Synapse Analytics dedicated SQL pools, or Teradata databases into one or more Fabric Warehouses. A separate destination Warehouse is not required for every source database or migration run. The destination design should still reflect workload ownership, security, naming, and data-isolation requirements.
This approach supports several consolidation patterns. Choose a pattern only after confirming that the workloads can share the same operational and security boundaries. Common uses are listed below.
- Consolidate objects from multiple databases on the same source platform.
- Bring together selected objects from different supported source platforms.
- Expand the same Warehouse as additional databases and workloads are ready to migrate.
As you add objects, conflict handling helps you manage names already present in the destination. Compare existing and incoming definitions, then keep the existing object, replace it with the incoming definition, or rename the incoming object. This decision determines which definition becomes part of the consolidated Warehouse.
Consolidating destinations does not automatically reconcile definitions or combine table data. Review dependencies, naming conventions, permissions, ownership, and data-loading requirements before each run. These checks help the consolidated Warehouse reflect the intended architecture rather than an accidental collection of objects.
Keep object migration and data loading distinct
In this preview, incremental migration means selecting, adding, or revisiting database object definitions across separate migration runs. It covers object selection, translation, dependency handling, and definition conflicts, but it does not continuously synchronize changed rows.
After migrating the required definitions and resolving conflicts, plan the associated data movement. Migration Assistant can integrate with a copy job in Data Factory for Microsoft Fabric to copy data into the destination. Treat that data movement as a separate activity with its own schedule, monitoring, and validation.
Validate each selected workload before expanding the migration scope. Verify translated definitions, dependency completeness, conflict decisions, permissions, and the queries or reports that depend on the migrated objects. When replacing a table definition, include the required data reload and downstream validation in the plan.
Keeping object migration and data loading distinct makes each run easier to review. The team can state which definitions move, which existing objects change, and what data work follows. That separation also makes failures easier to isolate and rerun.
Next steps
Reduce migration risk by starting with a small, representative workload: identify its boundary, choose the destination Warehouse, migrate the required objects, and validate the result before expanding the scope. For prerequisites and supported workflows, review the Migration Assistant for Fabric Data Warehouse overview, and then follow either the source-connection migration guide or the file-based migration guide.
Microsoft Employee