Moving Dataflow Gen1 to Gen2 in Microsoft Fabric - What I Tell Clients
If you've been using Power BI dataflows for any length of time, you've probably got a pile of Dataflow Gen1 artifacts kicking around your workspaces. They do their job, they refresh on schedule, and nobody really wants to touch them. Now Microsoft has Dataflow Gen2 in Fabric, the original ones are quietly being labelled "Gen1", and the writing is on the wall.
The migration story is reasonable but not entirely clean. I've done this a few times now for Australian clients and there are some patterns worth sharing before you wade in.
Why bother migrating at all
Let's be honest. If your Gen1 dataflow is running fine, refreshing on time, and nobody is complaining, the urgency is low. Gen1 still works. Microsoft hasn't announced an end-of-life date as of writing.
But there are real reasons to move:
CI/CD support. Gen2 with CI/CD finally lets dataflows live in source control properly. You can branch, review changes, and deploy through Git workflows. Gen1 was always a click-ops experience where the only "version control" was hoping nobody else edited the same dataflow at the same time. For any client where data engineering has matured past one person clicking around in a browser, this matters.
Better compute options. Gen2 runs on Fabric capacity and has knobs for performance tuning that Gen1 never had. If you've got a dataflow taking 45 minutes to refresh, Gen2 gives you levers to pull. Gen1 was take-it-or-leave-it.
Destination flexibility. Gen1 dataflows fed Power BI semantic models and that was about it. Gen2 can write to a lakehouse, a warehouse, SQL, or just leave the data in the dataflow itself. This unlocks a lot of reuse you couldn't get before.
Compatibility with the rest of Fabric. If your organisation has committed to Fabric for the broader data platform, mixing Gen1 dataflows in feels inconsistent. The data team starts to dread the Gen1 ones because they're the odd ones out.
If none of that resonates with you, leave them alone. Migration for its own sake is a waste of time.
The three migration paths
Microsoft documents three ways to move Gen1 to Gen2. They're all valid, they each have a sweet spot, and picking the right one saves a lot of friction.
Path 1: Export template
This is the one I default to when I'm moving an entire dataflow with all its queries. Open the Gen1 dataflow in the Power Query editor, hit Export template from the Home ribbon, give it a name, and you get a .pqt file in your downloads folder. Then create a new Dataflow Gen2, choose Import from a Power Query template, point at the .pqt, and you're off.
What I like about this approach: it preserves the query structure exactly, including the folder groupings if you've organised your queries that way. What I don't like: it doesn't bring across the dataflow's settings, refresh schedule, destination configuration, or permissions. You're moving the recipe, not the kitchen.
Plan to reconfigure all the settings on the Gen2 side. If your Gen1 dataflow was incremental refresh, that needs to be set up fresh. If it was writing to a specific destination, that needs to be redefined.
The template approach also works for moving queries from outside Power BI entirely. Power Platform dataflows export templates. Excel can export query templates. You can collect templates from multiple sources and stitch them into one Gen2 dataflow if that's useful.
Path 2: Copy and paste queries
When you only want a subset of queries from a Gen1 dataflow, this is the simpler approach. Open the Gen1 dataflow, multi-select the queries you want with Ctrl-click, copy them, then go to a new or existing Gen2 dataflow and paste into the Queries pane.
Slight catch: you can't paste into an empty dataflow directly. You need to create a blank query first (Get data, then Blank query) to give Power Query something to anchor against. Then paste your queries in. Then delete the placeholder blank query.
The credential prompts are the annoying part. Each pasted query loses its credential association because credentials are per-dataflow in Fabric. You'll get a "Credentials are required to connect" message and have to walk through Configure connection for each unique data source. Not a big deal but plan the time.
I use this approach a lot for refactoring. You've got one Gen1 dataflow that became a dumping ground for 40 queries over three years. Now you want to split it into three logical Gen2 dataflows by domain. Copy-paste lets you reshape the structure as you go.
Path 3: Save As
This is the newest option and the one Microsoft is gently pushing for full-dataflow migrations. Open a Gen1 dataflow, use the Save As feature to create a new Dataflow Gen2 (CI/CD) from it. The mechanics are essentially a one-shot upgrade that preserves more than the template approach does.
I haven't used Save As nearly as much as the other two because it's newer and the known limitations list keeps changing. Last I checked, things like incremental refresh policies and certain destination configurations don't make the trip cleanly. Always check the current Microsoft docs for known limitations before betting on Save As for a critical dataflow.
When Save As works cleanly, it's the path of least resistance. When it doesn't, you're debugging weird state and wishing you'd just used the export template approach.
What I actually recommend
For most clients, the order I work through is:
Inventory your Gen1 dataflows first. You need to know what you've got. List every dataflow, who owns it, what it feeds, how often it refreshes, and roughly how complex it is. Half the dataflows in a typical environment turn out to be unused, abandoned, or built by someone who left two years ago. Don't migrate dead weight.
Categorise by importance. Critical, business-as-usual, and "we should probably delete this". Migrate critical ones with the most care. Delete the dead ones rather than migrating them. The middle tier you can batch through quickly.
For each migration, decide consolidation or split. Don't just lift-and-shift. If a Gen1 dataflow has grown into a monster with 50 queries doing five unrelated things, the migration is a chance to break it apart. Copy-paste makes this easy.
Rebuild settings, don't just import. Even with Save As, double-check refresh schedules, destinations, incremental policies, and permissions. Assume nothing transferred and verify everything.
Run them in parallel for a bit. Don't delete the Gen1 version the day you finish the Gen2 migration. Let them run side by side for two refresh cycles. Compare outputs. Confirm the Gen2 version produces identical results before pulling the plug.
Some of our Microsoft Fabric consulting work has been pure migration projects where we've moved 200+ Gen1 dataflows for a single client. The technical mechanics are straightforward. The hard part is the inventory and the courage to delete the abandoned ones.
Watch out for these traps
A few things that have caught teams I've worked with:
Credentials and gateway connections. If your Gen1 dataflow uses an on-premises data gateway, the Gen2 version needs gateway access too. Sometimes the gateway permissions need updating to grant the workspace access to specific data sources. Don't assume it's all wired up.
Parameters that don't behave the same way. Gen1 had quirks around how query parameters interacted with refresh. Gen2 handles them differently. If you've got parameterised queries, test refresh behaviour explicitly rather than assuming it works.
Premium per user vs Fabric capacity. Gen1 ran on Premium per user or Premium capacity. Gen2 needs Fabric capacity. If your workspace isn't on Fabric capacity yet, you can't create Gen2 dataflows there. This is usually a procurement conversation more than a technical one but it can stop migration cold.
Linked queries. Gen1 supported linked entities where one dataflow's output became another dataflow's input. Gen2 has different patterns for this involving lakehouses and shortcuts. The simple "linked entity" pattern doesn't translate one-to-one.
Refresh history is gone. When you move to Gen2, you lose all the historical refresh logs from Gen1. Not catastrophic but worth knowing if you're auditing reliability.
Where this fits in a bigger picture
Migrating Gen1 to Gen2 dataflows is usually part of a bigger move into Fabric. We help clients with everything from initial Fabric adoption strategy through to detailed data engineering work in Fabric. The dataflow migration is one slice of that journey.
If you're starting Fabric adoption from scratch, my advice is to build new things in Gen2 from day one and migrate Gen1 opportunistically as you touch each artifact. Don't run a big-bang migration project unless there's a specific business reason for one. Migrate when you're already in the dataflow making changes, then you're not paying the migration cost on top of regular work.
Anyone who tells you Fabric is feature-complete and the migration story is smooth hasn't done many migrations. It's manageable, it's improving, but it's still work. Budget for it accordingly.
Reference
The Microsoft documentation lays out the three paths cleanly: Move queries from Dataflow Gen1 to Dataflow Gen2. Worth reading alongside this post for the screenshot walkthroughs.
If you're thinking about a larger migration program, get in touch. Most of our Fabric work starts with helping someone work out what to migrate, what to rebuild, and what to leave alone entirely.