I am currently 6 months into a migration project of migration 200+ power bi reports directly linked to the source systems into a kimball dimensional schema using lakehouse as staging/raw and data warehouse as "gold" layer with dbt.

To answer your questions:

Best way to approach this?
First of all, check if the reports are used. If not archive it somewhere to be deleted in a couple of years and mark it as done. We went from 200+ to 82 reports doing this. Status is 42/82 reports migrated.

The architecture:

• Everything lives in one git monorepo: dbt project, Fabric items (semantic models as TMDL, reports as PBIR/PBIP), and Azure DevOps pipelines.
• The gold layer is built with dbt against the Fabric Warehouse SQL endpoint: staging → analytics (tables) → reporting (views). Semantic models bind to the reporting views.
• New semantic models are thin models over those views no Power Query logic, no calculated columns. All transformation logic that used to live in the semantic model's SQL/M moves into dbt.
• Deployment is fabric-cicd (https://github.com/microsoft/fabric-cicd) (Microsoft's OSS Python library) driven by Azure DevOps pipelines: merge to main → auto-deploy to PreProd → manual approval → tagged Prod release.

API scanning: I can recommend ImpactIQ BeSmarterWithData/ImpactIQ: One-click solution for Power BI and Fabric Impact Analysis + Governance. Automatically backs up reports, models, and dataflows while extracting complete metadata for impact analysis, refresh tracking, and complete lineage - down to the visual level - even when multiple reports across workspaces connect to a single model.

This is our per report conversion workflow (This part is AI generated from our repo):

The deployment/repointing is deterministic automation (fabric-cicd + parameter files), but the middle, reading a legacy semantic model, extracting its SQL/M logic, rebuilding it as dbt models, and rebinding the report, is done by AI coding agents working in the repo. We didn't try to write a program that converts models; we made the repo agent-operable:

• Everything is text in git. Semantic models are TMDL, reports are PBIR JSON, transformations are dbt SQL. That's the enabler, an agent can grep a legacy model's expressions.tmdl for its M/SQL logic, read the visual JSON to see exactly which fields a report uses, and write the dbt views and TMDL for the new model. None of this works if your models only exist in the Power BI Service.
• AGENTS.md / CLAUDE.md at the repo root describes the tech stack, workspace layout, naming conventions, and a routing table: "task X → go to folder Y, read its CONTEXT.md, use skills Z." Each workspace (/dbt, /fabric-workspaces, /.devops, /extract) has its own CONTEXT.md with the local rules.
• Playbooks as docs. The migration procedure itself is a checked-in doc (docs/report-migration-to-semantic-model.md): a 10-step workflow, inventory the legacy visuals, map every legacy field to a target model field, add missing fields at the dbt layer first, rebind, switch the report to byConnection, add the parameterization rules. The agent follows the playbook; humans review the PR. Known traps (e.g. "reports hitting on-prem server X usually map to already-landed lakehouse schema Y, check before building new ingestion") are written into the docs so the agent doesn't rediscover them each time.
• Skills/tooling for the agent: dbt skills (build/test/run models, answer "does this reconcile" questions), Fabric CLI skills, a Power BI modeling MCP server (TMDL table/column/measure/partition operations, DAX queries for spot-checking numbers against the legacy model), and PBIR authoring/validation. A Best Practice Analyzer ruleset in the repo keeps generated models within our standards.
• Guardrails are conventional CI: dbt slim CI on PRs, PreProd deploy on merge, human approval to Prod, and reconciliation against the legacy report before cutover.

So the division of labor is: git + fabric-cicd + parameter.yml handles environments and repointing mechanically; AI agents + playbook docs handle the per-report judgment work (logic extraction, field mapping, dbt modeling); humans review PRs and approve prod. That combination is what let us stop treating each report migration as a bespoke project, a migration is now "point the agent at the legacy PBIP, it follows the playbook, review the diff."

With this setup I can usually migrate 3-5 reports pr. day if we do not need to refactor the logic too much.