Updated March 11, 2026
NOTE: Important Update on Legacy Reporting and Analytics with Australia Release
UPDATE (March 2026): In March 2025, we announced that the ability to create new Core UI content (dashboards and reports) would be discontinued beginning with the Australia release. Based on customer feedback requesting additional transition time, we have extended this timeline — new Core UI content creation will remain available through the end of 2027, regardless of release family.
This is a reference guide to use in planning your migration from Core UI (or Classic) reporting and dashboards to Platform Analytics experience. This is an ongoing work in progress and will be updated frequently...
Platform Analytics recommended migration path
High level summary
- Plan for what content will be migrated and what stays in Core UI
- Work with a sub-production instance that contains all the latest updates to dashboard and reports (recent clone of production)
- Run a full migration (“Start moving”) in sub-production
- Activate the migration in sub-production
- Review the content in subprod, making any needed changes on the pre-migrated content in an active update set
- Once complete, test and promote the update set to Production
- Run the “Try it” migration as needed to verify update set changes are present
- Run full migration (“Start moving”) in Production
- Activate the migration in Production
Key Zurich updates:
- Dashboard owners can now choose what to migrate and when to migrate dashboards they own.
- It is now easier to select which reports to migrate at any given time
Stage 0 - Planning
In this stage you should consider what content you will and will not migrate. Consider whether more complex dashboards, including dashboards with Dynamic Content Blocks or other custom code, should be migrated at all. In many cases it will be simpler and more accurate to recreate the content using a Technical Dashboard. Technical Dashboards have the ability to use complex and custom code by default, so most content created in a Technical Dashboard should be future-proof against future upgrades. Custom content blocks in Core UI, just like any other platform customizations, are not supported by upgrades.
A common path many organizations are planning to follow is migrating most of their content, and leaving the most complex content in Core UI until the Technical Dashboard replacement is built..
Stage 1 - Migrate everything in sub-Production
A full migration in subprod is the easiest way to see and review your dashboards and reports prior to committing to them in production. The “Try your content” option is for those who want a quick preview of individual dashboards prior to having them reviewed by consumers.
- Make sure you start from a current clone of Production in a sub-Production environment. It’s important that the subprod dashboards and reports match prod as closely as possible.
- Create an update set (or application) in sub-prod to track modifications you make to dashboards, widgets, and reports. You can then apply the update set in production prior to the production migration
- In the subprod environment, run the “full migration” option from the Migration Center main page. This provides you an interface to review all Core UI Dashboards and Reports. It also allows you to view the before and after versions of all content.
- Under “Move all of your content” select “Start moving.”
- Review the preview and click “Migrate”.
NOTE: At this point, all that’s been done is making a copy of the legacy content. The original version is still intact and available via the Navigator as usual.
Stage 2 – Initial review of results
Compare/review all migrated content
- Identify content that is migrated in Compatibility Mode.
- Compare the before and after versions of the components migrating in Compatibility mode.
- Review the logs
- In Zurich or later, consider having dashboard owners review their own dashboards.
- For each component in Compatibility mode, you have the following choices:
- Keep it in Compatibility mode when migrating in Production.
- Modify the Core UI version of the content to make it compatible with the migration. Many of the log entries identify what caused the item to migrate in Compatibility mode.
- Recreate the content in Platform Analytics experience. This ensures that the recreated content will always be compatible with PAe, thereby minimizing future upgrade issues and other administrative overhead.
- Mark the item “Do not migrate in bulk”. This ensures the production migration skips this item.
TIP: Keep the migration update set you created in Stage 1 active during these tasks. Any modifications you make to the Core UI version of content, including marking it “Do not migrate in bulk”, along with any new versions you create in Platform Analytics experience, will transfer with the update set when moved to production. The Migration center itself, and any content moved by the migration center is NOT captured in the update set. The migration needs to be run separately in Production after applying the update set.
- Mark any content you do not want to migrate to “Do not migrate in bulk”.
- (Optional) Review the “Fully migrated” content. Keep in mind that “Fully migrated” doesn’t guarantee that the dashboard, widget, or report will look exactly as it did in Core UI. We mark this as optional if you have the content owners review for themselves in subprod.
Stage 3 – Activation and stakeholder review
This option puts the review of migrated content into the hands of the content owners and consumers. We do this in subprod.
UPDATE SET NOTE: Change the current update set so it is NOT the update set created in Stage 1, step 2.
We don’t want the changes made by the Activate step to be recreated in prod via update set. We want to run Activate in Prod later using the Migration Center to keep everything in sync.
- In the subprod instance, click the “Activate” button
- Content owners and stakeholders can review the content and the menu structure 3. Again, make any needed changes to the Core UI (pre-migrated) versions of content.
Stage 4 - Promote and apply update set in production
Stage 5 – Run full migration in production
Stage 6 – Activate in production
Appendix
|
|
|
|
|
|
|
Mark content to not migrate
Mark legacy content to not migrate (Do not migrate)
Important system properties (sys_properties)
- com.glide.par.unified_analytics.enabled (PAe active: true/false)
- glide.par.coreui.migration.bulk_rollback_enabled (Entire migration rollback)
Core tables
- par_dashboard: Migrated dashboards, and all PAe native dashboards
- pa_dashboards: Core UI (Legacy) dashboards
- more to come…
NOTE: Do not update content in Bridge tables. Bridge tables extend sys_metadata and NOT captured in update sets
Custom filters & content blocks
Custom filters and content blocks should be identified and recreated in PAe after the production activation. The custom code/scripting does not migrate to PAe. Recreating the content in PAe allows you to make the content more upgrade-proof, because the tools in the PAe Technical editor are the same as UI Builder. The platform now creates dashboard content customizations that are part of the core platform capabilities, significantly reducing tech debt.
Key optional migration tasks
Remove Core UI analytics content from bulk migration
Editors of the Core UI analytics artifacts tables can perform this action.
All the Core UI tables have an extra column in which admins can specify if they want to remove those artifacts from the bulk migration.
The column is called “Do not migrate in bulk” and is available for these tables:
- pa_dashboards
- pa_widgets
- sys_report
- sys_ui_hp_publisher
Additional resources:
15 Comments
