Try it free

Upgrade from classic to new cloud connections

  • Dynatrace Classic
  • Upgrade guide
  • 15-min read
  • Published Aug 13, 2026

This guide helps you plan and execute an upgrade from classic to new cloud connections in Clouds Clouds.

Why upgrade?

Upgrading to the new cloud connections offers benefits as it unlocks access to Cloud Platform Observability based on Latest Dynatrace and a new Clouds Clouds experience.

No infrastructure to manage

Platform-managed cloud connections replace the ActiveGate (AWS, Azure) and self-hosted GKE workload (GCP) required by classic connections. Dynatrace handles connection setup, telemetry ingestion, and topology discovery.

Broader coverage with curated content

Broader and deeper coverage of AWS, Azure, and Google Cloud services are supported by default. Ready-made dashboards and health alerts for each service are maintained by Dynatrace and available immediately after setup. Scope ingestion by cloud account, region, or cloud tag.

All data is queryable

Metrics, logs, events, traces, and topology from all cloud providers land in Grail. Query them with DQL across Clouds Clouds, []Dashboards Dashboards](dashboards), Notebooks Notebooks, and []Workflows Workflows](workflows).

Use segments and primary Grail fields & tags as consistent filters across apps.

Automatic topology mapping

Smartscape maps your full cloud environment within minutes, including resource-to-resource relationships. Query full resource configuration to analyze drift, resource consumption, or compliance posture.

AI-assisted analysis

Dynatrace Intelligence answers natural-language questions about your Grail data. Generative AI skills for AWS, Azure, and GCP are available in Dynatrace Assist or via the GitHub repository.

What is new?

When you migrate to the new cloud connections, each cloud provider gets its own separate ingestion path, and all data is stored in Grail. Because of this, the entity model and metric shape change from what you had before. These changes matter during migration, since you'll need to update existing dashboards, alerts, notebooks, workflows, or custom integrations that rely on the Dynatrace API.

AWS

New type of AWS connection that is used by Dynatrace platform for ingesting data from AWS (CloudWatch, AWS APIs, Amazon S3, and Eventbridge). The new AWS connections introduce changes to:

Topology model

AWS resources are represented as Smartscape nodes (entities) named from AWS resource types (for example, AWS_EC2_INSTANCE, AWS_LAMBDA_FUNCTION, AWS_RDS_DB_INSTANCE) instead of dedicated classic entity types (EC2_INSTANCE) or CUSTOM_DEVICE entries. Smartscape edges define the relationships between different Smartscape nodes (for example, AWS_EC2_VOLUME is attached to AWS_EC2_INSTANCE).

Metric shape

Metric keys follow the pattern cloud.aws.<Service>.<Metric>.By.<Dimension> and carry a dt.da.source dimension (for example, aws-metric-poller) so you can distinguish new metrics from classic ones.

Connection and deployment

The new AWS connections use the Dynatrace platform to establish a connection between AWS and Dynatrace. Cloud platform monitoring no longer requires an ActiveGate. You can scope the deployment by AWS account or organization.

For more details, see new AWS connection and supported services and metrics.

Azure

New type of Azure connection that is used by Dynatrace platform for ingesting data from Microsoft Azure (Azure Monitor, Azure APIs, and Azure Event Hubs). The new Azure connections introduces changes to:

Topology model

Azure resources are represented as Smartscape nodes (entities) named from the ARM resource type (for example, AZURE_MICROSOFT_COMPUTE_VIRTUALMACHINES, AZURE_MICROSOFT_SQL_SERVERS_DATABASES) instead of dedicated classic entity types (AZURE_VM) or CUSTOM_DEVICE entries. Subscriptions, resource groups, and resources all become first-class topology nodes.

Metric shape

Metric keys follow the pattern cloud.azure.<namespace>.<Metric> and carry dt.da.source == "azure-metric-poller".

Connection and authentication

The new Azure connections are leveraging the Dynatrace platform to create a connection between Azure and Dynatrace using a federated identity credential authentication and a service principal with the Reader role on the target subscriptions. No ActiveGate is involved for cloud platform monitoring anymore.

For more details, see new Azure connection and supported services and metrics.

GCP Preview

New type of Google Cloud connection that is used by Dynatrace platform for ingesting data from Google Cloud Platform. The new GCP connections introduce changes to:

Topology model

GCP resources are represented as Smartscape nodes (entities) named from the API resource type (for example, GCP_COMPUTE_GOOGLEAPIS_COM_INSTANCE, GCP_CLOUDSQL_GOOGLEAPIS_COM_INSTANCE), replacing the classic representation of every GCP resource as a CUSTOM_DEVICE with a cloud:gcp:* sub-type.

Metric shape

Metric keys follow the pattern cloud.gcp.<service>.<Metric> with dt.da.source == "gcp-cloud-monitoring".

Connection and authentication

The new GCP connections are leveraging the Dynatrace platform to create a connection between GCP and Dynatrace using a service account authentication via Workload Identity Federation. The classic GCP integration's self-hosted GKE workload is no longer required.

You can request access to the new Cloud Platform Monitoring for Google Cloud.

What is changing?

Topology model: Classic entity IDs do not carry over

A classic EC2_INSTANCE and the new AWS_EC2_INSTANCE for the same machine are different entities with different IDs. Dashboards, alerts, and SLOs that leverage classic entity IDs and selectors must be updated accordingly.

A machine monitored under classic monitoring and under the new cloud monitoring is represented as two separate entities, each with its own type and ID.

The classic EC2_INSTANCE and the new AWS_EC2_INSTANCE refer to the same physical machine but are not the same entity, so any dashboard, alert, or SLO that references classic entity IDs or selectors must be updated to use the new ones.

For example, the same EC2 instance might be identified as:

  • Classic: EC2_INSTANCE-0A1B2C3D4E5F6789
  • New: AWS_EC2_INSTANCE-9F8E7D6C5B4A3210
  • Both point to the same underlying machine, but a selector like type (EC2_INSTANCE) or a hard-coded ID of EC2_INSTANCE-0A1B2C3D4E5F6789 will no longer match anything in the new model.

See Metric and entity mapping for mapping of classic entities to new Smartscape nodes.

Cloud metrics: Metric keys are unified

All cloud metric keys are aligned with cloud provider conventions and follow a common pattern:

  • AWS: cloud.aws.<cloudwatch namespace>.<aws metric name>.By.<Dimension 1>.<Dimension N> (see Integrated AWS cloud services)
  • Azure: cloud.azure.<azure resource provider>.<azure resource type>.<azure metric name> (see Supported Azure services)
  • GCP: cloud.gcp.<gcp resource type>.<gcp metric path>.<gcp metric name> (see Supported GCP services (Preview))

See Metric and entity mapping for mapping of classic metrics to new Smartscape nodes.

Alerting: From classic metric events and classic anomaly detection to health alerts and warning signals

Classic cloud connections offered a set of out-of-the-box templates for metric events as well as a handful of infrastructure anomaly detectors for AWS. These metric events and anomaly detectors for alerting are based on Dynatrace Classic and do not work with the new cloud connections (different metric keys, different alerting engine).

In Latest Dynatrace, you can now create health alerts and warning signals based on the new cloud connections. We provide a recommended set of health alerts that can be added after onboarding your cloud account(s). In addition, you can easily create custom alerts based on cloud alert templates.

New ready-made dashboards

Alongside the new cloud connections, we've also released new ready-made dashboards for each cloud provider.

What is not changing?

Licensing

New connections require a DPS license with the Grail capabilities listed in the Clouds app prerequisites.

Classic connections continue to work with both DPS and classic licensing.

Cloud-side configuration

Existing IAM roles, service principals, and service accounts used for classic connections stay in place until you remove them.

New connections add their own authentication—they don't reuse the classic credentials.

Manual cutover

Classic cloud connections stay running until you turn them off. Existing connections are not automatically upgraded or removed.

Historical data

Historical metric, entity, and topology data from classic connections is retained according to your environment's data retention settings.

The Explorer Classic tab in Clouds Clouds and the classic AWS, Azure, and GCP apps continue to surface that data.

Capabilities not yet available

AWS CloudWatch Metric Streams Coming soon

  • Not yet supported by new AWS connections. If you rely on Metric Streams today, keep that classic ingestion path until support ships.
  • Classic polling-based AWS metrics on the same account can still migrate independently.

What will you do?

  1. Select one low-risk cloud account (AWS), subscription (Azure), or project (GCP) and plan the upgrade.
  2. Create a new cloud connection for this account and then follow this guide to discover, analyze, plan and execute the upgrade of all related assets (such as dashboards, alerts, and management zones).
  3. Upgrade all related assets.
  4. Enable telemetry ingest for the new connection (in parallel to the classic connection) to finally verify that topology, metrics, logs and events are flowing in and your assets are capable of dealing with the new entity types and metric keys.
  5. Then disable—but not yet delete—the classic connection to minimize the time running classic and new in parallel.
  6. Finally, create new connections for all cloud connections and repeat the verification of data and disablement of classic connections.
  7. Delete classic connections and, if applicable, related resources (classic credentials, ActiveGates in case they have been used only for Cloud Platform Monitoring).

Before you begin

Prerequisites

Review the full Clouds Clouds prerequisites before you start.

Dynatrace environment and license

  • Dynatrace SaaS environment powered by Grail and AppEngine, hosted in a region eligible for new cloud connections.
  • DPS license with the following capabilities:
    • Metrics powered by Grail
    • Logs powered by Grail
    • Events powered by Grail

Cloud-side access

You'll need new credentials on the cloud side—new connections don't reuse the classic ones.

  • AWS—IAM cross-account role (or AWS Web Identity) with read access to the services you want to monitor.
  • Azure—App registration with a federated identity credential, plus a service principal granted the Reader role on the target subscriptions.
  • GCP—Service account with the Viewer role on the target projects, accessed via Workload Identity Federation.

For per-cloud detail, see Create a new AWS connection, Create a new Azure connection, and Create a new GCP connection.

Plan your upgrade

  • Start with a low-risk account

    Start with a development or staging cloud account to validate the end-to-end flow before making any changes to production.

  • Don't run both connection types against the same account for an extended period

    Classic and new connections can coexist across a mixed set of accounts—for example, some AWS accounts on classic while others use the new connection. What we don't recommend is running both connection types against the same AWS account, Azure subscription, or GCP project for an extended period, because doing so has a two-fold impact:

    • Duplicated cost—Both connections independently ingest the same topology and metrics, so you pay for the same data twice.
    • Potential cloud API throttling—Each connection makes its own calls to the cloud provider's monitoring APIs (such as AWS CloudWatch). Running both doubles the call volume against that account. Cloud providers cap how many API requests you can make in a given time window; when you exceed that cap, the provider begins throttling—rejecting or delaying requests until the rate drops back under the limit. In most cases this just slows polling, but in severe cases throttled requests can cause gaps in ingested data.

    Running both connection types against the same account for a short, well-defined window—for instance, during a migration cutover—is expected and fine. The guidance is simply to avoid leaving both running against the same account long-term, so you don't carry duplicated charges or risk hitting API rate limits.

    If you do need to run both connections concurrently for a period, or you're approaching your provider's API limits for other reasons, we recommend working with your cloud provider's support team to request API rate limit increases where applicable. This can help avoid throttling and the data gaps it may cause during the overlap.

  • Inventory your dependent assets per cloud account before you cut over.

    Dashboards, alerts, SLOs, anomaly detectors, and workflows that reference classic metric keys or entity types need to be re-pointed at the new metric keys and Smartscape node types.

  • Decide on an alert strategy.

    Either create the new alerts in a disabled state and switch over at cutover (no alerting gap), or migrate alerts only after the classic connection is disabled (accepting a brief gap). The right choice depends on environment criticality.

Asset impact awareness

Plan a small remediation pass on the assets that depend on classic cloud data.

  • Dashboards

    Tiles using classic metric keys (dt.cloud.<provider>.*, builtin:cloud.<provider>.*, ext:cloud.<provider>.*) or entity selectors (fetch dt.entity.<classic_type>) need new keys and Smartscape queries. See Worked examples.

  • Alerts

    • Metric event alerts: Replace alerts that reference classic metric keys by switching to ready-made health alerts and/or create custom alerts using new metric keys.

    • Anomaly detectors and custom alerts: Replace DQL-based custom alerts with new metric keys.

    • Anomaly detection for classic AWS services: Switch to ready-made health alerts in order to replace classic alerts that were enabled in classic infrastructure anomaly detection settings for AWS (builtin:anomaly-detection.infrastructure-aws)

  • SLOs

    SLOs that use metric selectors against classic keys must be converted to DQL form and updated to the new metric keys.

  • Workflows

    Any workflow step that filters on classic entity types or metric keys needs the new equivalents.

For environments with many accounts and a large dashboard/alert/SLO inventory, see Need help with a large estate?.

The upgrade approach

The recommended sequence for each cloud account, subscription, or project:

Step 1: Set up a new connection in parallel

While your classic connection keeps running, create a new connection for the target account by following Create AWS connection or [Create Azure connection. Don't remove or disable the classic connection at this stage—the two run side by side for now.

Step 2: Validate topology

Smartscape nodes typically appear within ~10–15 minutes of setup.

Confirm the expected resource categories and counts in the Explorer New tab, then sanity-check counts against the equivalent view in Explorer Classic tab.

Step 3: Migrate dependent assets

Update the dashboards, alerts, SLOs, anomaly detectors, and workflows you identified in Asset impact awareness.

For dashboards and SLOs, re-point queries to the new metric keys and Smartscape node types.

For alerts and anomaly detectors, re-create the inputs against the new metric keys (consider creating them disabled to avoid double alerting).

Step 4: Switch over

Configure the new cloud connection to ingest all telemetry data you are expecting. Once new metrics are flowing and the migrated assets work, disable the classic connection. Keep it disabled (not deleted) for one to two weeks as a rollback buffer.

  • AWS—Disable via Settings Settings > Collect and Capture > Cloud and virtualization -> AWS Classic (schema builtin:cloud.aws).
  • Azure—Disable via Settings Settings > Collect and Capture > Cloud and virtualization -> Azure Classic (schema builtin:cloud.azure).
  • GCP—Stop or remove the GKE workload that runs the classic integration.

Step 5: Decommission classic

After the buffer period, with no remaining dependencies, you can delete the classic connection. Deleting a connection is an operation that cannot be reverted.

Historical classic data remains in Dynatrace and ages out according to retention.

Worked examples

One small before/after DQL snippet per cloud. Use these as a pattern when re-pointing your own queries.

  • Classic (entity-based query):

    fetch dt.entity.ec2_instance
    | fields entity.name, awsAccountId, awsRegion

  • New (Smartscape on Grail):

    smartscapeNodes AWS_EC2_INSTANCE
    | fields name, `aws.account.id`, `aws.region`

Metric keys shift from dt.cloud.aws.* / cloud.aws.* / builtin:cloud.aws.* to cloud.aws.<Service>.<Metric>.By.<Dimension> with dt.da.source == "aws-metric-poller".

  • Classic (entity-based query):

    fetch dt.entity.azure_vm
    | fields entity.name, azureSubscriptionUuid, azureRegion

  • New (Smartscape on Grail):

    smartscapeNodes AZURE_MICROSOFT_COMPUTE_VIRTUALMACHINES
    | fields name, `azure.subscription`, `azure.region`

Metric keys shift from builtin:cloud.azure.* and ext:cloud.azure.* to cloud.azure.<namespace>.<Metric> with dt.da.source == "azure-metric-poller".

  • Classic (every GCP resource is a custom device):

    fetch dt.entity.custom_device
    | filter contains(customDeviceType, "cloud:gcp:gce_instance")

  • Preview New (Smartscape on Grail):

    smartscapeNodes GCP_COMPUTE_GOOGLEAPIS_COM_INSTANCE
    | fields name, `gcp.project.id`, `gcp.region`

Metric keys shift from ext:cloud.gcp.* to cloud.gcp.<service>.<Metric> with dt.da.source == "gcp-cloud-monitoring".

See Metric and entity mapping for

Need help with a large estate?

For environments with many cloud accounts and a significant inventory of dashboards, alerts, and SLOs that reference classic cloud data, we offer an assisted migration.

Your Dynatrace Account Team can coordinate a guided exercise that discovers your active classic connections, scans your dashboards, alerts, and SLOs for classic references, produces a per-asset remediation plan, and supports you through the cutover.

Reach out to your Dynatrace contact if you'd like to scope this for your environment.

FAQ

Will my classic data disappear when I disable the classic connection?

No. Disabling a classic connection stops new data ingestion from classic polling, but existing metrics, entities, and topology data are retained according to your environment's retention settings.

You can still query historical classic data and continue to use the Explorer (Classic connections) tab.

Can I run classic and new connections on the same AWS account or Azure subscription?

It's not recommended. Across a heterogeneous set of accounts, classic and new connections can co-exist—some classic, some new.

But on the same account or subscription, running both at once leads to double ingestion of topology and metrics.

Migrate one account at a time and cut over cleanly.

I use AWS CloudWatch Metric Streams—can I migrate today?

Partially. Metric Streams is not yet supported in new AWS connections, so accounts that rely exclusively on Metric Streams should wait.

If the account also uses classic polling-based AWS metrics, you can migrate that portion to a new connection and continue using the Metric Streams pipeline in parallel until new connection support ships.

Do my existing dashboards keep working during the parallel run?

Yes. Dashboards built on classic metric keys and entity types continue to render from classic data for as long as the classic connection is running.

Once you disable the classic connection, those dashboards stop receiving new data—which is why you re-point them to the new metric keys before cutting over.

When should I delete (rather than just disable) the classic connection?

Keep the classic connection disabled for one to two weeks after cutover as a rollback buffer.

Once you're confident that all migrated dashboards, alerts, and SLOs are functioning and no further dependencies surface, you can delete the classic connection.

Historical classic data is retained independently and is not affected by the deletion.

Related tags
CloudsCloudsInfrastructure Observability