Looker to Lightdash.
Without the chaos.
I've led BI migrations and reporting transformations at fintechs and scale-ups, including one of the largest Looker to Lightdash moves in Europe: audits, dbt fixes, training, governance, and the support channel where it all gets real. 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 Looker to Lightdash 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 audit you migrate everything, and six months later you have the same mess in a nicer tool. The audit is where the migration is won or lost.
The dbt layer breaks on the way over
"The chart worked in Looker. In Lightdash it just... returns nothing."
LookML and Lightdash YAML are not 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 in Looker."
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's included
Seven areas of work. The mix and depth depend on your estate, and we establish that in the assessment.
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
dbt Fixes & LookML-to-YAML 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
- LookML-to-YAML translation guides for your analytics engineers
- 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 Looker URLs to the right Lightdash 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
- Looker 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 YAML 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 Lightdash team, so your bugs reach their roadmap
- Dashboard lifecycle framework and runbooks handed over before I go
AI compresses the timeline.
Humans land the adoption.
I build AI tooling into the migration itself: a dashboard finder, redirect logic, LookML-to-YAML conversion assistants, and Claude Code skills your analysts run themselves to fix broken charts and explores. 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 Lightdash.
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 Lightdash API where possible. Your team inherits a living estate, not a snapshot from migration day.
This is the right fit if...
- Your Looker 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 Lightdash 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 Lightdash after go-live
- You want to keep Looker running in parallel indefinitely
Every migration is different. Let's talk about yours.
No two dashboard estates are the same, so I start with a Migration Assessment: two weeks to understand your estate, your team, and what a successful migration actually looks like for you. Everything else follows from there.
30-minute call. No obligation. I'll tell you honestly if this isn't the right fit.
The assessment is fixed-fee: £8,950 + VAT. If you don't see value in the first week, we stop, and you pay half.
Coming from Superset, Mode or Tableau instead of Looker? Same playbook, different source. Get in touch.