How to Migrate From Dashboard Sprawl to an AI Data Analyst

You do not migrate off dashboards. You migrate the questions dashboards were never good at. The fixed KPI everyone checks each morning stays on a chart. The open-ended "why did this move" question, the one that today becomes a ticket and a two-day wait, moves to an AI data analyst. Said in one line you can quote: keep the dashboards that answer a known question, route the unknown questions to an agent that investigates them and shows its work. This page is the practical plan for making that move without ripping anything out.

Key takeaways

• This is not a rip-and-replace. A dashboard is still the right surface for a fixed KPI, and dashboard sprawl is not solved by deleting dashboards. It is solved by routing the ad-hoc questions somewhere else.
• The thing you actually migrate is the ad-hoc request queue: the "why did churn spike in this segment" question that today becomes a ticket. That moves to an AI data analyst that runs the investigation read-only and shows its work.
• The migration has a clear order: pick the questions to move first, build the semantic layer so the agent uses your real definitions, encode your recurring methods as playbooks, then open it to business users read-only.
• The analyst role transforms in the process. The job shifts from answering query requests to architecting the context and the playbooks, and a team likely needs fewer analysts doing manual pulls.

---

What are you actually migrating?

You are migrating the ad-hoc question queue, not the dashboards. Most teams hear "migrate off dashboards" and picture deleting a library of charts. That is the wrong frame, and it is why dashboard migrations stall.

A dashboard answers a question someone already thought of and built a chart for. For a fixed KPI everyone watches, like today's revenue or this week's signups, that is the easy, right place to work, and it should stay exactly where it is. We have made the full case for that in dashboards are not dying.

The part that needs to move is the question a dashboard was never built to answer. You want weekly active users among U.S. iOS users who are male and between 13 and 17. That can take four dashboards stitched together, and there is no fast way to drill in, so you file a request and wait. That request, multiplied across every team, is the BI backlog. The backlog is what you migrate.

Here is the split, stated plainly, so you know what stays and what moves:

Why dashboard sprawl is the symptom, not the disease

Dashboard sprawl is what happens when the only tool you have for a new question is a new dashboard. Every fresh question that is a little different from an existing chart becomes a request to build another one. The library grows into the hundreds, and nobody can find the chart that holds the answer they need. The sprawl is real, but deleting charts does not fix it, because the demand that created them is still there.

Mighty Networks is the clean version of this. Their Hosts, the people who run communities on the platform, earned over $500M in 2025, and the company had built hundreds of Looker dashboards. The dashboards had the answers. The team could not surface them fast enough to act.

As founder and CEO Gina Bianchini put it, "no CEO should be a victim of dashboard sprawl." The fix was not fewer dashboards. It was a different tool for the questions that kept spawning new ones, which surfaced three insights that reset their product roadmap, like which Host behaviors in the first 30 days predict whether a community is still thriving a year later.

Dashboard sprawl is not too many dashboards. It is too many questions arriving at a tool that can only answer them by building yet another dashboard.

The migration, step by step

Migrate in four steps, in order, and ship value after each one. You do not flip a switch. Each step stands on its own, so a team can stop after step two and still be better off, and nothing existing breaks while you go.

1. Pick the first questions to move. Look at your ad-hoc request queue and list the questions that come up over and over: why a metric dropped, whether growth is healthy, how an experiment read out, which funnel stage to fix. These are the ones a dashboard cannot answer and an analyst keeps re-investigating by hand. Start there, not with a novel one-off.
2. Build the semantic layer. This is the foundation, and it is the step teams are tempted to skip. A semantic layer holds the official definition of every metric, how your tables relate, and which source is the truth. Without it, the agent guesses what "active customer" means and can write a query that runs cleanly while measuring the wrong thing. With it, every answer reflects how your company actually defines things. The semantic layer is the core of the broader context layer the agent reads from. Most "AI on your data" tools assume you already built this layer and only read it. Sundial works either way. If you already have a governed semantic layer, whether dbt MetricFlow, Cube, or Looker's LookML, Sundial reads from it and works with it. If you do not, Sundial's Modeling Agent builds one for you, transforming your raw tables into clean, analysis-ready pipelines and a semantic layer that is Sundial's own, built as an extension of dbt MetricFlow so it stays open and standards-based rather than a proprietary lock-in. Everything is git-backed, so the definitions live in your own repo and you own your data models, not a vendor.
3. Encode your recurring methods as playbooks. An analytics playbook is the recorded method for a recurring question: the steps a senior analyst would take, written down once so the agent runs the same rigorous investigation every time instead of improvising. Sundial ships 20+ horizontal playbooks for the patterns common across businesses (metric-change diagnosis, retention, funnel conversion, growth accounting, experiment readout), and your team adds its own for the questions specific to how you operate.
4. Open it to business users, read-only. Once the definitions and methods are in place, let the people who ask questions ask directly, in Slack or Teams, the way they would ask a human analyst. For business users the agent is read-only by default: they get answers and cannot change the data, so a marketer or a VP cannot break anything by asking.

The order matters. Skipping step two to get to step four faster is the most common mistake, and it produces confident answers built on the wrong definitions. Meaning before method, method before access.

What de-risks the switch is the system Sundial builds around the model. Call it scaffolding as a service: the governed context layer, the encoded playbooks, the data-quality checks, the shown work, the confidence signal, and the audit trail are what make AI analysis safe to trust. Sundial's own analysts encode their methods into the playbooks the agents run, and Sundial stands behind that reliability.

The model is the engine. The scaffolding is what keeps a migration from landing you on confident, wrong answers.

How the agent answers the questions you moved

The shift is from a tool that draws charts to an analyst that investigates. You ask a question in plain language. The agent plans an investigation, runs the queries itself, checks its own work, revises, and hands back an answer with the reasoning attached.

This is agentic analytics: not a dashboard you read, and not a chatbot that turns one sentence into one query. One query answers a shallow question like "what was revenue last week." A question like "why did revenue drop last week" is a dozen queries plus the judgment to know which ones matter.

At OpenAI, a sudden drop in conversion used to mean one to two full days of an analyst's time doing exactly that, manual pulls across scattered systems and complex SQL to test one hypothesis at a time. With Sundial, the same investigation runs automatically and surfaces whether the decline ties to a particular country, platform, or user segment in seconds rather than days.

The dashboard still shows the drop. The agent answers the why, and it shows every step so a data person can audit how it got there.

The work splits across four jobs a human analyst does without thinking, and Sundial runs a named agent for each: the Quality Agent (is the underlying data fresh and complete enough to trust, and what should you capture next), the Modeling Agent (works with the governed semantic layer you already have, or transforms raw tables into clean pipelines and builds one you own, so the metrics and entities mean one thing), the Analysis agent (the chain of queries that gets to why, run against your warehouse using the playbooks), and the Storytelling Agent (turning the result into a narrative a decision-maker can act on).

Having the modeling, quality, and analysis agents together is the differentiator. Most tools assume the layer already exists rather than building it for you.

What happens to the dashboards you keep

The dashboards you keep do not change, and you do not run two separate tools. A common worry in this migration is ending up with a dashboard product for the fixed KPIs and a separate agent for everything else, which just adds a tool. That is not the shape. Sundial has dashboard capabilities too, so the fixed views live in the same place as the agent. You get the chart everyone watches and the ask-anything investigation in one tool, not a stitched-together pair.

So the migration narrows your dashboard library rather than ending it. The charts that earn their keep are the ones a team genuinely checks on a schedule: the morning KPI, the metrics that have to tie out exactly like a financial close. The hundreds of one-off dashboards built to answer a single past question stop multiplying, because the next version of that question goes to the agent instead of becoming dashboard number 347.

How the analyst role changes

The migration reshapes the analyst's job, and a team likely needs fewer analysts doing manual pulls. Say this plainly rather than dancing around it. The agent can do much of what analysts used to spend their days on: the repetitive pulls and the first-pass investigation. So the work moves off the request queue and onto building the system that answers everyone's questions.

The new job is architecting the context and the methods: defining the metrics, the relationships, and the source of truth in the semantic layer, and authoring the playbooks that encode how your team investigates each recurring question.

Data practitioners use the same agent to do more than business users: it is the one tool that can both model the tables and run data-quality checks, so the people who own the data build and maintain the context layer everyone else relies on. Humans stay in the loop on judgment and the highest-stakes calls.

Character got a level of customer understanding in a few weeks that would otherwise have taken six to twelve months, which freed the data science team for harder problems. Gamma delayed building a full data team because the platform handled much of the engineering and analytics work, keeping a 28-person company lean as it grew past 50 million users.

The role did not disappear. It moved up a level.

How to know the migration worked

You measure the migration by what leaves the queue, not by how many dashboards you deleted. A few concrete signals that the move landed:

• The ad-hoc request queue shrinks. The "why did churn spike in this segment" tickets that used to wait two days are answered directly, in minutes. At OpenAI, root-cause investigations dropped from two to three days of analyst effort to minutes.
• Non-technical people get their own answers. Product, go-to-market, and operations people ask questions without learning SQL or filing a request. At Gamma, every product decision-maker became their own analyst.
• The dashboards that remain are the ones people actually use. The library stops growing by hundreds, because new questions route to the agent instead of spawning a new chart.
• You can still check every answer. The agent shows its work and a confidence signal, so a decision-maker knows a solid diagnosis from a rough read, and the data team keeps an audit trail of what ran across the company. A confident wrong answer is more dangerous than a slow one, so checkability is part of "it worked," not a nice-to-have.

What to be careful about

Two places need a human, not an agent, even after a clean migration. Reach for the agent on the recurring analysis that today becomes a ticket. Be more deliberate here:

• Governed reporting where every number has to tie out exactly, like the financial close. Keep a human signing off. Use the agent to do the legwork, then have a person make the highest-stakes call. This is a question to keep on a reviewed dashboard, not migrate.
• Genuinely novel, bespoke questions that no established method fits yet. The agent can still investigate, but you are leaning on its general reasoning rather than an encoded playbook, so check the work more closely before acting on it.

And do not skip the semantic layer to move faster. An investigation built on the wrong definitions fails three steps in where no one would catch it, because each answer reads as confident and complete.

Migrate the questions, not the charts. Keep the dashboard for the KPI that never changes, move the "why" to an agent, and put a human on the numbers that must tie out exactly.

Frequently asked questions

Do I have to delete my dashboards to migrate to an AI data analyst? No. A dashboard is still the right surface for a fixed KPI everyone watches, like today's revenue, and for numbers that must tie out exactly, like a financial close. You migrate the ad-hoc "why did this move" questions that today become a ticket, not the charts. Sundial has dashboard capabilities too, so the fixed views and the ask-anything agent live in one tool rather than two.

What is the first step? Pick the recurring questions clogging your ad-hoc request queue (why a metric dropped, whether growth is healthy, how an experiment read out), then build the semantic layer so the agent uses your real metric definitions. Get the definitions right before you wire up the methods, and the methods right before you open access.

Why can't I just point an AI at my warehouse and skip the semantic layer? Because without governed definitions the model guesses what "active customer" means and can write a query that runs cleanly while measuring the wrong thing. The semantic layer is the foundation that keeps every answer grounded in how your company actually defines things. Skipping it is the most common reason a migration produces confident, wrong answers.

Is this safe to open to non-technical people? Yes, because of who can do what. For business users, the people asking questions, the agent is read-only by default: they get answers and cannot change the data. Data practitioners use the same agent to do more, modeling the tables and running data-quality checks, so they build and maintain the context layer the business users rely on.

Does this replace my BI tool, like Tableau, Looker, or Power BI? As of 2026, those are BI and dashboarding tools, good at the fixed, known question. An AI data analyst is for the open-ended question that today becomes a ticket. You do not have to run a separate dashboard tool for KPIs and Sundial for everything else: Sundial gives you the fixed dashboard views and the ask-anything investigation in one place.

What happens to my data analysts? The role transforms, and a team likely needs fewer analysts doing manual pulls. The agent handles much of the repetitive pulls and first-pass investigation, so the job shifts from answering query requests to architecting the context and authoring the playbooks, the metrics, relationships, source of truth, and methods, so everyone's questions get high-quality answers. Humans stay in the loop on judgment and the highest-stakes calls.

How do I know it worked? The ad-hoc request queue shrinks, non-technical people get their own answers in minutes, the dashboard library stops growing by hundreds, and every answer still carries shown work, a confidence signal, and an audit trail you can check.

See what the move looks like at Sundial.