Product knowledge

Docs

Migration
View Markdown

Power BI To Qlik Migration

Understand how Raptor helps teams assess, plan, rebuild, and validate Power BI reports in Qlik.

Overview

Power BI to Qlik migration in Raptor is an assisted rebuild workflow. It helps teams inspect the source estate, plan the target Qlik app, and validate the finished result against trusted source evidence.

This is not a one-click PBIX converter or a promise of pixel-perfect cloning. It is intended for controlled migration projects where business logic, data access, security, and acceptance checks matter.

  • Best suited for Power BI content that can be inspected through supported Microsoft APIs or exported project formats.
  • Useful for assessment, migration planning, guided rebuild work, and acceptance validation.
  • Not intended to move credentials, bypass tenant permissions, or guarantee pixel-perfect visual clones.
  • Some source files may need preparation before deeper migration evidence is available.

How it works

The migration separates source assessment from target build activity. Source evidence is gathered first, then Raptor uses that evidence to support the Qlik rebuild.

This separation keeps the migration auditable. Teams can review what was discovered, what was recommended, what was rebuilt, and what still needs a decision.

  • Source metadata and report structure are gathered where permissions allow.
  • Migration evidence is summarized into reviewable planning artifacts.
  • The Qlik rebuild is performed through licensed Raptor workflows and approved Qlik access.
  • Unsupported or uncertain items are recorded for review instead of being hidden.

Access requirements

Power BI and Fabric assessment uses approved Microsoft identity and permissions. The signed-in user or service account must have permission to read the relevant source content.

For unattended gateway deployments, use a dedicated service identity and grant that identity access to each source workspace. Tenant or Fabric administrator visibility is not the same as workspace-level access for the identity used during assessment.

Some source details depend on tenant settings, item permissions, and Microsoft sensitivity controls. If Microsoft blocks access to an item or definition, Raptor records that as a migration constraint.

  • Use delegated access for interactive assessment and service-principal access for controlled unattended runs.
  • Enable the service principal in your Fabric or Power BI tenant settings before using app-only authentication.
  • Add the service principal, or a security group containing it, to every source workspace that should be visible to the migration MCP.
  • If a user can see a workspace but the MCP cannot, compare the user's delegated access with the service principal's workspace role assignments.
  • Credentials and gateway secrets are not copied into the manifest.
  • Tenant-admin features may require additional Microsoft configuration.
  • Security owners should review any row-level security recommendations before production use.

Migration manifest

The migration manifest is the main handoff artifact. It captures the source evidence, target-plan summary, and validation items in a structured form that can be reviewed by the project team.

The manifest is useful for planning and governance because it gives everyone the same view of migration scope, dependencies, assumptions, and open decisions.

For migration projects, store the full handoff pack before the Qlik rebuild starts. The pack keeps enough source inventory, build guidance, validation checks, and open-decision notes for the project team to continue or repair the migration later without relying on live assessment access.

  • JSON manifest for structured handoff.
  • Source inventory markdown for human review.
  • Qlik build handoff markdown for base Raptor/Qlik tooling.
  • Validation pack markdown for acceptance checks.
  • Open decisions markdown for review, redesign, security notes, and project decisions.

Qlik rebuild expectations

The Qlik output is a rebuilt Qlik app, not a mechanical copy of the Power BI file. The aim is to preserve business meaning, measures, filters, security intent, and user workflows while using Qlik's associative model and native objects well.

Some visual differences are normal. Layout, colors, map providers, labels, object behavior, and custom visuals may need review or redesign during the project.

  • Standard visual types are rebuilt with native Qlik objects where practical.
  • Custom or highly specialized visuals may require redesign or extension work.
  • Source-matched styling is treated as a project choice, not the default.
  • Security migration is advisory until security owners validate Section Access and space permissions.

Validation

A migration should be accepted on evidence, not appearance alone. Raptor helps capture the checks that matter for the source and target app.

Validation usually includes business totals, row-count confidence, selected visual comparisons, reload status, security review, and a list of accepted differences.

  • Confirm the key numbers that business users rely on.
  • Review representative pages and filters with the business owners.
  • Record expected differences and remaining risks.
  • Keep unresolved parity items visible until they are fixed, accepted, or descoped.

Previous

QlikView Migration

Next

Writeback and Workflows