Leave Looker with your logic intact.

Looker compiles your LookML into SQL for every tile it renders, and Papercrane extracts it: the query behind each tile, the dashboard layout, the visualization configs. The agent rebuilds your dashboards from that, as code you own.

See what gets extracted

Connects with a Looker API key. Everything Papercrane does in your Looker instance is read only.

Connect in about a minute. Free to connect and ask. Paid plans start when you publish a dashboard. See pricing

Every Looker migration plan dies in the same three places

Nobody knows what is in there.

Hundreds of dashboards and looks, built over years by people who left. The audit alone can stall the project before it starts.

The logic lives in the model.

Ten years of business definitions sit in LookML. Every migration plan begins with translating them into the next tool's modeling language, and that is the quarter that never ends.

The rebuild feels like starting over.

A blank canvas in a new tool, recreating every tile by eye from a screenshot of the old one.

Here is the part those plans miss: Looker already resolved your model. Every tile on every dashboard has finished SQL behind it, with the joins, filters, and measures compiled in. You do not need to translate LookML to move a dashboard. You need the SQL it produced.

One tile, taken apart

In Looker

Revenue by region

One tile on one dashboard, the way viewers see it today.

What Papercrane extracts

SELECT
    region.name  AS "region.name",
    COALESCE(SUM(order_items.sale_price), 0)
      AS "order_items.total_revenue"
FROM analytics.order_items AS order_items
LEFT JOIN analytics.orders AS orders
    ON order_items.order_id = orders.id
LEFT JOIN analytics.regions AS region
    ON orders.region_id = region.id
WHERE orders.created_at >= DATE_TRUNC(
    'quarter', CURRENT_DATE)
GROUP BY 1
ORDER BY 2 DESC
LIMIT 500

viz

type: "looker_bar", value_labels: true

position

row 2, col 1, width 6

LookML's whole job was to write this query. It is still your logic, in a language every tool speaks.

Rebuilt, code you own

Revenue by region

Live

Same query, same warehouse, now a tile on a dashboard you can export to your own repo.

This is what the connection returns for a single tile: the generated SQL with your model's logic already compiled in, the visualization type and its configuration, and where the tile sits on the dashboard. The agent rebuilds from these, pointed at the same warehouse Looker queries today.

Ask your Looker estate anything before you move it

Connecting and asking is free. Before you commit to migrating anything, find out what you actually have.

Inventory every dashboard and look in the Finance folder

Show me the SQL behind the pipeline coverage tile on the exec dashboard

Which dashboards still query the old orders table?

List every look that filters on region, with its query

Rebuild the weekly revenue dashboard here, and blend in the targets from our planning spreadsheet

joins Looker and a spreadsheet

Three steps, no blank page

STEP 1

Connect and map.

Add a Looker API key. The agent browses your folders, looks, and dashboards and builds an inventory you can question.

STEP 2

Pick a dashboard. The agent rebuilds it.

It pulls the layout, the generated SQL behind each tile, and the visualization configs, then recreates the dashboard against your warehouse connection: BigQuery, Postgres, wherever the data already lives. The queries are not regenerated from scratch: the extracted SQL is the starting point, and the extracted configs decide chart types and placement.

STEP 3

Publish when it is right.

Share by link, embed it in your product, or put it on your own domain. When a dashboard breaks later, the error routes back to the agent, so it gets fixed instead of quietly rotting.

The straight answer on what transfers

From your Looker instance	Carries over?	Note
Dashboard layout and tile arrangement	Yes	Extracted per dashboard
The query behind every tile	Yes	Generated SQL, with LookML logic compiled in
Visualization types and configurations	Yes	Chart types, series, formatting settings
Folder, look, and query inventory	Yes	Browsable and searchable from chat
LookML model files	Not needed	Migration starts from the compiled SQL, not the model source
Persistent derived tables	Decision required	The real risk row. Tile SQL that reads from a PDT references Looker's scratch schema, and other PDTs may build on it. See the PDT answer in the FAQ
User permissions and row level access	No	Papercrane has its own sharing model; access rules are set up fresh
Schedules and alerts	Recreated	Rebuilt as Papercrane scheduled tasks, not imported
The Explore self serve experience	No	Papercrane rebuilds dashboards, not a governed exploration surface

When staying on Looker is the right call

If you have a staffed LookML team and hundreds of business users running their own Explores against a governed model every day, Looker's semantic layer is doing exactly what it was built for, and nothing here replaces that. The same goes if your contract rides inside a broader Google Cloud commitment that works for you. Papercrane is the move when the dashboards matter more than the model: when what your company actually uses is a few dozen dashboards, one overloaded LookML developer, and a renewal that is getting hard to justify.