Best practices for upgrading classic cloud monitoring
Latest Dynatrace
Best practices
Published Aug 24, 2026
Cloud Platform Monitoring in Latest Dynatrace introduces a completely new architecture for monitoring cloud environments across AWS, Azure, and GCP. The new architecture uses a different entity model, metric keys, enrichment approach, and onboarding process. These best practices help you plan and execute the migration without monitoring gaps.
Treat this as a full migration, not an in-place upgrade
The latest Cloud Platform Monitoring architecture is not a version increment of classic cloud monitoring; it is a fundamentally different approach. Do not attempt to migrate by adjusting existing classic cloud integration settings. Plan and execute a full migration using the latest cloud connection onboarding process for each cloud provider.
The key differences that make this a full migration:
New entity model: cloud resources are represented differently in the latest entity model. Existing entity selectors, management zone rules, and tagging strategies that reference classic entity types will not work.
New metric keys: classic cloud integration metrics use different key names than latest Cloud Platform Monitoring metrics. Dashboards and alerts that reference classic metric keys must be rebuilt.
New enrichment approach: cloud tag propagation and Primary Grail Field enrichment replace the classic tagging and host group model.
New onboarding process: the latest cloud connection uses a different authentication and discovery mechanism than classic cloud integrations.
Existing dashboards, alerts, management zones, tagging strategies, and integrations will not work after migrating to the latest cloud connection. Budget time to rebuild each of these before retiring the classic integration.
Plan for parallel operation during transition
Run the classic cloud integration and the latest cloud connection in parallel during the transition period. Parallel operation lets you validate data parity between the two integrations, rebuild dependent configurations against real data, and confirm monitoring coverage before decommissioning classic.
Plan the parallel operation phase with the following steps:
Set up the latest cloud connection alongside the existing classic integration; do not disable the classic integration yet.
Confirm that cloud resources are discovered and enriched with expected metadata in the latest connection.
Run equivalent DQL queries and compare metric values between classic and Latest Dynatrace to confirm data parity.
Rebuild dashboards, alerts, and access control configurations against the latest data.
Confirm that all dependent configurations are validated before retiring the classic integration.
Parallel operation may incur additional monitoring costs during the transition period. Agree on the duration of parallel operation with stakeholders before starting.
Rebuild dashboards, alerts, and tagging for the new model
All classic cloud monitoring configurations that reference cloud-specific entities, metric keys, or management zone filters must be rebuilt for the latest Cloud Platform Monitoring model. This includes:
Dashboards: tile queries that use classic cloud metric keys must be rewritten to use the equivalent latest Cloud Platform Monitoring metric keys and DQL syntax.
Alerts: anomaly detectors and metric event configurations referencing classic cloud metric keys must be updated to reference the latest metric equivalents.
Tagging: classic auto-tag rules that matched on cloud entities must be replaced with enrichment-based Primary Grail Tags configured through the latest cloud connection.
Identify the complete list of dashboards, alerts, and tagging rules that depend on classic cloud monitoring before starting the migration. Use this list as your migration backlog and track completion before retiring the classic integration.
Validate data parity before retiring classic integration
Confirm that the latest cloud connection provides equivalent monitoring coverage to the classic integration before disabling it. Data parity validation should include:
Resource discovery: confirm that all cloud accounts, resource groups, and resource types visible in classic are also discovered by the latest connection.
Metric coverage: confirm that equivalent metric keys exist in the latest connection for every classic metric used in active dashboards and alerts.
Enrichment coverage: confirm that cloud tags and attributes are propagated to signals as expected.
Alert coverage: confirm that rebuilt alert configurations fire correctly against the latest monitoring data.
Only retire the classic integration after each of these validation checks passes and the team confirms the latest experience meets their operational needs.