What you can export from Looker, and what stays behind
A renewal, an edition change or a hosting constraint is forcing you to plan a data extraction from Looker, so the first question is what you can actually take out. LookML model definitions leave through the project's Git repository, because each LookML project corresponds to a Git repository that Looker connects to over HTTPS or SSH. Query results and dashboards can be downloaded in documented formats, but only within the limits of each user's permissions. Looks and Explores download as TXT, Excel, CSV, JSON, HTML, Markdown or PNG, and dashboards download as PDF or CSV. The artifacts you collect are not a full copy of the Looker instance: user accounts, roles, schedules, folder structure and access rules are not part of them and must be recorded separately.
The download limits are the part most likely to surprise a migration team. Users with the download_with_limit permission can download at most 5,000 rows, or up to 50,000 if an administrator raised the visualization limit, and 50 columns. The download_without_limit permission allows more, subject to system or query limits. Confirm with your Looker administrator which account or service user will run the extraction, and whether that account holds the unlimited permission. Looker also cannot stream table calculations, so a full, unlimited result set requires removing table calculations from the query first. Those calculations then have to be rebuilt elsewhere, which is effort to plan for early.
Before you start, inventory what you need and where each piece lives. Treat the Git repository as the source of truth for modeling logic, and confirm you can read its full history and branches, not only the default branch. For dashboards and Looks, list the content by owner and folder, then decide which items need full data and which only need the logic behind them. Keep a record of each export, including the user, date, row count and any truncation, so you can show later that a figure in the new tool matches the original. The exported files are evidence and working material, not a replacement for the Looker instance, so plan the cutover around what the files can and cannot reproduce.
Which Looker content has a documented export path
This table lists each kind of Looker content, the format or route it can leave in, and the limits that apply. Read it before sizing an extraction plan, because row and column caps depend on the permissions your users hold. The main takeaway is that model code comes from Git, while query results and dashboards pass through Looker's download limits.
| Content | Documented export route | Formats or limits | What to confirm |
|---|---|---|---|
| LookML models | Git repository linked to the Looker project | GitHub, GitLab or Bitbucket over HTTPS or SSH | Repository ownership and branch used for production |
| Looks | Download from the Look | TXT, Excel, CSV, JSON, HTML, Markdown or PNG | Whether the user holds download_with_limit or download_without_limit |
| Explores | Download query results from the Explore | TXT, Excel, CSV, JSON, HTML, Markdown or PNG | Row and column caps applied to the query |
| Dashboards | Dashboard download | PDF or CSV | Whether PDF output matches the layout your reviewers expect |
| Standard row limit | download_with_limit permission | Up to 5,000 rows, or 50,000 if an admin raised the visualization limit | Current visualization limit set by your admin |
| Column limit | download_with_limit permission | Up to 50 columns | Wide extracts may need splitting into several queries |
| Unlimited downloads | download_without_limit permission | More rows, subject to system or query limits | Which system limits apply in your instance |
| Table calculations | Query design before download | Looker cannot stream them for unlimited results | Remove table calculations before extracting full result sets |
What does not leave Looker through standard downloads
Standard downloads move query results and dashboard snapshots, not the full state of a Looker deployment. The gaps below sit between what a user can download and what a migration team needs, so each one should be inventoried before the extraction plan is final.
Table calculations block unlimited downloads
Looker cannot stream table calculations, so any Look or Explore result that depends on one cannot be downloaded without a row cap. For an unlimited extract, the query must be rebuilt without table calculations, and the logic moved into the warehouse as SQL, a view or a dbt model. Illustrative example: a running total defined as a table calculation would need to be recreated as a window function in the source query. Confirm with your Looker admins which of your Looks use table calculations before scheduling any bulk export.
Downloads are not the warehouse data
A downloaded result is a snapshot of one query at one moment, shaped by row and column limits and by the filters applied at download time. It is not a copy of the underlying tables, and it does not carry the LookML joins, measures and filters that produced it. Teams that need full history should extract from the warehouse directly and use the LookML only as a definition reference. Confirm with your data team which source tables back each model before treating a CSV as a system of record.
Schedule settings stay behind
Scheduled deliveries, their recipients, cadence and filter values are configuration held inside Looker, and a file export does not carry them. A dashboard PDF or CSV captures the output of one run, not the rule that produced it. Record every active schedule from the admin or user views before cutover, and plan to recreate each one on the target stack. Confirm with Google Cloud or your Looker admin how schedule records can be listed for your edition.
Users, roles and permissions do not export
The download permissions that set row and column limits, along with user groups, role assignments and content access rules, live in Looker's admin configuration and not in the Git repository that holds LookML. The row limits described for download_with_limit and download_without_limit therefore have no direct equivalent in a file. Document the role-to-group mapping and the permission sets that matter to your extraction plan. Confirm with your Looker admins which settings are exportable from the admin console and which must be rebuilt.
Dashboard interactivity is lost in PDF and CSV
A dashboard PDF is a static render, so filter controls, drill-down paths, cross-filtering and tile-level interactions do not survive the download. A CSV captures a single tile's data only. Teams should record which dashboards depend on interactive filters and which users rely on drill paths, then rebuild those behaviors on the target BI tool rather than expecting them to carry over in an export. Confirm with the dashboard owners which views are used interactively before choosing the export format for each one.
How to run a complete Looker export in order
This sequence produces a verified, dated copy of your LookML models, query results and dashboard files, with a record that each export matches its source in Looker before any data leaves your control.
Inventory Looks, Explores and dashboards
A Looker admin lists every Look, Explore and dashboard that the export must cover, with its owner, folder, underlying model and last-run date. Keep the list in a spreadsheet or ticket so each item can be checked off later. This step is done when every item has an owner and a target format, and when the list is reviewed against the Looker folders the business still uses. Items that nobody claims are flagged for retirement decisions rather than silently dropped.
Confirm the Git connection and clone the LookML project
Each LookML project maps to a Git repository, and Looker connects to remote providers such as GitHub, GitLab or Bitbucket over HTTPS or SSH. A developer with access to the repository clones it locally and checks out the production branch that Looker deploys, not a feature branch. Confirm the Git connection settings in Looker's project configuration, then record the commit hash of the production branch. This step is done when the clone exists, the commit hash is written down, and the repository's model and view files match what Looker shows in development mode for a sample Explore.
Identify accounts with download_without_limit
A Looker admin reviews roles and permission sets to list which users hold download_without_limit and which hold only download_with_limit. Users with download_with_limit are capped at 5,000 rows, or up to 50,000 if an admin raised the visualization limit, and 50 columns, so a full extract needs an account with the broader permission or a query run under the right account. Document the account used for each export. This step is done when the extraction account is named, its permissions are confirmed in the admin console, and the account is logged for the audit trail.
Remove table calculations for full extracts
Looker cannot stream table calculations, so a query with them cannot return unlimited results. For each full extract, an analyst copies the Look or Explore, removes table calculations, and moves the logic into LookML measures or a warehouse view, or records it separately for rebuilding later. Keep the original Look unchanged so the business can compare results. This step is done when the working copy runs without table calculations and the removed logic is documented with its original formula.
Export results and dashboards in chosen formats
Looks and Explores download as TXT, Excel, CSV, JSON, HTML, Markdown or PNG, and dashboards download as PDF or CSV. The exporting user runs each query with the agreed account, selects the format that the receiving team needs, and saves files to a controlled location with names that include the Look ID and export date. Use CSV or JSON for data that must be reloaded elsewhere, and PDF or PNG for visual records. This step is done when every inventory item has at least one file in its target format.
Compare row counts against the source query
For each data export, the analyst reruns the source query in Looker and compares the row count and column count with the number of rows in the file. Any mismatch points to a row cap, a dropped column or a filter that changed between runs. Investigate and rerun the export before accepting it. This check is done when every file matches its source count, and each mismatch and its resolution is noted on the inventory list.
Record file hashes and the export manifest
Generate a SHA-256 hash for each exported file and record it, together with the row count, the Look or dashboard ID, the Git commit hash, the extraction account and the export date, in a manifest file. Store the manifest alongside the exports in a location separate from the Looker instance. A second person re-hashes a sample of files to confirm the manifest is accurate. This step is done when the manifest lists every file, the hashes match on re-check, and the manifest is stored under the same access controls as the data.
How to verify that an extract is complete before you rely on it
Treat every Looker extract as incomplete until you have checked it against the source. Looker's documented limits can cut a download short without an error that a reader would notice in a spreadsheet. Users with the download_with_limit permission can download at most 5,000 rows, or up to 50,000 if an admin raised the visualization limit, and at most 50 columns. Before you run a bulk extract, confirm which permission each exporting user holds and which row limit that permission applies. Record the limit next to each file, because a file that stops at exactly 5,000 or 50,000 rows is a signal that truncation happened, not that the data ends there.
Next, compare the extract with the Explore or Look it came from. Run the same query in the Explore, note the row count it reports, and compare that figure with the row count in the downloaded file. Count the columns too. If the query returns more than 50 columns, the extract cannot carry them all under the limit, so split the query or reduce the fields before exporting. Also check that table calculations were removed when you needed unlimited results, since Looker cannot stream table calculations and a query that still contains them will not return the full result set you expect.
Finally, sample metric values. Choose a small set of dimension values, such as one month or one region, and compare the totals in the export with the totals shown in Looker for the same filters. Keep the filters, time zone and user context identical on both sides, because a different permission set can change which rows a user sees. Store the check results with the extract, including the row limit, date, and the Looker user who ran it. Ask your Looker administrator to confirm the visualization limit currently set on the instance, since that setting determines the ceiling for each download.
What to plan before the Looker contract ends
Exporting from Looker is less a file transfer than a project with five connected parts: the hosting you run today, the content you must inventory, the period when old and new run side by side, the files you create along the way, and the warehouse logic that the dashboards depend on. Work through these before the renewal date so the extraction is not rushed.
Confirm the Looker edition and hosting
Looker (Google Cloud core) is hosted by Google in Google Cloud and is not offered for customer-hosted or multicloud environments. It comes in Standard, Enterprise and Embed editions, and the edition shapes which features and embedding paths your dashboards use. Record the edition, instance location and any embedded dashboards now, because each one changes the migration scope. Ask your Google Cloud account team to confirm the notice period, the data return terms and what happens to instance data after the contract ends.
Inventory Looks, Explores and dashboards
Export work starts with a list of every Look, Explore, dashboard, scheduled delivery and user-facing folder, with its owner and last-used date. Unused content is often the largest share of the list and is cheaper to retire than to move. Note which dashboards are sent as PDF or CSV by schedule, because those recipients depend on the delivery, not only the dashboard. Allow time for owners to confirm which items still matter, since that conversation usually takes longer than the export itself.
Plan the row and column limits
Users with the download_with_limit permission can download at most 5,000 rows, or up to 50,000 if an admin raised the visualization limit, and 50 columns. Users with download_without_limit get more, subject to system or query limits. Identify which extracts exceed these caps and which accounts hold the unlimited permission, since those accounts will do most of the bulk extraction. Looker also cannot stream table calculations, so unlimited downloads need the table calculations removed from the query first.
Run a parallel period for dashboards
Plan a period in which the same metrics are shown in Looker and in the replacement tool, and compare totals, filters and date ranges for each key dashboard. Differences usually come from timezone handling, null treatment or filter defaults rather than from the data itself. Agree in advance who signs off each dashboard and what counts as a match. Keep Looker available until every business owner has signed off, which means the contract end date should leave room for this comparison.
Govern exported files and their access
Exported CSV, Excel, PDF and JSON files copy data out of Looker's permission model, so they can be opened by people who could never query the source. Decide where extracts will be stored, who can read them, how long they are kept and how they are deleted. Map each export to a data classification and check whether any file contains personal or regulated data. Record the decisions in a retention schedule before the first bulk download runs.
Locate the warehouse and dbt logic
LookML models live in the Git repository connected to the Looker project, but the metric logic often depends on warehouse views, persistent derived tables and transformations in dbt or SQL. Export the LookML from version control, then trace which definitions point to tables your team maintains and which depend on Looker-only logic. The warehouse and dbt project will outlive Looker, so confirm who owns them and whether they are documented well enough to rebuild metrics without the original LookML.
Questions teams ask before exporting from Looker
How much effort does a full Looker export take?
The effort depends mostly on how much content exists and how it is built. The main drivers are the number of Looks, Explores and dashboards to rebuild or archive, the size and complexity of the LookML project, and how many query results need to leave Looker as files. Table calculations add work because Looker cannot stream them, so unlimited downloads require removing them from the query first. Ask for an inventory of content, users and scheduled deliveries before agreeing on scope, since that inventory sets the real size of the job. No duration is given here because none is supported by a researched source.
Does the download permission model change how much data can leave Looker?
Yes. Users with the download_with_limit permission can download at most 5,000 rows, or up to 50,000 if an administrator raised the visualization limit, and 50 columns. Users with download_without_limit can download more, subject to system or query limits. An extraction plan should list which accounts hold each permission, because a single unlimited user may be the only practical route for a large extract. Confirm the current limits in your own instance with your Looker admin, since they are set by permissions and configuration.
Can an internal team export from Looker without outside help?
Often yes for simple estates, but the work spans several roles that must agree on scope. A small team with a short content list, a clear LookML repository and a warehouse that already holds the data can usually handle downloads and Git cloning in-house. Larger estates with many Explores, complex table calculations or derived tables usually need a dedicated owner for the semantic layer rebuild. A fixed-scope engagement from DeployOpen can cover planning, implementation and documentation, with the written scope setting the deliverables and timelines before work starts.
What does an export need from Looker admins, Git owners and the warehouse team?
Each group holds a different piece of the export:
- Looker admins confirm user permissions, row and visualization limits, scheduled deliveries and which content is still in use.
- Git owners provide read access to the LookML project's remote repository, which Looker connects to over HTTPS or SSH, so the full model history can be cloned.
- The warehouse team confirms that the tables behind Looks, Explores and persistent derived tables exist and that they can be queried directly for the new BI layer.
Agree on these responsibilities in writing before any data moves, since a missing permission is a common cause of delay.
How long should a parallel run last before Looker is retired?
Plan the parallel run around the business reporting cycle, not a fixed number of days. Confirm with the owners of key dashboards which month-end, quarter-end or regulatory reports must match Looker output before the switch. Also confirm how many users and scheduled deliveries depend on Looker. Your team and the chosen partner should agree on exit criteria for each dashboard, and the Looker renewal date should leave enough room to finish those checks.
Can exported LookML run in another tool without rework?
Not as-is. LookML is Looker's modeling language, so the files in the project's Git repository can be copied and kept under version control, but other BI tools cannot execute them directly. The business logic, such as joins, measures and filters, must be rebuilt in the target tool or moved into the warehouse or dbt. Self-hosted Lightdash reads metrics from dbt YAML, while Apache Superset works with datasets and metrics defined on the database layer. Ask for a mapping of each LookML view, measure and Explore to its target before estimating the rework.
Who pays for the export, and what recurs after it is done?
Costs fall into one-time work and recurring running costs. One-time work includes content inventory, extracting files, cloning the LookML repository, rebuilding models and validating outputs. Recurring costs include hosting for the new BI tool, its metadata database and any caching layer, plus upgrades and support. Ask any provider to split the quote into these components and to state which items depend on the number of dashboards, users and warehouse size. For a Looker renewal comparison, include the Looker edition and user licenses that stop at exit.
When an export becomes a migration to Lightdash or Superset
A raw export keeps results but not the logic that produced them. A CSV or PDF from a Look or dashboard tells you what the numbers were on the day you pulled them, but it does not carry the LookML dimensions, measures, explores, joins or filters that defined them. If your goal is to keep running the same analysis somewhere else, the export is only the data half of the job. The model half lives in the LookML project, and that is where a migration plan has to start.
Teams moving to Lightdash need to translate LookML views, dimensions and measures into metrics in dbt YAML, and rebuild explores and joins as dbt models in the warehouse. Teams moving to Apache Superset need to rebuild those definitions as dataset metrics or warehouse views, and decide where governed logic will live, usually in dbt or SQL. Before you schedule any extraction, inventory the LookML files in the project's Git repository, list which measures and explores your dashboards depend on, and note any persistent derived tables that exist only inside Looker. Those items decide whether an export is enough or whether a conversion project is needed.
The sibling migration pages cover the conversion steps, so treat this one as the checkpoint that decides which path applies. Confirm with your analytics owners which dashboards must match Looker's numbers during a parallel run, and confirm with your data platform team where the transformed tables will be built and who maintains them. If those answers are unclear, the export work can proceed, but the migration scope should not be estimated until the semantic inventory is complete.
How DeployOpen works on this
DeployOpen plans and implements the export path for a Looker exit inside your own infrastructure, from LookML repository handling to the data extraction plan. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the Looks, Explores, dashboards and scheduled deliveries that must leave Looker, with owners for each
- Confirm which LookML projects and Git providers hold the model definitions to be exported
- Record the download permissions in use, including row and column limits that shape extraction volumes
How we build
- Set up the export pipeline that pulls LookML from version control and query results in the agreed formats
- Remove table calculations from queries that must return unlimited results before extraction runs
- Test exported datasets against Looker outputs on a sample of dashboards before any cutover
How we hand over
- Deliver written runbooks, export inventories and reconciliation reports for each agreed dashboard
- Document the export scripts, schedules and access controls so your team can rerun extractions
- Provide an evidence pack of export logs and checks that your compliance or audit teams can review
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Confirm the support hours, response terms and retainer scope in the written agreement
- Review the export outputs again when Looker or the target platform changes a supported version
