Looker (Google Cloud core) Migration

Google has been steering Looker customers from Looker (original) onto Looker (Google Cloud core) since the Google Cloud-hosted edition launched, and in 2026 most new capability, from Gemini in Looker to private networking, lands on core first. If you are still on a yourcompany.looker.com instance, a migration is in your future. Done well it is a controlled project with a rehearsed cutover; done badly it breaks every embed and every script the business depends on in one afternoon.

What actually changes

Authentication becomes Google sign-in. Looker (Google Cloud core) authenticates users through Google Cloud OAuth. Local Looker passwords go away, and SAML, LDAP or Google-Workspace sign-in configurations on the original instance need to be re-mapped to Google identities and Cloud Identity groups. Every user account, group membership and role assignment has to be reconciled against that new identity source.

The admin surface moves. Instance-level settings such as edition, region, maintenance windows, public or private IP, and network attachments live in the Google Cloud console rather than Looker's Admin panel. Looker's own Admin pages remain for connections, users, roles and content, but the split surprises teams who expect one place to look.

Networking options change. Core instances can be private-IP only, reach databases over VPC peering or Private Service Connect, and sit behind organization policies. Database allow-lists that were keyed to the original instance's egress IPs have to be redone, and PDT connections tested again.

The API host changes. Scripts, schedules, the Embed SDK configuration and CI pipelines all point at a new hostname. API keys are re-issued on the new instance. Anything still calling API 3.x has been broken since 2023 and needs rewriting on 4.0 as part of the move (see our field guide).

Content comes along, but not by magic. LookML projects move through Git. Looks, dashboards, boards, schedules, user attributes and folder permissions are exported and imported with Google's migration tooling and then verified. Embedded dashboards keyed by numeric ids need their ids re-mapped.

Our migration runbook

1. Inventory via the API. We script an inventory of the original instance: users, groups, roles, model sets, connections, projects, scheduled plans, user attributes, embed users and every dashboard referenced by an external system. This is the checklist the rest of the project is measured against.
2. Identity mapping. Each Looker user is mapped to a Google identity; groups to Cloud Identity groups; service users to dedicated accounts. Gaps (contractors on non-Google email, shared logins) are resolved before anything is provisioned.
3. Provision and connect. The core instance is created in the console with the right edition, region and networking. Connections are rebuilt with service accounts where the dialect supports them, and PDT builds are verified on each connection.
4. Code and content. Projects are attached to the same Git remotes and deployed. Content is migrated in a dry run first, and a reconciliation report compares dashboard counts, tile queries and schedule definitions between instances.
5. Embed and SSO rework. Signed-embed secrets, embed domains, user attributes and the Embed SDK initialization are updated and tested against a staging copy of your application before production is touched.
6. CI cutover. Deploy webhooks, LookML validators and SQL validation jobs are re-pointed at the new host and run green before the switch.
7. Cutover and rollback. The original instance stays read-only for an agreed window. DNS, links and schedules move together; if a blocker appears, the rollback is a configuration change, not a rebuild.

Timeline and fixed-fee assessment

A typical mid-sized instance (a few hundred users, a handful of embed integrations) migrates in four to eight weeks, with most of the elapsed time spent on identity mapping and embed testing rather than on Looker itself. We offer a fixed-fee migration assessment: one week to run the inventory, identify the blockers (unsupported auth configurations, custom networking, API 3.x dependencies, orphaned content) and give you a scoped plan with a firm estimate for the migration itself.

Vistelio is an independent Looker consultancy and is not affiliated with or endorsed by Google. Contact us to book an assessment.