Migrating Reports to PostgreSQL Without Creating New Audience in Power BI App

[azeenk]

Hi Everyone,

In our Power BI workspace, we have an app that includes multiple audiences, each containing different catalogues with reports. Currently, we have three audiences, and all their reports are connected to an Oracle server.

We are now migrating reports for the first audience (named Zoogy) to a PostgreSQL server. These reports are organized under various catalogues within the Zoogy audience.

Here’s the challenge:
We want to publish the new PostgreSQL-based reports in the same app, ideally under the same Zoogy audience, without creating a new audience. Creating a new audience would require us to reassign access to all users, which we want to avoid.

Is there a way to:

• update the existing reports with the new PostgreSQL versions?(after one month will be replacing the existing reports)
• Keep them under the same audience and catalogues?
• Avoid duplicating audiences or reconfiguring user access?

Any suggestions or best practices to handle this migration smoothly within Power BI Service would be greatly appreciated.

Thanks in advance!!

[grazitti_sapna · Accepted solution]

Hi @azeenk 

Here are some best practices that you can follow to migrate the reports from Oracle to PostgreSQL without creatingnew audiences:

1. Prepare the New PostgreSQL Reports: Build and test all new reports connecting to PostgreSQL in a development or test workspace. Validate data accuracy and refresh.
2. Match Report Names and Structure: Use the exact same report names and organize them under the same catalogues in your workspace as the existing Oracle reports.
3. Republish to Overwrite Existing Reports: Publish the new PostgreSQL reports directly to the existing workspace, overwriting the Oracle reports. This preserves user access and audience settings.
4. Verify Refresh and Gateway Settings: Ensure proper gateway and credentials are configured for PostgreSQL datasets to avoid refresh failures after migration.

After following these steps, Inform the end users of the migration schedule and monitor report usage and refresh logs for any issues post-migration.

This approach avoids creating new audiences or reassigning permissions, ensuring a smooth transition. Do let us know if you need any further help or run into issues.

🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.

💡 Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.

🎖 As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.

🔗 Curious to explore more? [Discover here].

Let’s keep building smarter solutions together!

[v-kpoloju-msft · Accepted solution]

Hi @azeenk, 

Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thanks to @grazitti_sapna, for his inputs on this thread. 

You do not need to create a new audience or reconfigure access when migrating your Zoogy reports from Oracle to PostgreSQL. The app’s audiences and permissions are tied to the reports in the workspace, not the data source. What you can do is below mentioned.

Open the migrated PostgreSQL version of each Zoogy report in Power BI Desktop. Publish it back to the same workspace, with the same report name, so it overwrites the Oracle version. Once all reports are replaced, just click Update App.

This way, your Zoogy audience and catalogues remain intact, and users do not experience any change in navigation or permissions. The only thing that changes is the backend source. If you prefer, you can also parameterize the data source in Power BI Desktop, making it easier to switch from Oracle → PostgreSQL without rebuilding the reports.

Refer these links:
1. https://learn.microsoft.com/en-us/power-bi/guidance/migrate-ssrs-reports-to-power-bi 
2. https://learn.microsoft.com/en-in/power-bi/collaborate-share/service-create-distribute-apps#update-o... 
3. https://learn.microsoft.com/en-us/power-query/connectors/postgresql 

Hope this clears it up. Let us know if you have any doubts regarding this. We will be happy to help.

Thank you for using the Microsoft Fabric Community Forum.

[v-kpoloju-msft]

Hi @azeenk,

Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.

Thank you.

[v-kpoloju-msft]

Hi @azeenk,

Hope you had a chance to try out the solution shared earlier. Let us know if anything needs further clarification or if there's an update from your side always here to help.

Thank you.

[v-kpoloju-msft]

Hi @azeenk,

Just wanted to follow up one last time. If the shared guidance worked for you, that’s wonderful hopefully it also helps others looking for similar answers. If there’s anything else you'd like to explore or clarify, don’t hesitate to reach out.

Thank you.

[grazitti_sapna · Accepted solution]

Hi @azeenk 

Here are some best practices that you can follow to migrate the reports from Oracle to PostgreSQL without creatingnew audiences:

1. Prepare the New PostgreSQL Reports: Build and test all new reports connecting to PostgreSQL in a development or test workspace. Validate data accuracy and refresh.
2. Match Report Names and Structure: Use the exact same report names and organize them under the same catalogues in your workspace as the existing Oracle reports.
3. Republish to Overwrite Existing Reports: Publish the new PostgreSQL reports directly to the existing workspace, overwriting the Oracle reports. This preserves user access and audience settings.
4. Verify Refresh and Gateway Settings: Ensure proper gateway and credentials are configured for PostgreSQL datasets to avoid refresh failures after migration.

After following these steps, Inform the end users of the migration schedule and monitor report usage and refresh logs for any issues post-migration.

This approach avoids creating new audiences or reassigning permissions, ensuring a smooth transition. Do let us know if you need any further help or run into issues.

🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.

💡 Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.

🎖 As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.

🔗 Curious to explore more? [Discover here].

Let’s keep building smarter solutions together!