SSRS to Power BI Migration Guide

Decide the target experience first

“Power BI” can mean different target experiences. Choose at the report level rather than applying one pattern across the estate.

Microsoft calls .rdl content in Power BI “paginated reports.” That path is different from rebuilding a report as an interactive .pbix report. The assessment should state which target is intended for every item.

Phase 1: Discover the SSRS estate

Build an inventory of more than report names. Microsoft's migration guidance begins with discovery and assessment because not every server item or feature migrates the same way. Use the inventory to expose unsupported features and missing ownership before the build begins.

• Report context: path, owner, business purpose, criticality, and the business decision the report supports.
• Usage: last execution and execution frequency where reliable usage data exists.
• Dependencies: data sources, shared datasets, embedded datasets, parameters, subscriptions, and schedules.
• Complexity: custom code, subreports, linked reports, extensions, and rendering requirements.
• Security: security assignments and sensitive-data classification.
• Downstream use: exports, APIs, print workflows, and operational procedures.

Phase 2: Assign a disposition to every report

Use a small set of explicit dispositions so scope is a decision rather than an assumption.

Require a business owner to approve the disposition. Usage logs help identify candidates, but absence of recent execution is not enough to retire a statutory, seasonal, or contingency report without owner review.

• Retire: no approved need remains.
• Retain temporarily: keep in SSRS during a phased transition.
• Migrate as paginated: preserve the .rdl experience in the Power BI service.
• Redesign as interactive: rebuild around an approved semantic model and user workflow.
• Consolidate: replace several overlapping reports with one governed experience.
• Replace outside Power BI: use another operational or document-generation path when that better fits the requirement.

Phase 3: Gather requirements before estimating

Microsoft's Stage 1 migration guidance says that the existing BI inventory becomes the input for detailed, prioritized requirements. The following questions determine the real effort: what business question or action the report supports, which elements must remain pixel-perfect, which filters, drill paths, exports, and subscriptions are required, what data freshness is actually needed, which metric definitions are approved, which security boundaries must be reproduced, what response time and concurrency are expected, what accessibility and device requirements apply, and who validates the output and approves go-live.

Do not estimate a portfolio from the number of .rdl files alone. Two files can share one simple data source, or one file can contain complex dependencies and operational behavior.

Phase 4: Design the semantic model where reuse matters

Interactive Power BI reports should not automatically inherit one dataset per legacy report. That reproduces duplicated business logic in a new platform.

Paginated reports can use Power BI semantic models when that is appropriate, but the target design should be selected from the requirement rather than imposed on every report.

• Identify measures used across several reports.
• Reconcile conflicting definitions with business owners.
• Design dimensions, relationships, and calculation ownership.
• Decide Import, DirectQuery, or composite behavior from freshness, scale, and source constraints.
• Define row-level and object-level security where required.
• Establish certification, change control, and support ownership.

Phase 5: Assess .rdl migration compatibility

Microsoft's current guidance describes tools for supported SSRS versions and a migration workflow for .rdl reports. The RDL Migration Tool checks for unsupported data sources and report features, converts shared resources to embedded resources where required, and publishes reports that pass checks as paginated reports to a Power BI workspace. It does not modify or remove the existing SSRS reports.

That tool is not a general converter from every SSRS report into an interactive Power BI report. Treat its output as a migration path for paginated content and review the tool's report of successful and unsuccessful actions. Because product support changes, check Microsoft's current supported-version and feature documentation immediately before execution.

• Supported or unsupported data source.
• Supported or unsupported report features.
• Shared resource changes.
• Credential and gateway requirements.
• Workspace and capacity requirements.
• Rendering comparison results and required manual remediation.

Phase 6: Build and validate in waves

Migrate a representative wave before scaling the process. Include at least one paginated report, one interactive redesign if that path is in scope, one security-sensitive report, and one report with meaningful downstream use.

Use the same source period and agreed filters when comparing SSRS and Power BI. Document every discrepancy and classify it as a defect, an approved redesign, a source-data change, or an accepted limitation.

Phase 7: Plan workspaces, gateways, and access

Microsoft's deployment guidance recommends a test environment for IT-managed or business-critical solutions and describes a staged path through production, support, and monitoring. Use a test workspace when the risk and operating model justify it.

• Development, test, and production workspace structure with a defined deployment and approval path.
• Gateway clusters and data-source ownership where on-premises connectivity remains.
• Service accounts, credentials, and rotation.
• Semantic-model and report permissions, plus row-level security assignments.
• Sharing, export, and external-access policy.
• Monitoring, audit, and support responsibilities.

Phase 8: Run parallel and decommission deliberately

For critical reporting, keep the legacy and target outputs available during an agreed validation window. The duration should come from business risk, reporting cadence, and acceptance evidence — not a generic rule.

Before redirecting consumers, confirm the final validation set is complete, gateway and refresh behavior is correct, subscriptions and schedules are in place, support coverage and incident routing are active, and business owners approve the target outputs. Record the exact switch time and rollback conditions.

Do not decommission SSRS until retention, audit, rollback, consumer, and operational requirements are satisfied. Microsoft explicitly treats deployment, support, and monitoring as part of the migration process rather than an afterthought.

What not to do

Do not migrate every report automatically: inventory and owner-approved disposition come first. Rebuilding unused or duplicated content increases cost and makes governance harder.

Do not force paginated requirements into interactive dashboards, and do not recreate business logic report by report. Where reports share metrics, govern the semantic model and measure definitions instead of copying calculations into each report.

Do not treat a successful upload as acceptance, and do not leave decommissioning undefined. Set the approval criteria and accountable decision-maker during planning, or the organization can end up supporting both platforms indefinitely.

SSRS-to-Power BI go-live checklist

Use this list as the gate before consumers are redirected and SSRS is retired.

• Every report has an approved disposition and owner.
• Unsupported features and sources have a documented treatment.
• Paginated and interactive targets are clearly separated.
• Semantic-model decisions and measure owners are recorded.
• Gateway, credential, workspace, and capacity dependencies are ready.
• Data, business logic, rendering, security, refresh, and workflow tests pass.
• Exceptions and approved differences are documented and signed off by business owners.
• Support, monitoring, recovery, and escalation are active.
• Rollback conditions and the SSRS decommission gate are documented.

Primary documentation

Verify product behavior against Microsoft's current documentation before execution: the Power BI migration overview (https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-overview), gathering migration requirements (https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-requirements), planning the migration of .rdl reports (https://learn.microsoft.com/en-us/power-bi/guidance/migrate-ssrs-reports-to-power-bi), deploy, support, and monitor guidance (https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-migration-deploy-support-monitor), and migrating a report server installation (https://learn.microsoft.com/en-us/power-bi/report-server/migrate-report-server).

Frequently Asked Questions

Read next — Analytics Engineering