Author: Norma: Practice Director
Key takeaways:
- Genie Code's import capability (in Public Preview, for Tableau and Power BI) turns a workbook into an AI/BI dashboard backed by metric views, so a migration can preserve business logic in a governed, reusable form rather than just copying charts.
- The automation covers a great deal, measures, calculated fields, connections, and filters, but chart-type equivalence, layout, and some level-of-detail and drill behaviors still need an engineer's review. Treat it as an iterative workflow, not a one-shot conversion.
- At enterprise scale, the migration succeeds or fails on the decisions the tool does not make for you: Rationalizing duplicate logic before you convert, promoting shared metric views into Unity Catalog, and validating parity before rollout. That is where KPI Partners focuses.
Databricks recently published a hands-on guide to importing dashboards with Genie Code, and it is a genuinely useful step forward. Point Genie Code at a Tableau or Power BI file and it will inspect the model, propose a plan, and build an AI/BI dashboard connected to metric views in a target catalog and schema. Having led BI migrations at enterprise scale, my honest read is this: The import itself is the easy part now. The engineering decisions around it are what determine whether you end up with a governed analytics foundation or a faster version of the mess you already had. This is a field guide to those decisions.
What the Import Actually Does
The capability, invoked with the import command in Genie Code, is currently in Public Preview and supports Tableau and Power BI files out of the box. When you run it, Genie Code reads the source model, separates fact tables from dimensions, reviews the measure definitions, and flags any formulas that have no direct equivalent so you can decide what to do with them. Once you approve the plan, it builds the objects, usually a mix of metric views and supporting views, in the catalog and schema you specify. It is an assistant you steer with prompts, not a black box, and that distinction matters, because the quality of the result depends heavily on how precisely you instruct it.
The Real Win is Metric Views, Not Migrated Charts
If you take one thing from this, take this: A dashboard migration to AI/BI is only worth doing if it leaves you with more than dashboards. The import lands your business logic as metric views, and those metric views can be promoted into Unity Catalog, where they become reusable across dashboards, Genie Agents, and notebooks, under central governance with access controls, lineage, and discoverability. That is the difference between copying charts from one tool to another and consolidating your business logic into one governed semantic layer. A migration that stops at chart parity has missed the point. A migration that promotes shared metric views into Unity Catalog has turned a reporting project into a foundation.
At Enterprise Scale, Rationalize Before You Convert
The import runs one file at a time, and that is exactly where large migrations go wrong if you are not deliberate. If you convert an estate of hundreds or thousands of dashboards as-is, you will faithfully reproduce every duplicate measure and near-identical dashboard you have accumulated over the years, now as metric views to maintain.
Databricks' own guidance is clear on this, and it matches what we see in the field: Inventory first. Catalog the dashboards, shared models, extracts, and dependencies, then decide what to migrate, what to consolidate into a single governed model, and what to retire. This is where teams usually discover the same revenue metric defined several different ways across teams. Resolve that before you convert, not after, because a duplicate definition is far cheaper to fix as one metric view than as fifty.
Migrate the Semantic Layer First
The corollary is a sequencing rule I hold to on every engagement: When a report depends on a shared data source or model, migrate the semantic layer before you recreate any visuals. Build and settle the metric views first, promote the shared ones into Unity Catalog, and only then rebuild the dashboards on top of them. Instructing the import to reference existing governed metric views for shared measures, rather than creating a fresh local copy per dashboard, is the single most effective way to avoid metric-view sprawl. Define a measure like gross margin once, govern it, and let every dashboard and every Genie Agent draw on the same definition.
Know What Converts Cleanly, and What Needs an Engineer
Set expectations with your team up front, because an over-promised migration erodes trust fast. In practice, measures and calculated fields, data source connections, and dashboard and page-level filters tend to come across well. What needs a human eye is the presentation layer and the edges of the modeling: Chart types map only where a direct equivalent exists and may fall back to a simpler visual otherwise, widget positioning is approximate and usually needs layout tweaks, and some level-of-detail expressions and drill-down behaviors are not fully covered yet.
The productive way to work is iterative and specific. After the first pass, refine one class of change at a time, layout, then filters, then calculations, then naming, rather than issuing a single vague instruction to improve the dashboard.
Precise, single-purpose prompts produce reliable results; A generic "make it better" does not.
Governance is the Point, Not a Later Step
Because the target is a governed platform, treat governance as part of the migration rather than a cleanup afterward. Decide up front which catalogs and schemas will hold the migrated assets, how sensitive and personally identifiable information (PII) fields are handled, and what your naming conventions are, and encode those conventions directly into your Genie Code instructions so every generated object lands consistent and discoverable.
On the way to production, promote local metric views into Unity Catalog, then apply the access model your data requires: Row-Level Security (RLS) and Column-Level Masking (CLM), and Attribute-Based Access Control (ABAC) where it fits. When you publish, choose deliberately between everyone seeing the same data and each user seeing only what their Unity Catalog permissions allow. These are not optional finishing touches. They are what make the migrated estate safe to open up.
Validate Before You Roll Out
The line between a technically successful import and a production-ready rollout is validation, and it is worth being disciplined about. Before you scale across the estate, confirm that the metrics and dimensions produce the numbers the business expects, that filters behave the way users rely on, that charts are mapped sensibly where no direct equivalent existed, and that your most important dashboards are backed by promoted metric views in Unity Catalog rather than local copies. If the numbers do not tie out to the source, nothing else matters, because trust is lost on the first wrong figure and is slow to win back. Validation is not a formality at the end; It is the gate that decides whether the migration is real.
Do Not Stop at Chart Parity
The reason to move to AI/BI in the first place is that a dashboard alone is a ceiling on what a business user can ask. Once a dashboard is migrated and backed by governed metric views, enable Genie on it so users can ask the questions the fixed visuals do not answer, and lean on the fact that Genie works better precisely because your migration produced clean metric views. For larger needs, a dedicated Genie Agent alongside the dashboard handles ad hoc exploration and cross-dashboard questions.
And as you productionize, version your dashboards and enable continuous integration and continuous delivery (CI/CD) so changes are controlled and materialize heavy aggregations where speed matters. The endgame is not a migrated dashboard. It is a governed foundation your business can both read and interrogate.
Where KPI Partners Comes In
The native import removes most of the manual conversion effort, and for a handful of dashboards it may be all you need. Our value shows up at enterprise scale, in the work the tool does not do for you: Inventorying and rationalizing a large estate before conversion, designing the shared metric-view layer so definitions are governed once and reused everywhere, standing up the permissions and governance model, and running the validation discipline that proves parity before anything goes live.
We treat a dashboard migration as the moment to consolidate business logic into a trusted semantic foundation on Databricks, delivered through the KPI Partners Enterprise Analytics Accelerator on Databricks and our Databricks partnership. The automation is a lever. The outcome still depends on the engineering judgment around it.
The Tool Automates the Conversion. Your Team Owns the Outcome.
Genie Code has made the mechanical part of a dashboard migration dramatically easier, and that is worth celebrating. But the enterprise result, one governed set of metrics, a clean semantic layer, validated numbers, and dashboards that can be questioned as well as read, is not something any import produces on its own. Rationalize before you convert, migrate the semantic layer first, govern it properly, and validate before you scale. Do that, and Genie Code becomes an accelerator toward a governed analytics foundation, rather than a faster way to copy the past.
Related reading: KPI Partners Enterprise Analytics Accelerator on Databricks
Ready to Transform Your Data Strategy? Talk to our experts and discover how KPI Partners can accelerate your data and analytics initiatives.
