Any BI platform.
Without the chaos.
Looker, Superset, Tableau or Mode: the tool is not the hard part, adoption is. I have led BI migrations at fintechs and scale-ups, including one of the largest Looker to Lightdash moves in Europe. I resell no platform, so the tool call is made on merit, not commission. Migrations fail at adoption, not architecture. I handle both.
Aggregated across consulting engagements at fintechs and scale-ups. Happy to walk through the detail on a call.
Why most BI migrations stall
The technical move is the easy part. These four problems are what actually kill it. I have heard every one of these sentences in real life.
Nobody knows what to migrate
"Which of these 600 dashboards do people actually use? Honestly? No idea."
Without a proper diagnosis you migrate everything, and six months later you have the same mess in a nicer tool. The diagnosis is where the migration is won or lost.
The model layer breaks on the way over
"The chart worked in the old tool. In the new one it just... returns nothing."
Source and target are never the same language. Missing joins, fanouts, dimensions that never existed in dbt. Someone has to fix these at the model layer, and that someone is usually a very annoyed engineer.
Analysts quietly go back to the old tool
"I watched the training video. I still build my charts where I always did."
A one-hour webinar and a wiki page is not change management. If analysts are not confident in the new tool within their first session, they will find a way around it. Usually Excel.
Governance disappears on day one
"Who owns this dashboard?" "The person who left in March."
A migration is the one chance to give every dashboard a named owner and a lifecycle. Skip it and the new estate becomes a graveyard, just like the old one.
What the research actually says
The tool is rarely the problem. Adoption is.
This is not just my opinion from the field. The industry numbers say the same thing: buying, or re-buying, a BI platform does very little on its own. The value shows up only if people actually use it, and most of the time they do not.
~29%
of employees actually use the BI tools their employer pays for. Adoption has sat around the 25–30% mark for roughly seven years, barely moving.
Source: BARC / Gartner adoption research80%+
of data-migration projects run over time or over budget, with cost overruns averaging around 30%. A new tool does not fix a problem the old tool did not cause.
Source: industry migration-cost benchmarks16%
of organisations reach full dashboard adoption on a leading BI platform. Most of the estate is built, paid for, and then quietly ignored.
Source: Gartner, BI & analytics adoption surveyOne honest note on the numbers
You will see “60–70% of dashboards go unused, per Gartner” quoted everywhere. I have looked: it does not trace to any Gartner publication, it traces back to a social-media post. The real, defensible figure is the adoption ceiling above, and it is bad enough on its own. I would rather give you a number you can check than one that sounds good in a pitch deck.
What's included
Seven areas of work, run by a written operating system. The mix and depth depend on your estate; the diagnosis establishes both.
Dashboard Audit & Triage
- Full inventory of every dashboard: active, dormant, duplicate
- Usage data cross-referenced with stakeholder interviews
- A KEEP / MIGRATE / ARCHIVE decision for each report
- Ownership assigned before a single dashboard moves
Model-Layer Fixes & Syntax Conversion
- Root-cause analysis of broken explores and chart failures
- Direct PRs into your dbt repositories. I fix at the model layer, not with workarounds
- Source-to-target translation guides for your analytics engineers, LookML to YAML at Wise
- A self-serve fix workflow so your team can convert independently
Internal Tooling & AI Skills
- A dashboard finder so analysts locate the new home of any migrated report instantly
- Redirect logic from old tool URLs to the right new content
- A live migration status site, so nobody asks "where are we?" twice
- Custom Claude Code skills analysts run themselves to fix charts, fix explores and migrate looks
Programme Management & Comms
- Migration timeline owned end to end: batches, redirects, account deactivations
- A live migration status site so everyone knows where things stand
- Company-wide announcements written and sent at every milestone
- The old tool's contract sunset coordinated so you stop paying for two tools
Analyst Training & Enablement
- Structured curriculum from first login to power user
- Live hands-on sessions. Analysts ship their first real chart in about 90 minutes
- A train-the-trainer Ambassador programme so adoption keeps spreading after I leave
- AI-assisted workflows taught alongside the tool itself
Documentation & Knowledge Base
- Beginner, intermediate and advanced training paths
- Migration playbooks: go-live readiness, common issues, manual fix guides
- A troubleshooting cheat sheet your analysts will actually use
- It all lives in your wiki, not mine. You keep everything
Support, Incidents & Governance Handover
- I sit in your analyst support channel during the migration and answer the hard questions
- Incident response owned end to end, including rollback and comms when a vendor bug bites
- A direct escalation channel with the target tool's team, so your bugs reach their roadmap
- Dashboard lifecycle framework and runbooks handed over before I go
The same operating system, every migration
Whatever the source tool, a migration runs on a written operating system, not my memory: ten phases, one repeatable core, rules that do not change. Your team inherits the machine, not just the outcome.
One authoritative tracker: every asset, owner, usage number.
KEEP / HOLD / DELETE with named owners. Effort follows value.
A converter owns the bulk. Humans own the exceptions.
Fixed weekly cadence. Predictability over speed.
Diagnose, fix at the model layer, PR, merge. The core unit.
One front door, and a FAQ to docs to skills flywheel.
Train-the-trainer, until tribes fix their own dashboards.
Phased off-boarding, redirects, account deactivation.
Lifecycle states and ownership, so it stays healthy.
The machine keeps running after I leave.
The Fix Loop: the core repeatable unit
Every broken migrated dashboard goes through the same loop: diagnose against the source, fix at the model layer, PR, merge, confirm with the reporter. Master this loop and most of the job is muscle memory. A few real rows from the diagnosis tree:
| Symptom | Fix layer |
|---|---|
| "Unknown field id" after the move | Model layer: rename or re-add, or repoint the chart |
| Inflated or duplicated numbers | Model layer: fix the join grain |
| Chart empty, a field is missing | Model layer: add the join |
| Filters or chart type look off | Target UI or an AI fix-skill, no PR needed |
Positions, not people
The migration is run as a set of position contracts, so it can be handed off one contract at a time and pointed at any tool. Early on one person may hold several positions; the contracts stay separate on purpose.
The DRI owns the machine, not the charts: timeline, cadence, comms, cutover. Tribe ambassadors own their own dashboards. The vendor gets one channel, not twenty voices.
Rules the machine follows
If the same question is answered twice, it becomes documentation. If the same fix happens three times, it becomes a skill or a script. You are not paid to answer the same question twice; you are paid to make the second answer unnecessary.
Never paper over a model-layer bug in the UI. And never invent business logic: if a field was commented out and nobody knows why, the owner decides. I do not guess.
A tool's "no changes" signal is not proof of no changes. Bulk re-migrations over live dashboards need a real diff and an owner heads-up. Learnt the hard way at Wise, encoded forever.
If in week ten I am still fixing charts myself, the enablement has failed. Fix the system, not the chart. The point is a machine that runs without me.
Converter error count
Support questions per released dashboard
Fixes done at tribe layer, not central
AI compresses the timeline.
Humans land the adoption.
I build AI tooling into the migration itself: a dashboard finder, redirect logic, and Claude Code skills your analysts run themselves to fix broken charts. The mechanical work gets faster, which leaves time for the part machines cannot do: getting hundreds of people to trust a new tool.
The training covers this too. Your analysts leave knowing how to work with AI agents on real analytics problems, not just how to click around the new tool.
Migration tooling built from scratch
Dashboard finder, redirect logic, a live migration status site, custom Claude Code skills. All built for your estate.
Knowledge base handed over on exit
Beginner to power-user documentation, ambassador toolkit, governance runbooks. Lives in your Confluence, not mine.
Analysts production-ready fast
Hands-on sessions built for speed. Analysts go from zero to shipping their first chart in about 90 minutes.
The migration doesn't end at go-live
Without a lifecycle, a migrated estate turns back into a graveyard within months. I design the governance layer before I leave, so it doesn't.
Work in progress. Not yet ready for business users.
Reviewed, owned, and trusted. The badge that matters.
Hasn't been touched in a while. Needs review before use.
No longer active. Out of the way, not deleted.
Every dashboard enters a lifecycle and gets a named owner, with a resolution chain for when that owner leaves. Stage transitions run through the target tool's API where possible. Your team inherits a living estate, not a snapshot from migration day.
Free to use
Size the work before you talk to anyone
Most migration quotes start with a guess at how much is in there. These read the files and tell you. They run in your browser, so nothing is uploaded and you do not need a connection to anything.
This is the right fit if...
- Your current BI tool's renewal is approaching and the invoice is getting hard to justify
- Your dbt models are already in place. You need the BI layer to move, not a data platform rebuild
- You have hundreds of dashboards and no honest answer to "which ones matter?"
- A previous migration attempt stalled at adoption, not architecture
- You need analysts productive in the new tool in weeks, not quarters
This is not the right fit if...
- You want someone to clear a Jira backlog of migration tickets
- Your dbt models don't exist yet. The data engineering layer has to come first
- You need a permanent resource to run the new tool after go-live
- You want to keep the old tool running in parallel indefinitely
Every migration is different. Let's talk about yours.
No two estates are the same, so every migration starts with the diagnosis: two weeks to understand your estate and what a successful migration looks like for you. Everything else follows.
30-minute call, no obligation. If it isn't the right fit, I'll say so.
The diagnosis is fixed-fee and scoped in advance. If you don't see value in the first week, we stop, and you pay half.
The diagnosis is the same fixed-fee entry for every engagement. Tool-agnostic: Looker, Superset, Tableau or Mode out; Lightdash or your target in.