BrickShift: Accelerating BI Migration to Databricks for the Genie Era

For data leaders evaluating how to move existing Power BI, Tableau, and ThoughtSpot dashboards onto Databricks AI/BI without losing semantic fidelity, this guide explains why dashboard migration is the bottleneck on the path to Genie, what high-fidelity migration actually requires, the four phases that make the work tractable, and how BrickShift —  LatentView’s migration accelerator — compresses a typically multi-quarter program into weeks.

TL;DR (Key Takeaways)

• BI migration to Databricks is no longer a lift-and-shift problem; it is a semantic translation problem, and that is where most programs stall.
• Databricks Genie unlocks natural-language analytics over the lakehouse, but only when the underlying metric layer is preserved during migration, not rebuilt from scratch.
• BrickShift  automates extraction, conversion, and validation of dashboards from ThoughtSpot, Tableau, and Power BI into native Databricks AI/BI assets through a structured four-phase workflow.
• A complexity-mapping framework (L1–L4) sets accurate effort estimates upfront, so migration scope is defensible before the first dashboard is touched.
• Coverage benchmarks today: ThoughtSpot 80%, Tableau 65%, Power BI 55% — with corresponding cost reductions of 58%, 50%, and 40% against a manual baseline.
• The accelerator was built on Databricks for Databricks, with output that is Genie-ready by construction.

What is BrickShift?

BrickShift is LatentView’s migration accelerator, engineered for the systematic, high-fidelity translation of existing BI dashboards into the Databricks AI/BI environment. It supports three source platforms — ThoughtSpot, Tableau, and Power BI — and produces native Databricks artifacts: governed semantic layer objects, AI/BI dashboards, and migrated access controls. It is built on Databricks itself and runs as a set of orchestrated workflows, with all customization handled through configuration so customers can extend mappings without touching code.

The output is Genie-ready by construction. Metric definitions land in the Databricks semantic layer with proper classification, formatting, and dependency ordering — the structure Genie needs to answer natural-language questions accurately.

Why is BI migration to Databricks AI/BI different from a traditional dashboard migration?

BI migration to Databricks AI/BI is different because the destination is not just a new dashboard tool; it is a semantic layer that powers Genie, ML workflows, and AI/BI dashboards from a single metric definition. A migration that only redraws the visuals misses most of the value. The translation has to preserve calculation logic, table relationships, the access-control model, and the format of every measure — because every downstream Databricks capability reads from that semantic layer.

This distinction matters operationally. A team that completes a “successful” dashboard migration but rebuilds the calculations as ad-hoc SQL inside each visual has not finished the work. They have created new technical debt: every time someone asks Genie a question, the answer is computed from raw SQL without the governed metric definition behind it. Within six months, the same calculation is being expressed three different ways across three dashboards, and trust in the answers erodes.

The technical imperative for high-fidelity migration is driven by three forces:

• Genie depends on metric semantics. Natural-language queries route to the right tables and aggregations only when measures and dimensions are correctly classified at the catalog level.
• AI/BI dashboards are declarative. Visuals are defined as specifications against governed metric objects. Without a clean metric layer, every visual has to redefine its own logic.
• Unity Catalog is the access perimeter. Row-level security, column masking, and grants migrate as code, not as configuration screens — and they must align to the new identity model on day one.

How does the BrickShift technical workflow work?

BrickShift addresses migration through a structured four-phase technical approach. Each phase produces a defined output that the next phase consumes, and each phase logs its results so the migration leaves a complete audit trail.

Phase 1: High-fidelity asset discovery and ingestion

The first phase securely connects to the source BI platform and performs deep discovery of dashboard assets and their metadata. Across ThoughtSpot, Tableau, and Power BI, the goal is the same: extract a complete, structured representation of every dashboard, including the visualizations, the calculations behind them, the relationships between underlying tables, and the user access model.

A key step in this phase is dependency mapping across the metadata. When a visualization is migrated, all dependent components — formulas, filters, relationships, underlying data sources, and user access grants — are identified and logically grouped. This is what allows the conversion phase to translate calculations correctly the first time, instead of producing technically valid output that returns wrong numbers because a relationship was missed.

Phase 2: Structured complexity mapping

Not all dashboards require the same level of intervention, and treating them as if they do is the most common cause of overrun in BI migration programs. BrickShift uses a complexity-mapping framework that categorizes every asset into one of four levels based on a weighted score of visualization complexity and visual element count.

The output of this phase is a portfolio-level scorecard that drives sprint planning. Stakeholders know which dashboards will land cleanly through automation and which will need analyst review before the migration starts, not after.

Phase 3: Automated migration and transformation

The core of BrickShift is an automated workflow that transforms discovered assets into native Databricks artifacts. It runs in four sub-steps for every dashboard:

• Backend data mapping. Source schemas are aligned with the target Databricks data model, with source-system references resolved into governed catalog objects.
• Calculation conversion. Source-platform expressions are translated into the target semantic layer with classification preserved — measures remain measures with the right aggregation behavior, dimensions remain dimensions, format strings carry through, and dependencies are ordered correctly.
• Layout automation. A Databricks AI/BI dashboard is generated programmatically, mirroring the structure of the source. Standard chart types are mapped natively; less common visuals fall back gracefully to tables that can be refined manually.
• Tracker validation. Every visual element is logged with a conversion status: complete, partial, or flagged. Engineers see exactly which fields mapped, which were missing, and which need manual attention — for every widget, on every dashboard.

For higher-complexity assets (L3 and L4), the manual retouch step addresses tracker-flagged items. The 5–10% of charts that require human attention are surfaced explicitly, not hidden inside a “best effort” output.

Phase 4: AI-powered validation

The migration validator is the final phase. It evaluates the migrated dashboards and produces three outputs:

• Visualization summary. Every visual is compared structurally and semantically against its source. Differences in chart type, encoding, or field mapping are flagged with the specific divergence noted.
• Data validation summary. The underlying numbers behind each visualization are validated against the source. Numeric drift, null-handling differences, and aggregation mismatches are reported as concrete deltas, not summary statistics.
• Overall score. Each dashboard receives an overall score out of 10, with prioritized recommendations for any further changes required to reach production readiness.

This phase is what makes BrickShift defensible at sign-off. A migration without quantitative validation asks the business to take it on faith that the new dashboards are correct — and most enterprise migrations stall at exactly that handoff. The validator removes the trust gap.

What gets unlocked once the migration is complete?

Once dashboards are translated into Databricks-native artifacts, the source-platform constraints fall away. The same metric definitions that power dashboards become available to Genie for natural-language querying, to ML pipelines for feature generation, and to downstream applications — all without re-implementation.

The strategic difference is consolidation. Most enterprises run analytics across three or four BI tools because each was the right answer in a different decade. BrickShift supports collapsing that estate onto a single semantic layer governed in Unity Catalog, which is the precondition for a coherent AI strategy on top.

How is BrickShift different from generic migration scripts?

BrickShift is different from generic migration scripts in four specific ways, each tied to a failure mode we have seen on real engagements.

• Semantic preservation, not just syntax conversion. The accelerator emits governed semantic objects, not just translated queries. Measures are classified as measures, dimensions as dimensions, format strings are preserved, and dependencies are correctly ordered. Genie reads from that structure on day one.
• Relationship-aware conversion. Both the calculation engine and the data-mapping engine read from the source tool’s relationship graph and generate output that respects it. Naive flat-join approaches produce subtle aggregation errors that surface weeks after migration; relationship-aware conversion prevents them upfront.
• Configuration-driven, no-code extension. Customer-specific calculation patterns or custom visuals are added as configuration entries, not code changes — which means BrickShift adapts to a customer’s existing dashboard conventions instead of forcing them into ours.
• Full conversion audit trail. Every widget, every measure, every relationship is tracked with a status. Migration governance is a generated artifact, not a manual reconciliation exercise.

What level of automation should you actually expect?

Honest scoping matters more than headline numbers. BrickShift achieves the following coverage and cost-reduction benchmarks today, measured against fully manual migration baselines on real engagements.

Coverage varies by source platform because each has a different surface area of expressive complexity. Some workbook patterns — heavy use of platform-specific filter context, multi-source blends, parameter-driven filters, custom visuals — benefit from human review. Standard aggregation patterns, common chart types, and well-modeled relationships convert cleanly through automation.

What automation does not cover is flagged in the assessment scorecard before the engagement starts. There is no “migration completed except for the parts we never told you about.” For typical enterprise dashboards, that means the majority of work is automated, the remainder is scoped and estimated upfront, and analyst time is focused on the small set of items that genuinely need it.

How does BrickShift align to Databricks Genie?

BrickShift aligns to Databricks Genie at the metric layer, which is the single most important alignment a migration tool can make. Genie answers natural-language questions by routing them through governed semantic definitions. Without correctly classified measures and dimensions, Genie answers are unreliable; with them, Genie becomes the primary interface for the analytical estate that BrickShift has just migrated.

Three properties of the BrickShift output are specifically designed for Genie compatibility: measures emit with their aggregation semantics intact, dimensions are correctly classified, and format strings travel with the metric so answers display correctly without post-processing.

The practical implication is that an enterprise that migrates with BrickShift is not migrating a dashboard estate; it is creating the metric foundation that every Databricks AI capability — Genie today, downstream AI/BI agents tomorrow — will read from.

How should you start a migration program with BrickShift?

The fastest path to a defensible migration program — and the one LatentView runs with most enterprise customers — is a four-step sequence, applied to a single business unit before scaling 

• Run an assessment. BrickShift’s discovery and complexity-mapping phases run against the source environment in days, not weeks, and produce an L1–L4 scorecard for the entire dashboard portfolio. This is the single artifact that aligns stakeholders on scope, effort, and timeline before commitments are made.
• Migrate a representative slice. Pick a mix of L1, L2, and L3 dashboards from one business unit. Run them through the full four-phase workflow. The output is a working set of Databricks AI/BI dashboards plus a validated metric layer that Genie can immediately query.
• Validate against business users. The migration validator score is necessary but not sufficient. Have the original dashboard consumers run the migrated versions for two weeks. Their feedback closes the gap between technical fidelity and decision fidelity.
• Scale across the estate. Once one business unit has migrated cleanly, the configuration is tuned for that customer’s specific patterns. Subsequent business units inherit that tuning, and coverage rates climb with each iteration.

Most enterprises that try to migrate the entire estate at once spend the first quarter debating scope and the second quarter rebuilding things they could have automated. The single-slice approach gets a working metric layer into production inside the first quarter and uses the second quarter for scale, not negotiation.

Bottom line for data leaders

BI migration to Databricks AI/BI is no longer a question of whether, it is a question of how, and the wrong answer carries a real cost. A migration that skips the semantic layer creates technical debt that erodes Genie’s accuracy and forces ML teams to rebuild metric logic from scratch. A migration that tries to translate every measure manually consumes analyst capacity for two to four quarters and still ships with quality gaps that surface during business validation.

LatentView built BrickShift on the premise that the work that compounds  — semantic preservation, relationship-aware conversion, access-control translation, conversion audit — is exactly the work that should be automated. The work that requires judgment — flagged calculations, custom-visual decisions, business-user validation — is what analysts should spend their time on. Getting that allocation right is what separates migrations that finish on time from migrations that quietly become permanent.

Closing that gap is the work LatentView does with data leaders through BrickShift, our BI migration accelerator for the Databricks AI/BI ecosystem.

FAQs

1. Which BI platforms does BrickShift support today?

BrickShift supports ThoughtSpot, Tableau, and Power BI as source platforms. Each has a dedicated migration track with platform-specific extraction, conversion, and validation logic. The output for all three is native Databricks AI/BI: governed semantic objects, dashboards, and access-control mappings.

2. Does BrickShift support Databricks Genie?

Yes. BrickShift’s output is Genie-ready by construction. Metric definitions are emitted with proper classification, formatting, and dependency ordering — the structure Genie reads to answer natural-language questions accurately.

3. What automation coverage should we expect for our dashboards?

Coverage benchmarks today are 80% for ThoughtSpot, 65% for Tableau, and 55% for Power BI on typical enterprise workbooks. The remaining work is flagged explicitly in the pre-migration assessment scorecard. Coverage is higher for standard aggregation and chart patterns and lower for workbooks heavy on platform-specific filter logic or multi-source blends. The scorecard quantifies the gap before the engagement starts.

4. How does BrickShift handle row-level security and access control?

Access controls migrate as code into the Unity Catalog model, with a full audit trail. The exact coverage depends on the source platform and the customer’s existing access design; the assessment phase confirms what migrates automatically and what requires review.

5. How long does a typical migration take?

The assessment phase runs in days. A single business-unit slice with L1–L3 dashboards typically lands in four to eight weeks, including business-user validation. Estate-wide migrations vary by complexity-level distribution and the number of source platforms; most fall in a one to three quarter range, with the majority of analyst time concentrated on the L4 dashboards.

6. Is BrickShift a product or a service?

BrickShift is an accelerator delivered as part of a LatentView migration engagement that includes assessment, configuration tuning to customer-specific patterns, and analyst review of flagged items. It runs inside the customer’s Databricks environment, and customers retain the deployed accelerator after the engagement.