Migrate from Looker

Your LookML is years of encoded business logic — dimension definitions, measure formulas, join relationships, and the curation decisions behind them. Credible reads it as prior art and rebuilds the analytical domain as governed Malloy: the same metrics — validated to the row wherever a connection allows — plus the context an AI agent needs to answer the questions your explores couldn't.

LookML's UI patterns, Liquid templating, and performance-only constructs are identified and deliberately left behind.

What Credible Reads

The agent inventories your LookML project — manifest, model, view, and explore files — resolving manifest constants as it goes. Give it the .lkml files and it has what it needs; it can also work from dashboards and other unstructured context when that's all you have. How far validation goes depends on what else it can reach:

• LookML + live data — with a warehouse connection (and, optionally, the Looker API), LookML supplies the business context and the data validates each proposal against live results.
• LookML only — with no connection, LookML is the sole source of context and each proposal is flagged unvalidated until data confirms it.

What Comes Across

The everyday modeling carries over. Here's how the bigger pieces land — and where they get better:

The Migration Flow

What Credible Handles

• Liquid and HTML — {% … %} templating and html: conditional formatting are stripped; their intent is noted, and re-created as a renderer annotation only if it belongs in the model.
• Persistent derived tables — classified as transformation, aggregation, or performance-only. Perf-only PDTs are skipped in favor of querying the base table directly; real transformations become query-based sources.
• Refinements (+view) — consolidated into one definition rather than layered, so there's a single source of truth per field.
• Synthetic keys — a primary_key built from concat() or generate_uuid() is flagged so you can confirm the real grain instead of baking in a workaround.

Proving Parity

Two channels, used together:

1. Looker API — run the original explore through the API and compare. This requires the service account to satisfy the explore's required_access_grants, or restricted explores return 404 — so the agent preflights access first.
2. SQL against the same warehouse — run equivalent SQL directly against the warehouse the LookML reads and diff it against the Malloy result. This is the channel that validates the numbers in practice, with or without API access.

Before & After

A LookML view and explore:

view: orders {
  sql_table_name: sales.orders ;;

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

  dimension: status {
    label: "Order Status"
    description: "Current fulfillment status of the order"
    type: string
    sql: ${TABLE}.order_status ;;
  }

  dimension: order_size {
    type: string
    sql: CASE
           WHEN ${TABLE}.amount >= 100 THEN 'large'
           WHEN ${TABLE}.amount >= 20  THEN 'medium'
           ELSE 'small'
         END ;;
  }

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

  measure: order_count {
    type: count
    drill_fields: [order_id, status, created_date]   # dropped — UI only
  }

  measure: total_revenue {
    label: "Total Revenue"
    description: "Total revenue in USD"
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: usd
  }

  measure: cancelled_orders {
    type: count
    filters: [status: "cancelled"]
  }

  measure: cancellation_rate {
    type: number
    sql: 1.0 * ${cancelled_orders} / NULLIF(${order_count}, 0) * 100 ;;
    value_format_name: percent_1
    html: {% if value > 10 %}<span style="color:red">{{ rendered_value }}</span>{% endif %} ;;
  }
}

explore: orders {
  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }
}

The same domain in Malloy — one source, joins folded in, Liquid and drill fields dropped:

source: orders is conn.table('sales.orders') extend {
  primary_key: order_id
  join_one: customers is conn.table('sales.customers') on customer_id

  dimension:
    #(doc) Current fulfillment status of the order
    #(index)
    status is order_status

    #(doc) Order size bucket derived from amount
    order_size is
      pick 'large' when amount >= 100
      pick 'medium' when amount >= 20
      else 'small'

    #(doc) Date the order was placed
    created_date is created_at::date

  measure:
    #(doc) Number of orders
    order_count is count()

    #(doc) Total revenue in USD
    # currency
    total_revenue is sum(amount)

    #(doc) Orders that were cancelled
    cancelled_orders is count() { where: status = 'cancelled' }

    #(doc) Percentage of orders that were cancelled
    # percent
    cancellation_rate is cancelled_orders / order_count * 100

  view:
    #(doc) Monthly revenue trend with order counts
    monthly_revenue is {
      group_by: created_date.month
      aggregate: total_revenue, order_count
    }
}

The type: time dimension group becomes a single date dimension you truncate with .month/.year in a view — no enumerated timeframe list. drill_fields, the Liquid html: block, and value_format_name have no field-level model equivalent: drilling is implicit in Malloy, and formatting moves to # currency/# percent render tags.

More than a reformat. Off LookML, the model is AI-discoverable through the AI Analytics Engine, composes into questions your explores couldn't answer, and is open code you own rather than logic locked in Looker. See what you gain →

Next Steps