Forum Discussion

Lorenz33's avatar
Lorenz33
Icon for Helper IV rankHelper IV
2 months ago
Solved

Power BI Report Server migration to new servers

We have three Power BI Report Server environments with each of these enviornments having a development, unit acceptance testing, and production setups. These environments were set up 8 years ago and ...
"Need Help"
  • trivedisunita's avatar
    trivedisunita
    2 months ago

    Hi Lorenz33 ,

    Thanks for sharing and Yes, your understanding is correct.

    PBIRS is a stateless service, meaning all content is stored in the ReportServer databases. When you Backup and restore

    • ReportServer 
    • ReportServerTempDBR

    Restore the encryption key
    Configure the new PBIRS instance to point to the restored database

     You will automatically bring over-

    -Folder structure
    -Reports (RDL + PBIX stored in PBIRS)
    -Data sources
    -Subscriptions
    -Security (folder & item-level permissions)

    This is the standard Microsoft-supported migration approach-https://learn.microsoft.com/en-us/power-bi/report-server/migrate-report-server 

    2. Consolidating 3 Env into One-

     Direct Database Merge is NOT Supported

    Each PBIRS environment has its own ReportServer database, There is no supported way to merge multiple, ReportServer databases ,IDs, metadata, and catalog structures will conflict. rathere then that you can keep seperate env -
    • Migrate each environment independently
    • Maintain DEV / UAT / PROD separation

    Alternatively Instead of merging everything technically Consider logical consolidation-

    • Single PBIRS instance
    • Separate folders for each environment
    • /DEV_Env1 ,/DEV_Env2, /DEV_Env3
    OR
    • Separate PBIRS instances:
      • PBIRS-DEV
      • PBIRS-UAT
      • PBIRS-PROD
     This keeps isolation while reducing infrastructure complexity. 
    Always use a side-by-side migration approach (old system stays live until validation is complete) 
    • Use DB restore approach for each individual environment

    •  Avoid trying to merge databases

    •  If consolidation is required, use content migration and logical separation.

    •  For simplicity and governance, maintaining separate environments is often the safest choice.

    Hope this helps clarify both the migration and consolidation paths.
     
    If This reply helps you finnd answer please mark it as asolution.
     
    Thank you 
    Sunita
trivedisunita's avatar
trivedisunita
Icon for Continued Contributor rankContinued Contributor
2 months ago

Hi Lorenz33 ,

Thanks for sharing and Yes, your understanding is correct.

PBIRS is a stateless service, meaning all content is stored in the ReportServer databases. When you Backup and restore

  • ReportServer 
  • ReportServerTempDBR

Restore the encryption key
Configure the new PBIRS instance to point to the restored database

 You will automatically bring over-

-Folder structure
-Reports (RDL + PBIX stored in PBIRS)
-Data sources
-Subscriptions
-Security (folder & item-level permissions)

This is the standard Microsoft-supported migration approach-https://learn.microsoft.com/en-us/power-bi/report-server/migrate-report-server 

2. Consolidating 3 Env into One-

 Direct Database Merge is NOT Supported

Each PBIRS environment has its own ReportServer database, There is no supported way to merge multiple, ReportServer databases ,IDs, metadata, and catalog structures will conflict. rathere then that you can keep seperate env -
  • Migrate each environment independently
  • Maintain DEV / UAT / PROD separation

Alternatively Instead of merging everything technically Consider logical consolidation-

  • Single PBIRS instance
  • Separate folders for each environment
  • /DEV_Env1 ,/DEV_Env2, /DEV_Env3
OR
  • Separate PBIRS instances:
    • PBIRS-DEV
    • PBIRS-UAT
    • PBIRS-PROD
 This keeps isolation while reducing infrastructure complexity. 
Always use a side-by-side migration approach (old system stays live until validation is complete) 
  • Use DB restore approach for each individual environment

  •  Avoid trying to merge databases

  •  If consolidation is required, use content migration and logical separation.

  •  For simplicity and governance, maintaining separate environments is often the safest choice.

Hope this helps clarify both the migration and consolidation paths.
 
If This reply helps you finnd answer please mark it as asolution.
 
Thank you 
Sunita