Qlik to Power BI: Server Migration¶

Audience: BI administrators, IT operations, platform engineers Purpose: Infrastructure-level migration from Qlik Sense Enterprise to Power BI Service Reading time: 15-20 minutes

1. Architecture comparison¶

Qlik Sense Enterprise on Windows¶

Qlik Sense Enterprise runs as a multi-service Windows application across one or more servers:

• Repository Service -- metadata database (PostgreSQL), app storage, security rules
• Engine Service -- in-memory calculation engine, app loading
• Proxy Service -- authentication, session management, load balancing
• Scheduler Service -- reload task scheduling and execution
• Printing Service -- NPrinting integration (separate server)
• Shared persistence -- file share for QVF/QVD storage

Power BI Service (SaaS)¶

Power BI Service is a fully managed SaaS platform:

• No server infrastructure -- Microsoft manages compute, storage, networking
• No patching or upgrades -- updates deploy automatically
• No capacity planning -- scale through license tier or Fabric SKU selection
• No disaster recovery configuration -- built into the service
• Admin portal -- web-based administration for tenant, capacities, and workspaces

The migration from Qlik Sense Enterprise to Power BI Service is also a migration from self-managed infrastructure to SaaS. This eliminates the operational burden of Windows Server management, PostgreSQL database maintenance, certificate management, and cluster scaling.

2. Concept mapping¶

2.1 Content organization¶

2.2 User and security mapping¶

2.3 Administration mapping¶

3. Security rule migration¶

3.1 Qlik security rules to Power BI¶

Qlik security rules are attribute-based policies evaluated by the Proxy and Repository services. They control access to streams, apps, and data at a granular level.

Power BI uses a layered security model:

3.2 Common Qlik security rule patterns¶

Pattern: Stream access by group

// Qlik security rule
Resource filter: Stream_*
Condition: user.group = "FinanceTeam"
Actions: Read

// Power BI equivalent
// 1. Create workspace "Finance Reports"
// 2. Add Entra ID group "FinanceTeam" as Viewer role
// 3. Publish reports to this workspace

Pattern: App-level Section Access

// Qlik data load script (Section Access)
Section Access;
LOAD * INLINE [
    ACCESS, USERID, REDUCTION
    USER, DOMAIN\john, East
    USER, DOMAIN\jane, West
    ADMIN, DOMAIN\admin,
];

Section Application;
// Data load continues...

// Power BI RLS equivalent
// 1. Create a SecurityMapping table with UserEmail and Region columns
// 2. Define RLS role "RegionFilter" with DAX expression:
[Region] = LOOKUPVALUE(
    SecurityMapping[Region],
    SecurityMapping[UserEmail],
    USERPRINCIPALNAME()
)
// 3. Assign users/groups to the role in the Power BI Service

Pattern: Attribute-based access (dynamic)

// Qlik: Dynamic security rule based on user attributes
Condition: user.department = resource.stream.customProperty("AllowedDepartment")

// Power BI: Dynamic RLS with user-group mapping table
// 1. Create a DimUserAccess table: UserEmail, Department, Region, etc.
// 2. Import into the semantic model
// 3. Create relationships from DimUserAccess to fact tables
// 4. RLS DAX expression:
CONTAINS(
    DimUserAccess,
    DimUserAccess[UserEmail], USERPRINCIPALNAME()
)
// This filters all related tables through the access table

4. Reload task to scheduled refresh migration¶

4.1 Mapping reload patterns¶

4.2 Direct Lake: eliminating refresh entirely¶

With CSA-in-a-Box, the target architecture uses Direct Lake, which reads Delta tables directly from OneLake. This eliminates the entire concept of scheduled refresh:

• No reload tasks to manage
• No refresh failures to troubleshoot
• No stale data between refreshes
• No scheduling conflicts between multiple apps

The only "refresh" is the data pipeline that updates the Gold layer tables (ADF + dbt), which is managed by the data platform team, not the BI team.

5. Monitoring and operations¶

5.1 QMC monitoring to Power BI monitoring¶

5.2 Advanced monitoring with Log Analytics¶

For organizations requiring detailed monitoring (equivalent to Qlik's Operations Monitor and custom monitoring apps), export Power BI activity logs to Azure Log Analytics:

1. Enable Log Analytics integration in Power BI Admin Portal
2. Configure a Log Analytics workspace in Azure
3. Query Power BI events using KQL:

PowerBIActivity
| where ActivityName == "ViewReport"
| summarize ViewCount = count() by ReportName, UserName
| order by ViewCount desc
| take 20

This provides richer analytics than QMC's built-in monitoring, with the full power of KQL for custom dashboards and alerting.

6. Migration execution steps¶

Step 1: Inventory (Week 1)¶

1. Export the Qlik Sense site inventory via QMC REST API or manual export
2. Catalog all streams, apps, data connections, security rules, reload tasks, and users
3. Map the current stream hierarchy to a target workspace hierarchy
4. Identify stale apps (last accessed > 90 days) for archival
5. Document all custom security rules for conversion

Step 2: Workspace setup (Week 2)¶

1. Create Power BI workspaces matching the target hierarchy
2. Assign Entra ID groups to workspace roles (Admin, Member, Contributor, Viewer)
3. Create deployment pipelines (Dev/Test/Prod) for production workspaces
4. Configure tenant settings in the Admin Portal (org-wide policies)

Step 3: Security configuration (Week 3)¶

1. Convert Qlik Section Access to Power BI RLS roles
2. Create user-access mapping tables if dynamic security is needed
3. Configure sensitivity labels for classified content
4. Test security by validating that each user sees only their authorized data

Step 4: Data connection migration (Week 3-4)¶

1. Install and configure Power BI gateway for on-premises data sources
2. Configure cloud data source credentials in Power BI Service
3. Set up Direct Lake connections to CSA-in-a-Box Gold tables
4. Validate data connectivity from all target semantic models

Step 5: Refresh schedule configuration (Week 4)¶

1. Map Qlik reload schedules to Power BI refresh schedules
2. Configure incremental refresh for large datasets
3. Set up Power Automate flows for event-driven refresh scenarios
4. Validate refresh success and timing

Step 6: Validation and cutover (Week 5)¶

1. Verify all workspaces are accessible to the correct users
2. Confirm RLS restricts data as expected
3. Validate refresh schedules are executing correctly
4. Redirect users from Qlik Hub to Power BI workspace/app URLs
5. Archive QVF files for rollback (retain 90 days)

7. Server migration checklist¶

• Export Qlik site inventory (apps, streams, users, security rules, tasks)
• Design Power BI workspace hierarchy
• Create workspaces and assign Entra ID groups
• Configure deployment pipelines (Dev/Test/Prod)
• Convert Section Access to RLS roles
• Install and configure Power BI gateway (if on-prem sources exist)
• Configure cloud data source credentials
• Set up Direct Lake connections to CSA-in-a-Box Gold tables
• Configure refresh schedules (or validate Direct Lake auto-refresh)
• Set up monitoring (Usage Metrics, Log Analytics)
• Configure tenant settings (custom visuals, export controls, sharing policies)
• Apply sensitivity labels to classified content
• Create Power BI apps for end-user distribution
• Redirect Qlik Hub URLs to Power BI workspace/app URLs
• Archive QVF files
• Decommission Qlik Sense servers

Cross-references¶

Maintainers: CSA-in-a-Box core team Last updated: 2026-04-30