Upgrade configurations and settings

Latest Dynatrace
Upgrade guide
Published Jul 24, 2026

With capabilities in Latest Dynatrace in place, migrate the remaining foundational configurations before starting the dashboards and alerting upgrades. This stage covers service naming rules, service detection, calculated metrics, processing rules, SLOs, and RVA monitoring rules, all of which are direct dependencies for upgrading dashboards and metric alerting.

Coordinate with dashboard and alert owners first: metrics and SLOs feed dashboards and alerts. Upgrading them without coordinating with stage 7 and stage 8 creates a cascading update chain. Communicate changes to dashboard and alert owners before starting this stage.

Why upgrade?

Migrating your foundational configurations—service naming, metrics, SLOs, and processing rules—to Latest Dynatrace clears the dependency chain for dashboards and alerting: until calculated metrics and SLOs have Grail-backed equivalents, stage 7 and stage 8 cannot start.

Classic calculated metrics are precomputed with fixed dimensions and limited aggregation options. Latest Dynatrace metrics are backed by Grail, enabling advanced filtering, on-the-fly aggregation, and no metric explosion.

Grail-backed metrics: advanced filtering and aggregations without metric explosion, not limited to precomputed metrics and static dimensions

What will you do?

These configurations are dependencies for stage 7 and stage 8; complete all six sub-steps before starting either stage.

Migrate service naming rules to OpenPipeline
Upgrade service detection rules to SDv2
Replace calculated metrics with DQL-based Grail equivalents
Migrate processing rules to OpenPipeline
Rebuild SLOs in Latest Dynatrace and validate accuracy against classic baselines
Upgrade RVA monitoring rules to Latest Dynatrace security configuration

Before you begin

At a glance

Estimated effort: 3–10 days
Estimated timeline: 1–4 weeks

Prerequisites

Upgrade observability data & settings

Key stakeholders

Role	Involvement	Responsibility
Dynatrace Admin	Required	Primary configuration owner for naming rules, metrics, SLOs, and security settings
Application Team Leads	Recommended	Validate that service names, metrics, and SLOs match expected values after migration
SRE / Observability Eng.	Recommended	Own calculated metric and SLO definitions that need conversion to DQL-based equivalents

Upgrade your configurations and settings

1. Migrate service naming rules to OpenPipeline

Inventory all active classic service naming rules and recreate equivalent naming logic in OpenPipeline.

Export all active classic service naming rules and document their conditions and naming patterns.
Identify the equivalent OpenPipeline processor type for each rule.
Recreate each naming rule in OpenPipeline, preserving the original condition logic.
Deploy the OpenPipeline configuration and compare resulting service names against classic baselines.
Adjust rules where naming output differs from expected values.

Verify: Ratio of classic service naming rules vs. OpenPipeline equivalents at target coverage; service names match expected values across all monitored services.

Validate naming output before starting downstream stages: OpenPipeline naming rules may not produce identical output to classic rules. Differences in service names break dashboard queries and alert scopes in stage 7 and stage 8. Validate naming output before starting those stages.

2. Upgrade service detection rules

Migrate service detection configuration to SDv2 classic runtime to ensure services are correctly detected under the Latest Dynatrace entity model.

Review all active classic service detection rules and document their conditions.
Migrate each rule to the SDv2 classic runtime equivalent.
Validate that service detection produces the expected services under the new configuration.
Confirm that any custom detection rules are functioning correctly after migration.

Verify: All service detection rules migrated to SDv2; services detected correctly against expected baselines.

3. Upgrade calculated metrics to DQL and Grail

Inventory all classic calculated metrics and their consumers, then replace them with DQL-based equivalents that query Grail directly.

Export all active classic calculated metrics and document their entity selectors, dimensions, and aggregation methods.
Identify all consumers of each metric—dashboards, alerts, and SLOs—so you can update them after migration.
Write DQL-based metric queries that produce equivalent output for each calculated metric.
Validate metric values between classic and DQL-based versions using parallel queries.
Update each consumer (dashboard tiles, alert thresholds, SLO queries) to use the DQL-based metric.

Verify: Ratio of classic calculated metrics vs. DQL-based equivalents at target coverage; metric values align between classic and Grail-backed queries.

Validate complex metric conversions carefully: metrics with complex entity selectors or multi-dimensional splits require careful DQL translation. Incorrect conversions produce silent data discrepancies that only surface during downstream dashboard or alert validation.

4. Migrate processing rules to OpenPipeline

Inventory and recreate all active classic processing rules for logs and business events in OpenPipeline.

Export all active classic processing rules for logs and business events.
Document the logic, conditions, and transformations for each rule.
Recreate each rule as an OpenPipeline processor with equivalent logic.
Validate that processed output matches the classic processing behavior.

Verify: All active classic processing rules recreated in OpenPipeline; processing output validated against classic baselines.

5. Upgrade SLOs and validate accuracy

Rebuild classic SLOs in Latest Dynatrace backed by Grail data and confirm metric parity against classic baselines.

Document all classic SLO definitions: metric source, target percentage, evaluation window, and consumer dashboards or alerts.
Create equivalent SLOs in Latest Dynatrace using the DQL-based metrics upgraded in the previous step.
Run both classic and latest SLOs in parallel for at least one full evaluation window.
Compare SLO burn rates and metric values between classic and latest to confirm parity.
Update any dashboard tiles or alert conditions that reference classic SLO metrics.

Verify: Ratio of classic SLO definitions vs. Latest Dynatrace equivalents at target coverage; SLO burn rates and metric values match classic baselines within an acceptable variance.

Document acceptable variance before decommissioning: Latest Dynatrace SLOs backed by Grail may calculate slightly differently than classic SLOs during the parallel validation period. Document the variance and agree on an acceptable threshold before decommissioning classic SLOs.

6. Upgrade RVA monitoring rules

Recreate classic runtime vulnerability analysis rules using the Latest Dynatrace security configuration and validate entity coverage.

Export or document all active classic RVA 3rd-party monitoring rules.
Recreate each rule in the Latest Dynatrace security settings using the equivalent configuration.
Validate that the same entity types are covered by the new rules.
Confirm that vulnerability detection fires correctly against the migrated rules.

Verify: Ratio of classic vs. Latest Dynatrace RVA monitoring rules at target coverage; entity coverage and vulnerability detection validated.

Stage complete when:

All service naming rules, service detection, processing rules, and RVA monitoring rules are migrated to Latest Dynatrace equivalents at target coverage
Calculated metrics have DQL-based equivalents and metric values align with classic baselines
SLO burn rates and metric values match classic baselines within the agreed variance threshold

With configurations and settings migrated, you've established the foundation that dashboards and alerting both depend on. The next two stages—Upgrade classic dashboards and Upgrade metric alerting and maintenance windows—share this prerequisite and can run in parallel. Coordinate across teams to assign ownership before starting both stages simultaneously.

Documentation and best practices

The following resources support your work in this stage. Documentation covers platform concepts, configuration reference, and related guides; best practice cards provide implementation guidance from Dynatrace experts.

Service Detection v2

Reference for migrating service detection configuration to SDv2 classic runtime.
Upgrade from Metrics Classic to Metrics on Grail

Reference for migrating classic calculated metrics and metric selectors to DQL-based Grail equivalents.
Upgrade from classic pipeline to OpenPipeline

Guide for recreating classic processing rules as OpenPipeline processors.
Upgrade from Service-Level Objectives Classic to Service-Level Objectives

Step-by-step guide for rebuilding classic SLOs in Latest Dynatrace backed by Grail data.
Best practices for upgrading SLOs

Rebuild classic SLOs as Grail-backed definitions, validate metric parity, and prepare for the Smartscape 2.0 entity migration.

Ready for more?

Once configurations and settings are migrated, the next two stages can start simultaneously; assign ownership across teams before beginning. Both Upgrade classic dashboards and Upgrade metric alerting & maintenance windows share this stage as their prerequisite and can run in parallel, so coordinate team assignments early to avoid blocking either track.