Forum Discussion
Copy Reports into Production Workspace
Hi
Hopefully someone can help. I have been asked to consolidate Power BI Workspaces, which I have been doing without any issues using Powershell script to copy reports to a workspace - which is the best solution for us in this instance. I now have all my reports from 2 workspaces in a single workspace.
However, we would like to take this one step further as we have been asked to add all of these reports into another workspace. The production workspace in a deployment pipeline.
Before I go ahead and copy the reports into the workspace, just wanted to check if anyone had experience of doing this? The reports are to remain static so a refresh is unnecessary. Normally when I deploy the report I have to refresh everything. We have stopped publishing directly to any production workspaces as well.
Sorry if this is basic question, I just wanted to check really.
Thanks
Karen
This is technically possible to do but it partially bypasses the pipeline model you’ve put in place.
When you use PowerShell (or the REST API) to copy reports into the Prod workspace:
- The reports will land successfully
- They will not be tracked as artifacts in the deployment pipeline
- Future pipeline deployments will not manage or overwrite those reports
- You risk drift between Dev/Test/Prod environments
In other words, you’re mixing two deployment paradigms:
- Pipeline-governed assets
- Manually injected assets
If this is a one-time consolidation and reports are static:
Do it, but treat it as an exception case with guardrails:
- Document that these reports are out-of-band from the pipeline
- Ensure:
- Dataset bindings are correct
- Permissions are revalidated
- Any shared datasets exist in Prod with matching schema
- Avoid future pipeline deployments that might:
- Overwrite workspace contents
- Create confusion about “source of truth”
Lookout for:
- Dataset binding mismatch; Same name ≠ same dataset ID
- Shared dataset dependencies; Reports may silently point back to non-prod datasets
- Endorsement & lineage loss; Certified/promoted status won’t carry cleanly
- App publishing; If you use Power BI Apps, you’ll need to republish after copying
2 Replies
This is technically possible to do but it partially bypasses the pipeline model you’ve put in place.
When you use PowerShell (or the REST API) to copy reports into the Prod workspace:
- The reports will land successfully
- They will not be tracked as artifacts in the deployment pipeline
- Future pipeline deployments will not manage or overwrite those reports
- You risk drift between Dev/Test/Prod environments
In other words, you’re mixing two deployment paradigms:
- Pipeline-governed assets
- Manually injected assets
If this is a one-time consolidation and reports are static:
Do it, but treat it as an exception case with guardrails:
- Document that these reports are out-of-band from the pipeline
- Ensure:
- Dataset bindings are correct
- Permissions are revalidated
- Any shared datasets exist in Prod with matching schema
- Avoid future pipeline deployments that might:
- Overwrite workspace contents
- Create confusion about “source of truth”
Lookout for:
- Dataset binding mismatch; Same name ≠ same dataset ID
- Shared dataset dependencies; Reports may silently point back to non-prod datasets
- Endorsement & lineage loss; Certified/promoted status won’t carry cleanly
- App publishing; If you use Power BI Apps, you’ll need to republish after copying
Hi andrewsommer
Thank you for your reply.
That is very thorough. It is a great check and very helpful I had a feeling it was technically possible, but was unsure. I have used the script to copy between workspaces successfully but not with a pipeline before.
As this would be a one time migration of some old reports, we would not want the data to be refreshed once the report and dataset lands into the production workspace. THis was my biggest concern. You are correct this would be out of sync once it lands, but I will make this clear to the owners of the report before this takes place. I am not sure they would worry as these are reasonably old.
Again thank you for your help, and I will make this as the solution.
Karen
