Migrate from Looker to Omni in Days, Not Months

You've decided to move from Looker to Omni. The concept is clear — Omni uses YAML instead of LookML, topics instead of explores, and gives your users a spreadsheet-like exploration layer that eliminates the "file a ticket to add a dimension" bottleneck.

The problem is getting there. You have hundreds of views, thousands of fields, complex joins, derived tables, access grants, and years of accumulated LookML that nobody fully understands. A manual migration takes months and introduces errors at every step.

We built a tool that compresses that timeline to days. Here's how it works and why the naive approach fails.

---

Why Simple Converters Don't Work

There are tools out there that convert LookML syntax to YAML syntax. Paste your LookML on the left, get YAML on the right. They handle the easy cases — renaming type: count to aggregate_type: count, converting sql: ${TABLE}.column to sql: column, swapping yes for true.

But syntax conversion is maybe 20% of a real migration. The other 80% is the hard stuff:

1. Dependency resolution. Field A's SQL references Field B. Field B references Field C. If you convert Field A without including B and C, the output is broken. In large LookML projects, these chains can be 5-6 levels deep. A simple converter doesn't trace them.

2. Access grants and row-level security. Your Looker instance has access_filter blocks, required_access_grants, user attribute-based column hiding, and Liquid templates that conditionally expose data. A syntax converter ignores all of this — and now your Omni instance has no security layer.

3. Messy LookML. We audit hundreds of Looker instances. Most have: views with no primary key, duplicated business logic across multiple views, abandoned derived tables that still get referenced, inconsistent naming conventions, and fields that use ${TABLE}.column in some places and raw SQL in others. A converter that assumes clean input produces garbage output.

4. Business context loss. Your LookML has descriptions, group labels, drill fields, and HTML formatting that encode years of institutional knowledge. Omni uses a different metadata model — AI context, synonyms, sample values, tags. A direct translation isn't enough; the metadata needs to be restructured for the new platform.

Our Approach: Near 1:1 Migration That Merges With Your Existing Schema

LookML and Omni's YAML schema are conceptually similar — views, dimensions, measures, joins. The structure maps almost 1:1. Our migrator takes advantage of that: it converts your LookML views file-by-file and merges the output with your existing Omni schema, so you can migrate incrementally without breaking what's already there.

How It Works

For each LookML view, the tool:

1. Parses the LookML using lkml — the same parser Looker uses internally.
2. Resolves dependencies recursively — if a field's SQL references other fields, they're auto-included. No broken references in the output.
3. Applies conversion rules covering dimensions, measures, dimension groups (dates), format mappings, and boolean syntax.
4. Generates AI-optimized metadata — every field gets a label, description, AI context block, and synonyms so your Omni instance is AI-ready from day one.
5. Merges with your existing Omni schema — the output doesn't overwrite what you've already built. New fields merge in, existing fields are preserved.
6. Produces a migration report — a detailed .migration.md with risk assessment, change log, and a list of anything that couldn't convert cleanly.

The conversion is near 1:1 for standard LookML. Dimensions, measures, dimension groups, primary keys, descriptions, formats — all convert automatically. The only things that need manual attention are Liquid templates (Omni uses Mustache syntax instead) and parameters (no direct Omni equivalent). These are flagged clearly in the report, never silently dropped.

Explore → Topic Mapping

After views are migrated, the tool handles your explores:

• Small explores (under 5 joins) map directly to a single Omni topic
• Medium explores (5-20 joins) get split into core + extended topics with suggestions for how to divide them
• Large explores (20+ joins) are flagged for architecture review — these are often the explores that were a mess in Looker too
• Join definitions translate with proper Omni syntax — relationship types, SQL ON clauses, and field lists
• Access grants at the explore level are detected and documented with user attributes and allowed values

What Makes It Different

It's a migration co-pilot, not a black box. The tool runs interactively with an AI agent (Claude) that explains each conversion, discusses tradeoffs, and handles edge cases conversationally. It's automated enough to handle 95%+ of standard fields without intervention, but interactive enough to get human input on the ambiguous cases.

It merges, not overwrites. Omni's schema layer auto-generates a base schema from your database tables — similar to Looker's autogenerated views but automatic. Our migrator merges your converted LookML on top of that existing schema, adding the business logic, labels, descriptions, and measures that Omni can't infer from the database alone.

It handles the mess. Most Looker instances aren't clean. Our tool doesn't assume they are. It flags missing primary keys as HIGH risk, detects duplicated business logic, identifies orphaned derived tables, and standardizes inconsistent naming — things a syntax converter can't do because it doesn't understand the semantics.

It generates richer metadata. Omni's AI features work best with rich metadata — AI context, synonyms, sample values. Our tool generates all of this automatically during migration, so your Omni instance is AI-ready from day one. This is something you'd never get from a manual migration because nobody would take the time to write AI context for thousands of fields by hand.

Conversion Rules at a Glance

Here are the core translations the tool applies automatically:

Looker	Omni	Notes
type: string	(removed)	Omni infers type from SQL + schema
type: count	aggregate_type: count	Type → aggregate_type
sql: ${TABLE}.col	sql: col	Redundant prefix removed
primary_key: yes	primary_key: true	Boolean syntax
hidden: yes	hidden: true	Boolean syntax
${view.field}	${view__field}	Cross-view reference syntax
value_format_name: usd	format: usdcurrency_2	Format name mapping
dimension_group	dimension with timeframes	Date handling restructured
html:	(flagged)	Omni uses different rendering
parameter:	(flagged)	No direct Omni equivalent
Liquid templates	(flagged)	Manual Mustache conversion needed

What the Output Looks Like

Input (LookML):

view: orders {
  sql_table_name: production.orders ;;

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
    description: "Unique order identifier"
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

  measure: total_revenue {
    type: sum
    sql: ${amount} ;;
    value_format_name: usd
    description: "Sum of order amounts in USD"
  }
}

Output (Omni YAML):

views:
  orders:
    sql_table_name: production.orders
    dimensions:
      order_id:
        primary_key: true
        sql: order_id
        label: "Order ID"
        description: "Unique order identifier"
        ai_context: |
          Primary key for the orders table. Unique per order.
          Use this to join to line items, payments, and fulfillment data.
        synonyms: [id, order_number]
      created:
        sql: created_at
        timeframes: [raw, date, week, month, year]
        label: "Created"
        description: "Timestamp when the order was placed"
    measures:
      total_revenue:
        aggregate_type: sum
        sql: ${amount}
        format: usdcurrency_2
        label: "Total Revenue"
        description: "Sum of order amounts in USD"
        ai_context: |
          Total revenue across all orders. Includes discounts.
          Does not include tax or shipping.
          Synonyms: sales, gross revenue, order total.

Clean, minimal, production-ready. No redundant SQL, no Looker-specific constructs. The type parameter is removed (Omni infers it), ${TABLE}. prefixes are stripped, booleans are converted, and every field gets AI-optimized metadata that makes Omni's natural language features work out of the box.

Getting Started

The migration doesn't have to be a big-bang cutover. The phased approach lets you:

1. Start with one domain — pick your simplest model set (e.g., product analytics) and migrate it end-to-end
2. Run Looker and Omni in parallel — validate results against your existing dashboards
3. Expand domain by domain — each migration builds confidence and surfaces patterns specific to your LookML
4. Decommission Looker when you're ready — not when you're forced to

For a free migration assessment — where we review your LookML codebase, estimate complexity, and give you a realistic timeline — visit our migration tool page or book a call directly.

---

Labs4Change has trained 16,000+ analytics engineers on Looker and built an AI-powered migration engine used in production. Book a free migration assessment to see how fast your migration can go.