Chinh (lelouvincx) / Power BI to Holistics narrative

Created Mon, 25 May 2026 00:00:00 +0000 Modified Mon, 25 May 2026 16:41:09 +0000
1294 Words
page
  • Hello everyone. My name is Chinh. Today I want to walk you through something I’ve been building recently: an end-to-end migration from Power BI into Holistics, with the help of agentic development. If you’ve ever tried to move a Power BI project to another BI tool, you already know the pain point: the dashboard is the easy part. The hard part is everything underneath it. So that’s what I want to show you today — a less-painful path from PBI all the way to a code-native Holistics project.
  • Before touching any code, I want to put a conceptual map on the screen, because I think a lot of demos are making you reverse-engineer the mental model from watching commands fly by, and that’s not fair. So here’s the map. . And in Holistics, every single one of those — models, datasets, dashboards, metrics — is AMQL text. One language across the whole stack. That’s what makes this migration possible to automate, because both the source and the target are code-readable.
  • Here is the final result. At first glance — layout looks correct, the charts are in the same positions, the filters are where you’d expect them. Numbers look correct too: same revenue total, same YoY percentage, same breakdown by region. If I filter a year, the underlying values match. That’s the destination. The interesting part isn’t that the dashboard rendered — it’s that behind this dashboard there’s now a governed semantic layer in code, with every DAX measure translated into AQL, every relationship preserved, and every difference reviewable as a Git diff. So now let me rewind and show you how we got here.
  • Okay, with that mental model in place and the end state on the table, let me show you the source. Here’s a Power BI Project file — a .pbip. If you open it up, you’ll see TMDL files for tables and relationships, DAX measures sitting in their own files, and the report definition serialized as well. That’s the unlock. Before .pbip existed, you’d be staring at a binary blob and parsing screenshots. Now the agent can read the semantic model directly.
  • So let me jump into Claude Code. I’m going to load the skill — it’s called holistics-migrate-power-bi — and I’m just going to give it a plain English prompt: “Use the holistics-migrate-power-bi skill to migrate this .pbip project into a Holistics project. Create the AML models, datasets, and Canvas Dashboards, translate the DAX measures into AQL or SQL metrics, and validate with the Holistics CLI.” That’s the whole instruction. Let me run it from scratch — pretend no Holistics project exists yet — so you can see the full path from beginning to end.
  • First thing the agent does is inventory the Power BI source. You can see it discovering tables, walking the relationships, picking up every DAX measure, and cataloguing the report pages and visuals. This step — the step that on a real migration project usually becomes a multi-week manual documentation exercise where a consultant sits down and writes a spec — the agent finishes it in seconds, and the output is structured input it can act on.
  • Now it starts writing Holistics code. You can watch the .model.aml files appear in the editor. Each Power BI table becomes a logical model — note that there’s no imported copy of the data, just a definition that compiles to SQL at runtime. The semantic model becomes a .dataset.aml, and because Holistics datasets are reusable, the same underlying model can plug into multiple dashboards instead of being trapped in a single workspace-scoped Power BI semantic model. Where the source uses Power Query M for transformations, the agent generates a query model in SQL — so that transformation logic lives in your warehouse, not in VertiPaq, and any other tool in your stack can read it too.
  • Now the part I really want to show you, because this is where every Power BI migration project lives or dies — the DAX translation. Let me put a real example side by side. On the left, a year-over-year sales measure in DAX. You’ve got a CALCULATE wrapping SAMEPERIODLASTYEAR against a marked Date table, then a DIVIDE to get the percent change. Three lines of measure logic, plus a Date table you had to set up correctly upstream, plus all the filter-context behavior that anyone who’s debugged DAX knows can surprise you. On the right, the same measure in AQL. It’s a one-liner: total_sales | relative_period(orders.created_at, interval(-1 year)), and then a safe_divide to compute the percentage change. No marked Date table required. Native period functions that work on any timestamp column. Explicit dimension scope instead of implicit filter context. And — this is important — if the AQL version isn’t a fit, or your team just wants to stay in SQL because that’s where their skills are, you write @sql and drop in a SQL expression directly. There’s no language tax. Your team’s existing SQL knowledge still counts.
  • Once the semantic layer is in place, the agent rebuilds the report as a Canvas Dashboard. Layout, filters, the visual structure — all generated from the report metadata the agent extracted earlier. And again, unlike a Power BI report, this dashboard isn’t bound to a single semantic model. It can span multiple datasets if it needs to.
  • Now we get to the part that, on a real migration, eats sixty to eighty percent of the budget — validation. And this is where being code-native really pays off. The agent runs holistics aml validate to check that everything compiles. Then it runs holistics mcp execute_aql to actually execute queries against the warehouse and compare results to what the source produced. And because everything is AMQL text, when there is a difference — a measure that doesn’t quite match, a relationship that resolved differently — it shows up as a diff. You review it in a pull request. You see the change. You approve it or you correct it. The migration stops being a manual rebuild and becomes a code-review loop. That’s the shift.
  • Let me put the final result side by side. Here’s the original Power BI report. Here’s the migrated Holistics dashboard. Same numbers. Same shape of insight. But the difference is what’s behind them. Behind the Power BI report you have a .pbix with embedded DAX, a VertiPaq refresh pipeline you have to babysit, and a semantic model that lives in one workspace. Behind the Holistics dashboard you have a Git repository of AML files — models, datasets, dashboards, metrics — all version-controlled, all reviewable, all reusable. The warehouse is the source of truth. There’s no second copy of the data. There’s no refresh schedule to maintain. And the whole thing is ready for the next layer of analytics work — including AI agents — because the semantic context is already in code.
  • So to close this out — I want to be honest about what this is and what it isn’t. This is not a one-click, fully automated migration. Some DAX patterns, some calculation groups, some RLS rules will need a human in the loop. What it is, is a less-pain migration. You get a first draft in minutes instead of months. You get validation as a code review instead of as a side-by-side dashboard squint-test. And critically, you don’t just recreate the old BI estate in a new tool — you land on an analytics-as-code foundation that’s governed, AI-ready, and that your team can actually maintain and extend for the next decade.
  • That’s the demo. Happy to walk through any specific Power BI pattern you’d like to see translated — RLS, calculation groups, complex time intelligence, whatever your hardest measure is. Drop it in the chat or reach out. Thanks for watching.