Skip to main content
Blog

You don't need to migrate those 300 dashboards

Real self-service means migrating logic, not dashboard UI.

You don't need to migrate those 300 dashboards

I recently spoke with a Head of Data who said they must migrate 300 dashboards from a legacy BI platform to Hex. I wanted to reach through the Zoom screen, take them by the hand, and softly say “No, you don’t.” But they were insistent. You spend weeks, months, years building something in one tool, and the thought of reorienting everyone on some new UI is likely your personal sleep demon.

The demon whispers that you have to bring them all. Because someday, someone will come asking for that one dashboard you built three years ago, and they’ll need it by noon.

The real value is the information encoded in your dashboards: metric definitions and the organizational truth everyone uses. Your drill paths and filters are entry points; what users actually want is to ask their question and get a trusted answer.

I think it’s time we reevaluate not just how to shop for AI analytics platforms but also what we should actually migrate to make self-service finally work.

A chance to rethink

When I hear someone say they must migrate 300 dashboards, what I’m actually hearing is they haven’t fully bought into the promise of AI. I get it! The ‘self-service’ pitch is one we’ve heard for years. But agents are remarkably good at analytical tasks, traversing large, cumbersome datasets and reading piles of context to produce an insight that would have taken someone weeks. Now, that doesn’t happen magically. It takes work organizing your context, and maybe your data if it’s truly a mess. But when you invest, the returns are real.

So when you’re at the precipice of this transformative technology, why are we clinging to the thing we’ve done and seen deliver (at best) mediocre adoption?

Dashboards provide security; they are semi-permanent and can be audited and governed. That’s incredibly appealing, and while I don’t subscribe to the “dashboards are dead” argument, I do think that they need to be demoted, as Charles Schaefer wrote. Demoted to something that’s useful for a specific use case but not applicable to everything.

The user who requested that dashboard needed an answer, and they didn’t have another option for how to get it. The better version is letting them ask their question with trusted data, do the analysis, and make a decision. That answer might result in a dashboard, a chat, or a slide deck. The opportunity to deliver insights shouldn’t be limited to dashboard-shaped outputs.

We shouldn’t bring all of a BI tool’s UI/UX baggage to AI. But the governed logic inside should come along.

So I don’t need to migrate anything?

Ok so you’re telling me to burn all my dashboards and just let everyone ask their questions in a prompt bar? Not quite. Some dashboards are worth migrating. Here’s how you can evaluate your current library to decide what to migrate and what to leave behind.

  • Look at your usage data to see which ones users actually check often. If something hasn’t been viewed in the past 60-90 days, you should seriously question migrating it.
  • Does it contain a metric that multiple people or teams check daily? If so, it’s a keeper; migrate it.
  • Was it a one-off ask? Those become dead weight and are never checked again; toss it.

I’ve done several migration projects in my career, and when you do, you realize the 80/20 rule is alive and well. Suddenly, that list of 300 feels a lot more manageable — and worth the migration effort.

AI can help you move the dashboards you deem worthy. I’ve developed a BI migration skill that translates your BI dashboard into Hex data apps, with the same layout and logic. Once you’ve aligned on what’s worth moving, the timeline is days, not months.

Your AI analytics agents should support the rest, letting users ask one-off questions without ever opening a ticket.

Migrate the logic, not all of the dashboards

AI can take the wheel in writing SQL or Python, but it needs guidance toward trusted data and proper calculations. If we step back, that’s exactly what we do inside our BI dashboards. We should also migrate the knowledge and truth inside them.

At Hex, we’re building AI analytics that operate on top of your organization’s knowledge, which should include your dashboard logic. Each data connection may map to a semantic model or a markdown guide, and each critical dashboard becomes context for the agent to reason about, letting your users ask quick questions from the same foundation.

Governance is managed not just by gating who can see which dashboard, but by access to the foundational context your data team maintains. Visibility into what users are asking and the context they’re using becomes the way your data team measures and improves agent quality.

Use AI to extract logic and translate it into your context. Most BI tools expose the data connection and dashboard metrics as YAML or XML files that your coding agent of choice can easily parse. Then you ask it to translate those metrics and joins into scalable context.

That ability is baked into the BI migration skill I mentioned above. Dozens more are available because the translation tax is now trivial. The harder part is aligning on your context strategy and breaking the habit of making everything a dashboard.

300 dashboards isn’t self-service

When we continue to tie ourselves to the old ways, we’re limiting what’s possible in this era of AI. If what you had was so compelling, you wouldn’t be leaving. You’re leaving because you already know what your users need, and it was never 300 dashboards. It was the answer underneath each one. Bring that.

Join us on October 27th at Prompt, our first-ever customer conference.