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.

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 Raptor's licensed Qlik tooling and skills.
• Unsupported or uncertain items are recorded for review instead of being hidden.

The Power BI Migration MCP uses Microsoft Entra authentication. The signed-in user or service principal must have permission to read the relevant Power BI or Fabric items.

For unattended gateway deployments, customers should use a dedicated service principal and grant that identity access to each source workspace. Tenant or Fabric administrator visibility is not the same as workspace access for the service principal used by the MCP.

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 the customer's 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.
• Customer security owners should review any row-level security recommendations before production use.

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 customer 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 customer to continue or repair the migration later without relying on live access to the Power BI Migration MCP.

• 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 customer decisions.

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 customer security owners validate Section Access and space permissions.

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 customer.
• Record expected differences and remaining risks.
• Keep unresolved parity items visible until they are fixed, accepted, or descoped.