TSA Exit Acceleration
Off the seller’s Looker instance. With the model intact.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Looker TSA separation is the work of standing up a Newco instance, repointing the LookML model and database connections at Newco data, rebuilding the access model, and migrating content before the seller cuts access. The work sits inside the broader carve-out advisory program because Looker queries the warehouse live, so the analytics exit is bound tightly to the data platform separation underneath it.
Looker separation starts with an inventory of the seller instance. The buyer needs the LookML projects and their Git repositories, the database connections, the models and explores, the user defined content covering Looks, dashboards, and boards, the user and group model, and the deployment, whether Looker hosted by Google or Looker Core on Google Cloud. It needs the connection inventory: which models connect to which warehouses and with which service accounts.
The seller typically runs Newco analytics inside a shared instance, with content organized by folder and access controlled by group. The clean end state is a dedicated Newco instance with its own connections, projects, and user model. A shared instance is acceptable only as a bridge during the TSA, because the model, the connections, and the content sit under seller control otherwise, keeping Newco dependent.
Target strategy is shaped by the deployment choice and the warehouse. Where Newco adopts Looker hosted by Google, provisioning is straightforward. Where Newco runs Looker Core, it sits in Newco's own Google Cloud project. Either way, the new instance points at Newco data, so the strategy is settled in step with the data platform separation.
A clean inventory and a settled instance decision drive the downstream sequence: the LookML move, the connection repointing, the access rebuild, the content migration, and the consumer cutover. The pattern aligns with the broader BI separation framework and the carve-out data plan.
Looker is sold by Google as platform and user pricing, often tied into the broader Google Cloud commitment. The seller agreement does not transfer in a carve-out. Newco signs a direct agreement sized to its real user population and its platform edition. The buyer counts active developers and viewers rather than the licensed total, because carve-outs carry idle seats that Newco should not inherit.
Where Looker sits inside a wider Google Cloud relationship for Newco, the negotiation is run as part of that commitment rather than as a standalone line. Leverage comes from the consolidated cloud footprint, the choice between Looker hosted and Looker Core, and term and ramp structure. Where Newco runs multiple BI tools across the inherited estate, the separation is the moment to decide whether to standardize, and that decision strengthens the negotiating position.
Where the seller hosts Newco analytics through a TSA period, the pricing is cost-plus or fixed-fee with a defined exit ramp. The seller cannot mark up subscription or hosting costs it does not separately incur, and the TSA defines how shared infrastructure is allocated so Newco does not absorb seller overhead.
Where a partner is engaged for the migration, the contract is fixed fee for defined deliverables with disciplined change control. The audit discipline runs through the broader TSA license consolidation work so Newco rationalizes its BI spend at exit.
The LookML model is the one part of a Looker separation that moves cleanly, because LookML lives in version control. The migration repoints the Newco instance at a Newco Git repository holding the projects, or forks the seller repository into a Newco repository. The version history, the models, the explores, and the derived tables all carry over with the code. This is the advantage Looker has over BI tools where the model is locked inside the platform.
Connection repointing is the heart of the work. Each model connects to a warehouse through a defined connection with a service account. Those connections point at the seller's warehouse, and each is repointed at the Newco data source with Newco credentials. Because Looker queries the warehouse live rather than holding extracts, the connection repointing cannot complete until the underlying data platform has been separated, which is why the Looker exit waits on the warehouse.
Derived tables and persistent derived tables deserve attention. Where the model builds PDTs in the warehouse, the build process needs write access to a Newco scratch schema configured in the new connection. A missed scratch schema configuration is a common cause of broken explores immediately after repointing.
User created content is migrated separately. Looks, dashboards, and boards built by users are moved through the API or recreated, prioritizing the content that matters rather than every saved Look. The discipline mirrors the broader TSA exit data migration strategy.
The access model is rebuilt rather than copied. Looker uses roles, model sets, permission sets, and user attributes to control what each user can see and do. These are reconstructed in the Newco instance to match a standalone governance posture. Group membership is rebuilt from Newco's directory rather than carried over from seller groups, because seller groups carry seller users who must not exist in the Newco instance.
Access filters and user attributes are the most consequential pieces. Where the seller used user attributes to drive row level access in the LookML, that logic is rebuilt against Newco's user attributes and entitlement values. An access filter error exposes data to the wrong audience, so this is validated explicitly before any dashboard is opened to its full audience.
Governance content carries over deliberately. Folder structure, content access, and the curated model organization are recreated so users can still find trusted content. Where the seller maintained content validation and a development workflow with mode promotion, the equivalent is established in the Newco instance so the LookML development discipline survives the move.
Identity is the final piece. Single sign on and provisioning are configured against Newco's identity provider so users authenticate cleanly and map to the right roles and attributes from the first login.
Cutover moves users from the seller instance to the Newco instance. The runbook covers the final content sync, the freeze on changes in the seller instance, the connection repointing verification, the access model validation, the user notification, and the cutover gate. Because Looker is read only consumption, the cutover often runs as a controlled switch with a short overlap where both instances are available for verification.
Validation confirms parity. Key dashboards and explores are run side by side between the seller and Newco instances for the same period to confirm the numbers match against the repointed warehouse. Schedules and alerts are confirmed to run and deliver. A report that drives decisions cannot be declared migrated until its numbers reconcile against the source.
Stabilization runs thirty to forty five days. Broken explores, failed PDT builds, schedule failures, and access gaps are triaged within agreed service-level commitments. User adoption is supported with quick reference guidance. Only after a clean reporting cycle does the buyer certify the analytics platform for TSA exit.
Decommissioning is explicit. Once the Newco instance is validated and the TSA tail closes, the seller removes Newco content and revokes access so Newco models and content no longer persist in the seller instance.
Looker separation cost is driven less by the LookML move, which is cheap because it is version controlled, and more by connection repointing, access modeling, and the warehouse query load Newco now pays for directly. The discipline is to right size the user count to active developers and viewers and to model the warehouse query cost so the live query pattern does not surprise the Newco budget after cutover.
The common failure mode is sequencing Looker ahead of the warehouse. Because Looker queries the database live, a Looker exit that runs ahead of the data platform separation points its connections at a source that is moving. Buyers that sequence the Looker exit behind the warehouse separation avoid the broken explore on Day One.
The second failure mode is treating access filters as an afterthought. A migration that moves the model but rebuilds user attribute driven access loosely can expose data to the wrong audience. The fix is to validate access filters against named users before opening any dashboard broadly. A PMO maintains the dependency map across Looker and the warehouse, escalating blocks inside forty eight hours.
A clean Looker separation produces a Newco that owns its own instance, its own model repository, and its own access governance, with the optionality to consolidate BI tools on its own timeline. The discipline runs through the TSA exit acceleration program under a Fixed Fee plus Portfolio Retainer engagement model.
Yes. The clean end state is a dedicated Newco Looker instance with its own database connections, LookML projects, and user model. A shared seller instance is acceptable only as a bridge during the TSA because the model, connections, and content sit under seller control otherwise.
LookML lives in Git, so the model moves cleanly by repointing a new instance at a Newco Git repository holding the projects. The work is in reconfiguring database connections, rebuilding user attributes and access grants, and migrating user created content like Looks and dashboards.
The underlying warehouse. Looker queries the database live through its connections, so the Looker exit cannot finish before the warehouse it reads from has been separated and the connections repointed at Newco data.
Looker typically exits in two to four months once the warehouse is ready. The LookML move is fast because it is version controlled, so the pace is set by connection repointing, access modeling, and content migration.
Site strategy, content migration, data source repointing, and the RLS rebuild.
Read the article →Tenant and workspace strategy, dataset repointing, and the gateway move.
Read the article →The data platform separation that the Looker exit depends on.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →Scope the data split tightly. Every table you over-migrate and every pipeline you leave on the seller is a line on next year's TSA invoice.