SSRS to Power BI Migration Checklist: Step-by-Step for Enterprise Teams
A complete SSRS to Power BI migration checklist covering every phase — pre-migration audit, semantic layer build, parity validation, security setup, and adoption. Use this to track progress, identify gaps, and ensure nothing gets skipped before go-live.
An SSRS to Power BI migration has five distinct phases — and each phase has a set of tasks that need to be completed before you move to the next one. Skipping steps is how migrations end up with parity issues at go-live, ungoverned semantic layers, and adoption failures three months post-launch. This checklist covers every phase in sequence. Use it to track progress, identify gaps, and ensure nothing critical gets missed before you decommission SSRS.
Phase 1: Pre-Migration Audit Checklist
Complete before writing any DAX or building any report
The audit phase determines your actual migration scope. Most teams that skip it discover mid-migration that they are building reports nobody uses, or that their metric definitions conflict across dozens of SQL queries.
- Query the SSRS execution log Pull ReportPath, execution count, and last run date from ReportServer.dbo.ExecutionLog3 for the past 12 months.
- Classify every report Migrate to Power BI dashboard / Migrate to Power BI Paginated Reports / Retire. Get business owner sign-off on the retire list.
- Document every report's data source SQL query, source tables, joins, filters, parameters, refresh cadence.
- Identify all report subscriptions Who receives scheduled emails, what cadence, what format. These become Power BI subscriptions.
- Map row-level security rules Every SSRS report with data-level security needs its RLS rules documented and translated to DAX for the semantic layer.
- Identify conflicting metric definitions Find every report that calculates a core metric and document how each one does it. Discrepancies need to be resolved before the semantic layer is built.
- Get stakeholder sign-off on retirement list Before building anything, confirm with business owners which reports are being retired.
- Define the SSRS decommission date Set it at the start, not the end. A defined end date drives adoption.
Phase 2: Semantic Layer and Data Model Checklist
Complete before building any Power BI reports
The semantic layer is the foundation. Every report built before the semantic layer is defined will need to be rebuilt when metric definitions are finalised. Build this first.
- Define every core business metric in plain English Revenue, margin, headcount — written definition, named business owner, date approved.
- Design workspace structure One workspace per business domain. Separate staging workspace for development. Certified datasets in a restricted workspace.
- Build certified datasets per domain One dataset per business domain. All reports in that domain connect to the domain dataset.
- Implement DAX measures for all core metrics Every metric defined in DAX in the certified dataset. No metric calculated differently in different reports.
- Configure row-level security in the dataset RLS defined once in the semantic layer, not repeated in each report.
- Set dataset refresh schedules Refresh cadence documented and configured. Refresh failure alerts routed to a named owner.
- Certify datasets before any report connects Dataset certification confirms the numbers have been validated and the definition approved.
Phase 3: Parity Validation Checklist
Required for every migrated report before go-live
Parity validation is the step that prevents trust events. A discrepancy discovered by a business user after go-live takes months to recover from. Discovered during validation, it is a development ticket.
- Pull the same data for the same period from both systems Compare SSRS output vs Power BI output on a matched historical period for every critical report.
- Document every discrepancy For each discrepancy: what is different, why, which system is correct, how it was resolved.
- Get business owner sign-off on each validated report A named business owner confirms the Power BI numbers match expectations before go-live.
- Schedule 30-day parallel running for high-criticality reports Business users run both systems simultaneously and flag any differences for 30 days post-migration.
- Define acceptable parity threshold Agree in advance what constitutes a blocking discrepancy vs an acceptable rounding difference.
Phase 4: Security and Access Control Checklist
Power BI's access model is workspace-based and more permissive by default than SSRS. Get security configured before content goes live.
- Map every SSRS user and group to Power BI workspace roles Admin / Member / Contributor / Viewer. Document who has what access and why.
- Configure tenant-level sharing settings Restrict external sharing at the tenant level before go-live.
- Validate RLS roles in Power BI Test every RLS role with a named user in the expected role. Confirm data visible matches expectations.
- Migrate all subscriptions Every SSRS subscription has a Power BI equivalent configured and tested.
- Document the access request process How does a new user get access? Who approves it? Defined and communicated before launch.
Phase 5: Adoption and Decommission Checklist
A technically complete migration that business users do not adopt is a failed migration. Adoption needs an owner, not just a training session.
- Run team-specific adoption sessions Sessions focused on each team's specific reports — not generic Power BI training.
- Assign an adoption owner A named person accountable for tracking and improving adoption rates post-launch.
- Enable and review usage metrics Power BI workspace usage metrics show report views and active users. Review weekly for the first 60 days.
- Define the SSRS decommission trigger Adoption rate threshold at which SSRS gets switched off. Communicate this threshold to business users.
- Communicate the SSRS end date A firm end date accelerates adoption more than any training programme.
- Document support process post-go-live Named support owner and escalation path for Power BI report issues after the migration team closes.
Related Reading for This Migration
For the full context on why each phase matters — including the mistakes that derail migrations when steps get skipped — see the related guides in this cluster.
Full migration guide: How to Migrate from SSRS to Power BI: A Practical Guide for Enterprise Teams — covers every phase in detail, architecture decisions, tools, and timeline. Link: /blog/ssrs-to-power-bi-migration
Failure patterns: Why SSRS to Power BI Migrations Fail: 7 Mistakes That Derail Enterprise Projects — the structural failures that cause migrations to run over time and under-deliver. Link: /blog/ssrs-migration-failures
Case study: SSRS to Power BI Migration — 70% reduction in manual data prep, close cycle cut by 2–3 days. Link: /case-studies/finance-ssrs-powerbi
Real-World Example
A mid-market financial services firm came to Cipherbeats with a large SSRS report estate, recurring audit pressure, and executive distrust caused by inconsistent KPI definitions. After inventory rationalization, parity validation, and full Power BI migration, the result was a 70% reduction in manual data prep, close readiness improved by 2–3 days, and a single trusted version of the truth across all finance teams.
See how we delivered a financial services SSRS to Power BI migration — 70% reduction in manual data prep →Frequently Asked Questions
What should I do before starting an SSRS to Power BI migration?
Audit your SSRS estate before building anything. Query the execution log to find which reports are actually used, classify each report into migrate or retire, document every data source, and map all row-level security rules. Most migrations that run into trouble skip this phase and discover mid-build that they are migrating reports nobody needs.
How do I know when a migrated report is ready to go live?
A report is ready to go live when it has completed parity validation — the Power BI output has been compared against SSRS for the same period, every discrepancy has been resolved, and the business owner has signed off. Going live without this step is the most common cause of trust events in BI migrations.
How long should parallel running last after migration?
A minimum of 30 days for high-criticality reports. During this period, business users run both systems and flag any discrepancies. Lower-criticality reports can go live without parallel running once parity validation is complete.
What is the biggest adoption mistake in Power BI migrations?
Leaving SSRS running indefinitely after go-live. When the old system remains available, users treat it as a fallback and adoption stalls. Set a firm SSRS decommission date at the start of the project and communicate it to all business users.
Do I need Power BI Premium for an SSRS migration?
Not necessarily. Power BI Pro licences are sufficient for most dashboard migrations. Power BI Premium is required for paginated reports — the equivalent for pixel-perfect printable output like invoices and statements.
What this means for you
If your organization is working through an SSRS to Power BI migration and wants a delivery team that owns the process end-to-end — from audit through adoption — we can scope the engagement.