pq2fabric reads the Power Query out of your semantic models, dataflows, and Excel workbooks and turns it into one inventory: every query, every source, every duplicate. It then classifies each query against Fabric and emits Dataflow Gen2, notebook, or SQL artifacts. What it cannot translate with confidence goes on a review list instead of being guessed at.
Power Query is where most Microsoft BI estates keep their real transformation logic. It accumulates for years inside semantic models, Power BI dataflows, and Excel workbooks, written by different people, never reviewed, never documented. It is not a schema you can diff, it is thousands of lines of M spread across artifacts that each store it in a different format.
How many queries, where the duplicates are, which ones still point at a decommissioned source. The only way most teams find out is to open each artifact and read it, so the inventory becomes the first month of the project.
Linked and computed entities, gateway bindings, workspace-scoped parameters, and refresh policies all need rework in Fabric. Which ones, and how much, is usually discovered halfway through the migration.
Heavy transformations dropped straight into Dataflow Gen2 keep running. Some of that logic belongs in a notebook or in the SQL analytics endpoint, but deciding which requires reading every step of every query.
pq2fabric reads Power Query out of the formats it actually lives in, builds one normalised inventory, scores each query against Fabric, and emits artifacts you can commit. An LLM is used only for translation and explanation, never for the inventory itself, and a human signs off on every generated artifact before it runs.
Expressions and partition sources in .pbip TMDL and model.bim, the mashup document inside a Dataflow Gen1 model.json, exported Power Query templates, and the DataMashup part of Excel workbooks.
Every query, source, custom function, and parameter, plus the references between them. Duplicate and near-duplicate logic is reported, including the same transformation living under three different names.
Each query is rated on connector support in Fabric, folding behaviour, gateway dependency, and use of Gen1-only constructs such as linked and computed entities. That score is what the estimate rests on.
Straightforward folding queries over supported connectors come out as item definitions, mashup.pq plus queryMetadata.json plus .platform, ready to deploy through Git integration instead of being rebuilt by hand in the browser.
Queries whose cost profile argues against a dataflow are translated into PySpark or Spark SQL against a Lakehouse, with the original M step chain preserved as inline comments so a reviewer can check the translation line by line.
Native queries, timing tricks like Function.InvokeAfter, binary and PDF connectors, nested record gymnastics: each lands on a review queue with the source snippet, the reason, and a suggested Fabric pattern. A human decides those.
The parser and generator run as a Python CLI. Generated artifacts land in your repository and deploy through Fabric Git integration or the REST items API, so the migration output is source-controlled from day one.
Give us a semantic model folder or a dataflow export. We run the inventory against it, then walk you through what your estate actually contains and what the migration costs.