Why should mid-market businesses migrate from Dataflow Gen1 to Gen2?
Dataflow Gen2 in Microsoft Fabric gives data teams capabilities that Gen1 never had. Source control via Git, faster compute tuning, and the ability to write directly to a lakehouse, warehouse, or SQL destination all make Gen2 the clear long-term foundation for any business serious about scaling its data operations.
Microsoft has not announced an end-of-life date for Gen1 as of mid-2025. If your Gen1 dataflows refresh on schedule and no one is complaining, the urgency is low. But if your organisation has already committed to Microsoft Fabric as its core data platform, leaving Gen1 artifacts running alongside Gen2 creates inconsistency and adds operational risk over time.
Source control and CI/CD: Gen2 integrates with Git workflows so data engineers can branch, review, and deploy dataflow changes the same way they manage application code. Gen1 had no version control beyond hoping two people did not edit the same dataflow simultaneously.
Performance tuning: Gen2 runs on Fabric capacity and exposes compute controls that Gen1 never offered. A dataflow that takes 45 minutes to refresh on Gen1 can often be significantly accelerated using Gen2's performance levers.
Flexible data destinations: Gen1 dataflows fed Power BI semantic models and little else. Gen2 can write to a lakehouse, a warehouse, SQL, or keep data within the dataflow itself, unlocking reuse across the entire Fabric platform.
Platform consistency: Businesses running Microsoft Fabric for their broader data platform benefit from standardising on Gen2 entirely. Mixed environments increase maintenance overhead and make onboarding new data team members more complex.
What are the three migration paths from Dataflow Gen1 to Gen2?
Microsoft documents three supported methods for moving Gen1 dataflows to Gen2. Each path has a clear use case. Choosing the wrong one for your situation adds unnecessary rework.
Export Template (.pqt file): Open the Gen1 dataflow in the Power Query editor, export a .pqt template from the Home ribbon, then import it into a new Dataflow Gen2. This preserves the full query structure and folder groupings exactly. It does not carry over the refresh schedule, destination configuration, incremental refresh settings, or permissions. Those must be reconfigured manually on the Gen2 side.
Copy and Paste Queries: Select specific queries inside a Gen1 dataflow using Ctrl-click, copy them, then paste directly into a new or existing Gen2 dataflow. This is the best approach when splitting one large, mixed-purpose Gen1 dataflow into multiple focused Gen2 dataflows by business domain. Note that credentials do not transfer between dataflows in Fabric, so each unique data source connection needs to be reconfigured after pasting.
Save As (CI/CD upgrade): Open a Gen1 dataflow and use the Save As feature to create a new Dataflow Gen2 with CI/CD enabled. This is the closest to a one-shot upgrade and preserves more context than the template export. However, incremental refresh policies and certain destination configurations do not always migrate cleanly. Always review the current Microsoft documentation for known limitations before using Save As on a business-critical dataflow.
Which migration path should operations teams use first?
Start with a full inventory of every Gen1 dataflow in your environment before running a single migration. List each dataflow's owner, downstream dependencies, refresh frequency, and approximate query complexity. In most Microsoft Fabric environments, a significant share of Gen1 dataflows turn out to be unused, abandoned, or built by team members who have since left the organisation.
For complete dataflow migrations where all queries need to move, the Export Template path is the most reliable starting point. It produces a predictable result and forces a clean reconfiguration of settings on the Gen2 side, which is often useful for tidying up configurations that drifted over time on Gen1.
Use the Copy and Paste path when the goal is to restructure a large, disorganised Gen1 dataflow into multiple purpose-built Gen2 dataflows. This approach works well for wholesale distributors, manufacturers, or professional services firms whose Gen1 dataflows grew organically and now contain unrelated queries mixed together.
Save As is the fastest path when it works cleanly. Reserve it for lower-complexity dataflows where incremental refresh and custom destinations are not in play. Verify the current Microsoft known limitations list before applying it to any dataflow that feeds live reporting in Power BI or downstream processes in SAP, Salesforce, or Microsoft 365.
What goes wrong most often during a Dataflow Gen1 to Gen2 migration?
Credential loss is the most common friction point. Fabric stores credentials at the dataflow level, so any query moved from Gen1 to Gen2 loses its data source connection and needs to be reconfigured. Budget time for this step when planning migrations that touch multiple source systems.
Incremental refresh settings do not transfer through any of the three migration paths reliably. If your Gen1 dataflow uses incremental refresh to manage large historical datasets, that configuration must be rebuilt in Gen2 from scratch. Skipping this step causes full refreshes that significantly increase load times and capacity consumption.
Missing destination configuration: Export Template and Copy and Paste migrations do not carry over the dataflow's output destination. If Gen1 was writing to a specific Power BI dataset, the Gen2 dataflow needs a new destination mapping configured to a lakehouse table, warehouse, or SQL endpoint before it goes live.
Pasting into an empty Gen2 dataflow: Fabric does not allow pasting queries directly into a blank Gen2 dataflow. Create a placeholder blank query first via Get Data, paste the copied queries, then delete the placeholder. Skipping this step causes the paste operation to fail with no clear error message.
Migrating unused dataflows: Without an upfront inventory, teams frequently spend time migrating Gen1 dataflows that have had no downstream consumers for months. Kernel Flow always starts migrations with a dependency audit to ensure effort is directed at dataflows that actively support business reporting or operational workflows.