Migrate the Domain, Not the Dashboard
In practice there isn’t one dashboard — there are dozens or hundreds, uneven in quality and usage, a handful carrying most of the traffic. Migration shouldn’t recreate them tile for tile. Our migration approach anchors on the ones that matter and captures the analytical domain beneath them — the fields, metrics, and relationships actually in use, plus what they depend on — modeled by question rather than by tile, so the result rebuilds what those dashboards show and answers the follow-ups they imply. How sharply it can tell used from merely defined depends on the context: with query logs or system activity (as Looker has), the trim is precise; otherwise the agent works from the semantic models and the SQL behind your key dashboards.How It Works
Migration is the fast path through Credible’s Capture and Enrich stages — you already have structured meaning, so the agent brings it in and readies it for AI, then hands it to the same Deliver path every model uses. It works from your model code (LookML, TMDL, a YAML model, a semantic-view definition), draws on query logs and dashboards for context, and — where the source exposes APIs or MCP tools — uses them to validate against the live model. Then it runs four steps:1
Read
Inventory the source model — tables, dimensions, measures, joins, and the logic buried in calculated fields and filters.
2
Translate
Map each concept to its Malloy equivalent — sources, joins, dimensions, measures, views — keeping the logic and dropping tool-specific presentation and performance constructs.
3
Enrich
Add
#(doc) and #(index) metadata tags — documenting what each field means and how to use it (units, rules, caveats) and indexing its values — so an agent finds the right field and uses it correctly.4
Validate
Where a connection is available, run the model against live data and compare it row-by-row to the source’s own engine — confirming a match before delivery.
What the Agent Keeps, Skips, and Flags
Not every line in a source model belongs in a semantic layer:
Presentation isn’t ignored where it carries meaning: number and currency formats become render tags, a conditional-format rule (“flag when churn tops 10%”) becomes model logic, and whole dashboards are rebuilt — often improved — as data apps. What’s genuinely dropped is what’s dead — stale, redundant, or unused — or pure tool plumbing with no meaning. Where Malloy expresses something differently — DAX filter context, table calculations,
metric_time — it’s re-worked explicitly, never dropped silently; each source guide spells out how.
Proving Parity
When there’s query access, the agent validates row-by-row — running each original metric through the source’s engine (or equivalent SQL against the same warehouse) and diffing it against the migrated Malloy. Matching numbers confirm the translation; but a source of truth can carry its own errors, ambiguities, and inconsistencies, so any delta is confirmed and flagged for deeper investigation, not silently reconciled. It produces a coverage report — modeled, renamed, deferred, or skipped, each with a reason — plus any discrepancies it surfaced.More Than a Reformat
A before/after looks like a translation — same metrics, cleaner syntax. That’s the fidelity check; the reasons to migrate are what the new model can do that the old one couldn’t:- It answers the next question. Malloy is composable — views nest, chain, and reuse as sources — so the model handles follow-ups the original dashboard never exposed.
- AI-usable meaning.
#(doc)and#(index)tags indexed by the Context Engine tell an agent what a field means, how to use it, and what values it holds — so it finds the right field and queries it correctly, not just by matching a name. - Correct by construction. Malloy’s symmetric aggregates stop measures double-counting across one-to-many joins — the silent bug in hand-written SQL and BI extracts.
- It’s real code, and it compiles. A typed language catches bad references and type mismatches at build time, not as wrong numbers in a dashboard — and it’s concise, turning sprawling DAX or LookML into a few readable lines.
- One model, every surface. One governed model serves agents over MCP, dashboards, data apps, and the REST APIs, with access control enforced everywhere — open, in Git, no lock-in.
A Worked Example
The payoff is a question the old dashboard couldn’t answer — say, how revenue is pacing against target. With the sales domain modeled and atargets source joined in, that’s one query:
Supported Sources
Each has a dedicated guide with a concept-to-Malloy mapping and a before/after: Looker, Sigma, Omni, Cube, Power BI, Tableau, Snowflake, dbt, and Databricks. Don’t see your tool? The same method applies to any semantic layer that exposes its definitions. Contact us and we’ll walk through it.Next Steps
Migrate from Looker
See the full method applied to LookML, end to end
Metadata & Discovery
How
#(doc) and #(index) tags make a model discoverable