PowerBI

Report Server to Server Migration Path Guide – Checklist & Scripts

Migrating your Power BI Report Server is a high-stakes project where downtime and risk are major concerns. This definitive guide from GigXP provides a comprehensive, strategic playbook to navigate the entire process with confidence. We’ll break down why the side-by-side migration is the only professionally recommended approach and provide a detailed 3-phase master checklist to guide you from planning to cutover. Explore our interactive decision tree to validate your strategy, utilize our expert troubleshooting guides, and copy ready-to-use PowerShell and T-SQL scripts to streamline your inventory process. Whether you’re facing a standard migration or a complex scale-out deployment, this guide is your single source of truth for a successful PBIRS migration. GigXP | The Definitive Guide to Power BI Report Server Migration

The Definitive Guide to Power BI Report Server Migration

A strategic and technical playbook for migrating PBIRS with confidence. Minimize risk, eliminate downtime, and modernize your BI platform.

By GigXP Experts | Last Updated: August 7, 2025

In-Place vs. Side-by-Side: The Critical First Decision

The foundational choice in any PBIRS migration is the methodology. This decision impacts risk, downtime, and the long-term health of your BI platform. Let's break down the two main approaches.

Migration Methodology Comparison

Visualizing the Migration Paths & Risks

In-Place Upgrade Path

Start Upgrade on Live Server

Encounter Error?

HIGH RISK: Server Unstable

Rollback requires full restore from backup. Significant downtime.

Side-by-Side Migration Path

Build & Test New Server in Parallel

Production server remains online and unaffected.

Validation Complete?

LOW RISK: DNS Cutover

Rollback is a simple, instant DNS change. Minimal downtime.

Criterion In-Place Upgrade Side-by-Side Migration
Risk Profile High. Failure can corrupt the live instance. Low. Production instance remains untouched.
Rollback Complexity Very High. Requires full server restore from backup. Very Low. Simple DNS change to revert.
Downtime High & Unpredictable. Full outage during upgrade. Minimal. Limited to a short DNS cutover window.
Hardware/OS Upgrade Not Supported. Locks you into existing infrastructure. Ideal. Perfect opportunity to modernize the platform.
Testing & Validation Limited. Occurs post-upgrade during the outage. Comprehensive. Allows for extensive parallel testing.

The Architect's Recommendation

Based on the overwhelming evidence, the **side-by-side migration is the sole recommended methodology** for any production or business-critical Power BI Report Server environment. It's not just a technical preference; it's a fundamental decision about risk management and business continuity.

The 3-Phase Migration Master Checklist

A successful migration is a structured one. Follow this three-phase process for a smooth, predictable, and successful outcome.

1

Plan & Prepare

Foundation for success

2

Execute & Build

The technical migration

3

Validate & Cutover

Verification & go-live

Phase 1 Pre-Migration Planning & Preparation

This initial phase is the most critical. Thorough discovery and preparation here will prevent nearly all common migration failures.

Assemble the Team

Engage BI Admins, DBAs, System Engineers, Security, and key Business Users for UAT.

Inventory and Discovery

Catalog all reports, data sources, security settings, subscriptions, and customizations.

Prepare Target Environment

Provision new server with a modern OS, configure networking, and create service accounts.

Capacity Planning & Sizing

Analyze usage on the old server (CPU, RAM, ExecutionLog3 view) to correctly size the new environment for current and future load.

Critical Backups (Non-Negotiable)

Perform a FULL backup of `ReportServer` & `ReportServerTempDB` databases and, most importantly, **backup the Encryption Key**.

Phase 2 Migration Execution

The core technical steps to install, migrate data, and configure the new instance.

  1. 1

    Install PBIRS on New Server

    Choose the "Install report server only" option. Do not configure it yet.

  2. 2

    Migrate Databases

    Restore the `ReportServer` and `ReportServerTempDB` backups to the new SQL instance.

  3. 3

    Configure New Report Server

    Use the Configuration Manager to connect the new PBIRS instance to the restored databases.

  4. 4

    Restore Encryption Key

    In the Configuration Manager, restore the backed-up `.snk` file. This is critical for data source access.

Phase 3 Post-Migration Validation & Cutover

Rigorously test the new environment to ensure it's a perfect functional replica before directing users to it.

Comprehensive Testing

Validate report rendering, data refreshes, subscriptions, and security (including RLS).

User Acceptance Testing (UAT)

Get sign-off from key business users on their critical reports.

Communication Plan

Execute the communication plan: announce the cutover window and provide post-migration support info.

The Cutover

In a planned window, update the DNS CNAME record to point to the new server's IP.

Decommissioning

Keep the old server offline for a "cool-down" period (5-10 days) before fully decommissioning.

Advanced Topic: Migrating Customizations

Standard migrations are predictable. Custom extensions for branding, security, or data processing add significant complexity and risk.

This is the most straightforward customization. The process is simply to download the brand package `.zip` file from the old server's Site Settings and upload it to the new server. The package contains the `metadata.xml`, `colors.json`, and optional `logo.png`.

This is a software deployment task, not just administration. The old compiled DLLs may not be compatible with the new PBIRS version.

  1. Highest Priority: Locate the original Visual Studio source code.
  2. Document the `` and `` XML configuration in `rsreportserver.config`.
  3. Attempt to copy the DLLs and config to the new server.
  4. Likely Scenario: If it fails, you must recompile the source code against the new server's libraries (`Microsoft.ReportingServices.Interfaces.dll`, etc.) and deploy the newly built DLLs.

These extensions (e.g., for custom data sources or exporting to proprietary formats) follow the same high-risk pattern as security extensions. The migration process is a software deployment and requires developer expertise.

  1. Identify the custom DLLs and their configuration in `rsreportserver.config`.
  2. Locate the original source code. This is non-negotiable for a successful migration.
  3. Recompile the code against the new PBIRS version's libraries.
  4. Deploy the new DLLs and configuration to the new server.

The Scale-Out Deployment Scenario

Migrating a scale-out deployment adds another layer of complexity. This architecture, used for high availability and load balancing, involves multiple PBIRS nodes sharing a single `ReportServer` database.

Scale-Out Architecture

Users

Network Load Balancer (NLB)

PBIRS Node 1

PBIRS Node 2

Shared ReportServer DB

Migration Process for Scale-Out

The key difference is that you migrate the shared database once, then join multiple new nodes to it.

  1. 1

    Migrate Shared Database & Key

    The first steps are identical to a single-server migration. Back up and restore the `ReportServer` databases and the encryption key.

  2. 2

    Build & Configure the FIRST New Node

    Provision the first new server. Install PBIRS ("install only"). Use Configuration Manager to connect to the migrated database and restore the encryption key. This initializes the new scale-out farm.

  3. 3

    Build & JOIN Subsequent Nodes

    For each additional new node, provision the server and install PBIRS ("install only"). In Configuration Manager, go to the "Scale-out Deployment" tab and use the option to **join an existing deployment**. Point it to the shared database. The encryption keys will synchronize automatically.

  4. 4

    Configure New Load Balancer & Cutover

    Configure your new Network Load Balancer to distribute traffic across all the new nodes. The final cutover involves changing the public DNS record to point to the new load balancer's virtual IP address.

Post-Migration Optimization

A successful migration is just the beginning. Use this opportunity to tune, monitor, and govern your new, modern BI platform for peak performance and efficiency.

Performance Tuning

Fine-tune memory settings in `rsreportserver.config` to match your server's resources. Adjust `WorkingSetMinimum` and `WorkingSetMaximum` to manage memory pressure effectively.

Establish Monitoring

Use Windows Performance Monitor to track key PBIRS counters (e.g., 'Memory Pressure State', 'Requests Executing'). Set up alerts for critical thresholds to proactively manage server health.

Implement Governance

Use the migration as a catalyst to clean house. Archive or delete unused reports identified during the inventory phase. Establish a content lifecycle and certification policy for new reports.

Troubleshooting Common Migration Issues

Even with perfect planning, issues can arise. Here’s how to diagnose and resolve the most common problems.

Data Source Connection Errors

Symptoms: "Cannot create a connection" errors, credential prompts.

  • Most Common Cause: Encryption Key was not restored correctly. Re-run the restore process.
  • Check firewall rules between the new PBIRS server and the data source.
  • Verify stored credentials haven't expired.
  • Investigate Kerberos "double-hop" issues by checking Service Principal Names (SPNs) in AD.

Subscriptions or Refreshes Fail

Symptoms: Scheduled refreshes fail, emails are not delivered.

  • Ensure the **SQL Server Agent** service is running on the database host.
  • Verify SMTP settings in the Configuration Manager are correct.
  • Check credentials used for the data refresh.

Slow Performance

Symptoms: Web portal or reports are slower than on the old server.

  • Check if the new server is under-provisioned (CPU/RAM).
  • Change the Windows Server Power Plan from "Balanced" to "High Performance".
  • Use SQL Profiler to analyze and optimize slow-running report queries.

"Access Denied" Errors

Symptoms: Users can't access reports they previously could.

  • Compare folder and item security settings against your pre-migration inventory.
  • If using a custom security extension, check trace logs for errors indicating it failed to load.

Broken Images or Logos

Symptoms: Reports render, but images (e.g., company logos) appear as broken links.

  • Cause: Images in the report definition are using hardcoded URLs that point to the old server.
  • Solution: Edit the report in Power BI Desktop or Report Builder. Re-embed the image directly into the report file instead of referencing it via URL.

Appendix: Useful Scripts

Use these PowerShell and T-SQL scripts to help with your inventory and auditing process.

PowerShell: Inventory All Reports & Data Sources

# Requires ReportingServicesTools module: Install-Module -Name ReportingServicesTools
$ReportServerUri = "http://YourOldServer/ReportServer"
$OutFile = "C:MigrationPBIRS_Inventory.csv"

$session = New-RsRestSession -ReportPortalUri $ReportServerUri
$catalogItems = Get-RsFolderContent -ReportServerUri $ReportServerUri -RsFolder "/" -Recurse

$reportInventory = @()
foreach ($item in $catalogItems) {
    $itemType = $item.TypeName
    $details = ""
    if ($itemType -in @("PowerBIReport", "Report")) {
        try {
            $dataSources = Get-RsDataSource -ReportServerUri $ReportServerUri -RsItem $item.Path
            $dsNames = ($dataSources.DataSource.Name | ForEach-Object { $_ -replace ';', ',' }) -join "; "
            $details = $dsNames
        } catch { $details = "Error fetching data sources" }
    }
    $reportInventory += @{
        Name         = $item.Name
        Path         = $item.Path
        Type         = $itemType
        CreatedBy    = $item.CreatedBy
        CreationDate = $item.CreationDate
        ModifiedBy   = $item.ModifiedBy
        ModifiedDate = $item.ModifiedDate
        DataSources  = $details
    }
}
$reportInventory | Export-Csv -Path $OutFile -NoTypeInformation
Write-Host "Inventory exported to $OutFile"

PowerShell: Inventory Power BI Refresh Schedules

# Requires ReportingServicesTools module
$ReportServerUri = "http://YourOldServer/ReportServer"
$OutFile = "C:MigrationPBIRS_RefreshSchedules.csv"

$session = New-RsRestSession -ReportPortalUri $ReportServerUri
$pbiReports = Get-RsFolderContent -ReportServerUri $ReportServerUri -RsFolder "/" -Recurse | Where-Object { $_.TypeName -eq "PowerBIReport" }

$refreshPlans = @()
foreach ($report in $pbiReports) {
    try {
        $plans = Get-RsRestCacheRefreshPlan -ReportServerUri $ReportServerUri -Path $report.Path
        if ($null -ne $plans) {
            foreach ($plan in $plans.value) {
                $refreshPlans += @{
                    ReportName   = $report.Name
                    ReportPath   = $report.Path
                    PlanID       = $plan.Id
                    Owner        = $plan.Owner
                    ScheduleDesc = $plan.Description
                    LastRunTime  = $plan.LastRunTime
                    LastStatus   = $plan.LastStatus
                }
            }
        }
    } catch { Write-Warning "Could not get refresh plan for $($report.Path)" }
}
$refreshPlans | Export-Csv -Path $OutFile -NoTypeInformation
Write-Host "Refresh schedule inventory exported to $OutFile"

T-SQL: Audit Folder and Item Security

-- Run against the ReportServer database
SELECT
    c.Path,
    c.Name AS ItemName,
    CASE c.Type
        WHEN 1 THEN 'Folder'
        WHEN 2 THEN 'Paginated Report'
        WHEN 5 THEN 'Data Source'
        WHEN 7 THEN 'Shared Dataset'
        WHEN 13 THEN 'Power BI Report'
        ELSE 'Other'
    END AS ItemType,
    u.UserName,
    r.RoleName,
    r.Description AS RoleDescription
FROM
    dbo.Catalog c
JOIN
    dbo.PolicyUserRole pur ON c.PolicyID = pur.PolicyID
JOIN
    dbo.Users u ON pur.UserID = u.UserID
JOIN
    dbo.Roles r ON pur.RoleID = r.RoleID
ORDER BY
    c.Path, u.UserName;

T-SQL: Audit Paginated Report Subscriptions

-- Run against the ReportServer database
SELECT
    c.Name AS ReportName,
    c.Path AS ReportPath,
    s.Description AS SubscriptionDescription,
    s.EventType,
    s.DeliveryExtension,
    u.UserName AS Owner,
    s.LastStatus,
    s.LastRunTime,
    s.Parameters,
    CASE s.DataChanged
        WHEN 1 THEN 'Data-Driven'
        ELSE 'Standard'
    END AS SubscriptionType
FROM
    dbo.Subscriptions s
JOIN
    dbo.Catalog c ON s.Report_OID = c.ItemID
JOIN
    dbo.Users u ON s.OwnerID = u.UserID
ORDER BY
    c.Path, c.Name;
GigXP.com

Modernizing your data platform with expert guidance and proven strategies.

© 2025 GigXP.com. All Rights Reserved.

Disclaimer: The Questions and Answers provided on https://gigxp.com are for general information purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose.

What's your reaction?

Excited
0
Happy
0
In Love
0
Not Sure
0
Silly
0

Comments are closed.

More in:PowerBI

Next Article:

0 %