Blog · Platform Separation

Power BI separates with the tenant, and with the gateway.

Power BI TSA separation is the work of standing up Newco content in a Newco tenant, repointing datasets at Newco data, reconfiguring the data gateway, and rebuilding security before the seller's tenant cuts access. The work sits inside the broader carve-out advisory program because Power BI is bound to the Microsoft identity tenant, so the analytics exit is inseparable from the Microsoft 365 separation and the data platforms underneath.

5
Workstreams
2 to 5 Mo.
Typical Timeline
7 min
Read Time
2026
Last Updated
Section 01

Tenant inventory and target workspace strategy.

Power BI separation starts with an inventory of the seller tenant. The buyer needs the workspace layout, the reports, datasets, dataflows, and paginated reports, the on premises data gateway configuration, the capacity model whether Premium, Fabric, or Pro, and the license counts by user. It needs the data source inventory: which datasets connect to which warehouses and databases, which run import mode with scheduled refresh, and which run DirectQuery against a live source.

Power BI lives inside the Azure AD tenant behind Microsoft 365. Newco content is organized into workspaces inside the seller tenant, and the clean end state is Newco content in a Newco tenant tied to Newco identity. Because the platform is bound to the identity tenant, the Power BI separation sequences with the broader Microsoft 365 separation rather than running independently of it.

Target strategy is shaped by the tenant decision and the capacity model. Newco decides whether to adopt Fabric capacity, Premium per capacity, or Pro per user licensing based on its real refresh and query load. The decision is made early because it drives both the migration mechanism and the recurring cost of the analytics platform.

A clean inventory and a settled tenant decision drive the downstream sequence: content migration, dataset repointing, gateway reconfiguration, security rebuild, and consumer cutover. The pattern aligns with the broader Tableau and Power BI separation framework.

Section 02

Licensing and the Microsoft commercial.

Power BI licensing runs through the Microsoft commercial alongside the broader Microsoft 365 estate. Pro and Premium per user licenses are per user, while Premium and Fabric capacity is a tenant level commitment. The seller agreement does not transfer in a carve-out. Newco signs a direct Microsoft agreement, and the buyer counts active report consumers and authors rather than the licensed seat total, because carve-outs routinely carry idle licenses Newco should not inherit.

Because Power BI sits inside the wider Microsoft relationship, the negotiation is best run as part of the overall Microsoft enterprise agreement for Newco rather than as a standalone line. Leverage comes from the consolidated Microsoft footprint, the choice between Fabric capacity and per user licensing, and term and ramp structure. The buyer sizes capacity to real load rather than copying the seller's capacity allocation, which is often provisioned for a larger combined organization.

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 capacity costs it does not separately incur, and the TSA defines how shared capacity is allocated and metered 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 Microsoft spend at exit.

Section 03

Content migration, datasets, and the gateway.

Content migration moves reports, datasets, and dataflows from the seller tenant to the Newco tenant. The mechanisms include PBIX export and republish, deployment pipelines, and the Power BI REST API for scripted bulk moves. The buyer prioritizes the executive dashboards, the operational reports, and the certified datasets rather than migrating every abandoned report. Cross tenant moves do not preserve everything automatically, so the migration is planned as a rebuild of the workspace structure, not a simple copy.

Dataset repointing is the heart of the work. Each dataset connects to underlying data, and those connections point at the seller's warehouses and databases. Each is repointed at the Newco data source with Newco credentials. Where the underlying warehouse is itself under separation, the Power BI repointing waits on that data platform exit, which is why the analytics layer cannot finish ahead of the data it reads.

The on premises data gateway is reinstalled and reconfigured. Datasets that refresh from on premises sources route through the gateway, so a new gateway cluster is stood up in the Newco environment with Newco service accounts, and each affected dataset is bound to the new gateway. A missed gateway binding is a common cause of failed refreshes immediately after cutover.

Refresh schedules, subscriptions, and alerts are recreated in the Newco tenant so the reporting cadence matches what users expect. The discipline mirrors the broader TSA exit data migration strategy.

Section 04

Security, workspaces, and the identity boundary.

The security model is rebuilt rather than copied. Workspace roles, app audiences, and sharing are reconstructed in the Newco tenant to match a standalone governance posture. Membership is rebuilt from Newco's Azure AD groups rather than carried over from seller groups, because seller groups carry seller users who must not exist in the Newco environment after the identity boundary is set.

Row level security is the most consequential piece. Where the seller used row level security roles defined in the dataset to limit what each user sees, that logic is rebuilt against Newco's user attributes and group membership. Object level security and any sensitivity labels are reapplied. A row level security error exposes data to the wrong audience, so it is validated explicitly before any report is opened to its full audience.

Governance content carries over deliberately. Certified and promoted datasets, endorsement settings, and the curated app structure are recreated so users still find trusted content. Tenant settings, including who can publish, share externally, and install gateways, are configured for Newco's governance model rather than inherited from the seller's more permissive or more restrictive posture.

Identity is the binding constraint. Single sign on and provisioning run through Newco's Azure AD, so the Power BI cutover is gated on the tenant identity boundary being live, in step with the Microsoft 365 separation.

Section 05

Cutover, validation, and stabilization.

Cutover moves users from the seller tenant to the Newco tenant. The runbook covers the final content sync, the freeze on changes in the seller workspaces, the gateway binding, the dataset repointing verification, the user notification, and the validation gate. Because analytics is read only consumption, the cutover often runs as a controlled switch with a short overlap where both environments are available for verification.

Validation confirms parity. Key reports are compared side by side between the seller and Newco tenants for the same period to confirm the numbers match. Scheduled refreshes are confirmed to run through the new gateway and produce current data. A report that drives decisions cannot be declared migrated until its numbers reconcile against the source.

Stabilization runs thirty to forty five days. Failed refreshes, broken gateway connections, and permission 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 tenant is validated and the TSA tail closes, the seller removes Newco workspaces and revokes guest access so Newco content no longer persists in the seller tenant.

Section 06

Cost discipline and where carve-outs go wrong.

Power BI separation cost is driven by content volume, dataset and gateway complexity, and the capacity decision. The discipline is to migrate the content that matters, right size capacity to real refresh and query load, and avoid carrying forward a Premium or Fabric capacity sized for the seller's larger organization. Capacity that is over provisioned at cutover becomes a recurring cost that is hard to claw back later.

The common failure mode is sequencing Power BI ahead of the tenant and the data. The platform is bound to Azure AD and reads from warehouses, so a Power BI exit that runs ahead of the Microsoft 365 separation or the data platform exits points its reports at sources that are gone. Buyers that sequence the BI exit behind identity and data avoid the broken refresh on Day One.

The second failure mode is missing gateway bindings and embedded credentials. A dataset that still routes through the seller gateway or uses a seller service account fails the moment access is cut. The fix is a connection and gateway inventory verified before cutover. A PMO maintains the dependency map across Power BI, the tenant, and the data sources, escalating blocks inside forty eight hours.

A clean Power BI separation produces a Newco that owns its own tenant content, its own gateway, and its own capacity, 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.

FAQ

Questions buyers ask about Power BI separation.

Does Power BI move with the Microsoft 365 tenant?

Yes. Power BI is bound to the Azure AD tenant behind Microsoft 365, so the Power BI separation sequences with the tenant separation. Newco content lives in a Newco tenant, and the exit waits on the identity boundary being established.

How does Power BI content migrate between tenants?

Reports and datasets export as PBIX files or move through deployment pipelines and the REST API. The harder work is repointing datasets at Newco data sources, reconfiguring the on premises data gateway, and rebuilding row level security and workspace access in the Newco tenant.

What about the data gateway and capacity?

The on premises data gateway is reinstalled and reconfigured against Newco data sources with Newco service accounts. Premium or Fabric capacity is contracted directly by Newco and sized to its real refresh and query load, not inherited from the seller's capacity allocation.

How long does a Power BI separation take?

Power BI typically exits in two to five months, but the timeline is set by the Microsoft 365 tenant separation and the underlying data sources. Power BI cannot finish ahead of the identity boundary and the warehouses it reads from.

Related Reading

More on platform separation.

Free Download

Get the buyer-side TSA Exit Playbook.

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 →

Power BI separates with the tenant, and with the gateway.
TSA Exit Acceleration

Off the seller’s Power BI tenant. With the numbers intact.

Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.

White paper

The TSA Exit Playbook

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.

Read the playbook →
The Day One Letter

Get buyer-side TSA intelligence every two weeks

One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.

Subscribe to The Day One Letter →
White paper

The Data & Analytics Separation Playbook

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.

Read the playbook →