Migrating from Looker

If you've built semantic models in Looker, you already understand the core concepts that Celiq implements — views, Explores, dimensions, measures, and row-level security. This guide maps every Looker concept to its Celiq equivalent and walks through a complete migration.

Concept mapping

LookML to CML translation

View → Node

view: orders {
  sql_table_name: public.orders ;;

  dimension: order_id {
    type: number
    sql: ${TABLE}.id ;;
  }

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

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.revenue ;;
    value_format_name: usd
  }

  measure: order_count {
    type: count
  }
}

node: orders
  dataset: orders
  dimensions:
    - name: order_id
      type: number
      sql: id
    - name: created_at
      type: time
      grains: [day, week, month, year]
      sql: created_at
  measures:
    - name: total_revenue
      type: sum
      sql: revenue
      format: currency
    - name: order_count
      type: count

Key differences:

• sql_table_name is replaced by dataset: (referencing a logical dataset)
• ${TABLE}.field becomes just field (or ${TABLE}.field is also accepted)
• dimension_group with timeframes becomes a single type: time dimension with grains:
• type: count works the same — no SQL expression needed

Explore → Domain

explore: orders {
  label: "E-commerce Orders"
  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.id} ;;
    relationship: many_to_one
  }
  join: products {
    type: left_outer
    sql_on: ${orders.product_id} = ${products.id} ;;
    relationship: many_to_one
  }
}

domain: ecommerce
  label: E-commerce Orders
  primary_node: orders
  joins:
    - node: customers
      type: left
      sql: "${orders.customer_id} = ${customers.id}"
      relationship: many_to_one
    - node: products
      type: left
      sql: "${orders.product_id} = ${products.id}"
      relationship: many_to_one

access_filter (RLS) → Data Key

explore: orders {
  access_filter: {
    field: orders.customer_region
    user_attribute: region
  }
}

node: orders
  data_keys:
    - field: customer_region
      user_attribute: region

Data Keys apply at the node level, not the domain level. They filter every query against the node, regardless of which domain the query comes from.

always_filter → default filters

Looker's always_filter applies a filter to all Explore queries. In Celiq, use Filter Mappings on a Reveal, or apply default filters in a Domain's default_filters block (see CML Reference).

Migration workflow

Step 0 — Decide: auto-import vs. manual

Celiq's Import tool can connect to your Looker instance and auto-generate CML nodes and domains from your LookML. This is the fastest path for large models.

Use auto-import when:

• Your LookML is well-structured with clear view/Explore separation
• You have more than ~20 views to migrate
• Your LookML doesn't use heavy PDT (persistent derived tables) logic

Use manual migration when:

• Your LookML has complex PDTs you need to redesign as nodes with pre-computed datasets
• You want to use the migration as an opportunity to clean up and simplify the model
• You want full control over the resulting CML structure

Step 1 — Inventory your Looker model

Before writing any CML:

1. List every Explore that is actively used (check query counts in Looker's usage data)
2. For each Explore, list the views it joins
3. Note any access_filter, sql_always_where, or required_access_grants
4. Identify PDTs — these need special handling (see below)

Step 2 — Map Explores to Domains

Each Looker Explore becomes one Celiq Domain. The Explore's base view becomes the Domain's primary_node.

If you have Explores that share the same base view but differ only in their joins, you have two options:

• Create one Domain with all possible joins and let Celiq prune unused ones at query time
• Create multiple Domains with different join sets (better for large models with performance concerns)

Step 3 — Convert Views to Nodes

For each LookML view:

1. Create the dataset (Lumen → Physical Layer → Datasets) or let Celiq auto-create it when you specify dataset: in the node and validate
2. Write the CML node, translating:

- measure → measures block

- dimension_group → single time dimension with grains:

- sql_table_name → dataset: field name

Run Check & Save in Forge after each node to catch errors early.

Step 4 — Handle PDTs

Looker PDTs (persistent derived tables) have no direct equivalent in Celiq. Your options:

Step 5 — Migrate security rules

For each Looker access_filter, add the equivalent data_keys: block to the corresponding CML node.

For required_access_grants, use Data Gates — field-level visibility controls based on user role.

Step 6 — Rebuild Looks as Prisms

Saved Looks become Prisms in Celiq. For high-priority Looks:

1. Open Discover and reproduce the query (select the same node/domain, dimensions, measures, filters)
2. Choose a visualisation and configure it
3. Save as a Prism
4. Recreate the folder structure as Vaults

For bulk migration, the Celiq API (POST /api/reveals) can programmatically create Prisms from query specs.

Step 7 — Rebuild Dashboards as Mosaics

Each Looker Dashboard becomes a Mosaic. Add tiles by selecting existing Prisms or creating inline Reveals.

Step 8 — Validate with Evals

Once the model is built, create Evals — prompt sets that test Orion's understanding of your domain. Good evals confirm that the semantic model correctly answers the questions your team actually asks.

Common pitfalls

Related pages

• Import from Looker or dbt — auto-import tool
• CML Reference — complete field reference
• Platform Architecture — how the layers fit together
• Semantic Layer Overview — nodes, domains, metrics
• Data Keys — row-level security
• Data Gates — field-level security