Power BI Row-Level Security in Migration: The Complete Enterprise Guide 

Migrating Power BI content between tenants is one of the most security-sensitive operations an enterprise admin will ever run, and Row-Level Security (RLS) sits right at the heart of the risk. Get it wrong, and users either see data they shouldn’t, or can’t see the data they need – both outcomes are career-defining. This guide explains exactly how RLS behaves during migration, what transfers with a .pbix file, what doesn’t, and how Apps4.Pro preserves your security posture end-to-end. 

How RLS Is Stored Inside a Semantic Model 

RLS in Power BI is a two-layer construct: the role definition (a named role with one or more DAX filter expressions) and the role membership (the users or Microsoft Entra ID security groups assigned to that role). Roles and their DAX [Table] filter expressions live inside the semantic model itself – they are serialized into the Tabular model metadata stored within the .pbix file. Membership, however, does not live inside the model. It is stored in the Power BI Service against the published semantic model and is managed separately on the Security page of the dataset. 

This separation is by design: data modelers author the security logic in Power BI Desktop, while administrators assign Entra ID users and groups in the Service, allowing organizational changes (new hires, terminations) to flow through automatically. The implication for migration is critical exporting a file only captures half of your security configuration. 

What Transfers During .pbix Export/Import 

When you export a .pbix from the source tenant and import it into the destination, the following travel with the file: 

• All role definitions (role names and their DAX filter expressions on tables) 

• Object-Level Security (OLS) metadata defined on tables or columns per role 

• Any supporting security/user-mapping tables used by dynamic RLS (e.g., tables that map UPNs to regions) 

• DAX logic referencing USERNAME() or USERPRINCIPALNAME() for dynamic filtering 

What does not transfer: 

• Role membership assignments - every user and security group mapped to a role in the source workspace must be reassigned manually (or programmatically) in the target tenant 

• Microsoft Entra ID object IDs - group SIDs differ between tenants, so even groups with identical names must be re-mapped against the destination tenant’s directory 

• Dataset-level and workspace permissions, app audiences, and share links – these are Service-side constructs, not model artifacts 

The practical consequence: a freshly imported .pbix in a new tenant contains fully-armed RLS rules but zero members, which in Power BI means users assigned to an empty role see no data at all until membership is restored. 

How Apps4.Pro Handles RLS During Migration 

Apps4.Pro is built specifically to close the gap that native .pbix export leaves open. During a tenant-to-tenant Power BI migration, the platform: 

1. Enumerates every semantic model in scope and captures both the in-model RLS role definitions and the Service-side role membership list, including Entra ID group object IDs and individual UPNs. 

2. Resolves source-tenant identities against the destination tenant – either automatically via a UPN-match rule or through an admin-supplied mapping file – so that finance@contoso.com becomes finance@fabrikam.com without manual reassignment. 

3. Re-deploys the semantic model, then calls the Power BI REST API to restore role membership on the target dataset, preserving dynamic RLS tables and ensuring USERPRINCIPALNAME() logic resolves correctly in the new tenant. 

4. Logs every role, DAX expression, and member mapping to an audit report for compliance review. 

This means what would otherwise be a multi-week manual reassignment exercise across dozens of workspaces collapses into a validated, repeatable migration job. (See the Datasets migration guide for how semantic model dependencies are handled in parallel.) 

Object-Level Security (OLS) Considerations 

OLS is the often-forgotten sibling of RLS – it hides entire tables or columns from specific roles, rather than filtering rows. Three things to know before you migrate: 

• OLS is not configurable in the Power BI Desktop UI; it’s authored via Tabular Editor or the XMLA endpoint and written into the same role metadata that RLS uses 

• OLS metadata does travel inside the .pbix because it lives in the tabular model, but any downstream report visuals that reference a now-hidden column will break for restricted users – validate reports per role after migration 

• OLS requires a Premium, Premium Per User, or Fabric capacity workspace in the destination; migrating to a Pro-only workspace will cause OLS enforcement to fail silently 

If your source tenant uses OLS alongside RLS (common in HR, finance, and healthcare models), confirm destination capacity SKU before cutover. 

Post-Migration RLS Validation Steps 

Never declare a migration complete until RLS is tested with real user contexts. Use the following validation sequence: 

• Inspect role definitions in Power BI Desktop via Modeling → Manage Roles, or connect DAX Studio to the published model to export the full role list and DAX filters for diff against the source 

• Use “View as Role” in Power BI Desktop to simulate each role, including supplying a test UPN for dynamic RLS so USERPRINCIPALNAME() logic can be exercised 

• Test in the Service via the dataset’s Security page → “Test as role,” which is the only validation that uses the real published model and membership list 

• Recruit pilot users from each role (at minimum one per region/department) and have them open the actual report, checking that totals, slicer values, and detail tables match expected row counts 

• Verify OLS by confirming that restricted columns are invisible in the field list and that visuals referencing them either hide or display a “can’t display” message for the restricted role 

• Audit membership by exporting the dataset’s role assignments and reconciling against the pre-migration inventory 

Common post-migration failure modes include UPN format mismatches between the security table and destination tenant logins (users see no data), unresolved Entra ID groups (empty roles), and bidirectional relationships that leak data across roles – all of which surface only through explicit role testing. 

Frequently Asked Questions 

Related reading:  

Power BI Tenant Migration Pillar Guide  

Migrating Power BI Datasets and Semantic Models  

Apps4.Pro RLS Migration Support Guide