dt-upgrade

Assess and migrate Dynatrace tenants from classic 2nd-gen features to 3rd-gen platform equivalents.

Updated Dec 12, 2025
One-click install
npx skills add https://github.com/ricardojjulia/ESACompanion --skill dt-upgrade-ricardojjulia
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dt-upgrade
Source: https://github.com/ricardojjulia/ESACompanion/tree/main/.github/skills/dt-upgrade
Command: npx skills add https://github.com/ricardojjulia/ESACompanion --skill dt-upgrade-ricardojjulia

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Upgrading a Dynatrace tenant from classic (2nd-generation) to 3rd-generation concepts requires auditing dozens of feature areas, running readiness queries, and remediating dashboards, alerts, SLOs, and cloud connections before Phase 3 removes classic functionality. This Skill guides that assessment and migration end to end. ## Core Features & Use Cases - Readiness Assessment: Runs DQL tracking queries and Settings API scans to inventory classic usage, classic configurations, readiness status, and gen3 adoption across Platform, Edge Data Platform, Application Observability, Infrastructure Observability, Cloud Automations, Application Security, and Digital Experience areas. - Cloud Connection Migration: Covers full AWS, Azure, and GCP migration from classic connections to Smartscape on Grail, including connection discovery, dependency scanning of dashboards/alerts/SLOs, metric and entity key mapping, and zero-gap cutover. - Migration Guidance: Maps each classic concept (management zones, metric events, USQL, classic SLOs, K8s monitoring, RUM, synthetic) to its gen3 replacement with customer actions, tracking queries, and documentation links. - Use Case: A platform engineer asks which classic AWS dashboards and metric event alerts will break at cutover; the Skill scans settings schemas and dashboards, reports affected assets with classic metric keys, and provides the new metric key equivalents. ## Quick Start Ask the assistant to assess my Dynatrace tenant's upgrade readiness across all areas and list the classic features still in use.

Frequently Asked Questions about dt-upgrade

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I assess Dynatrace upgrade readiness from classic to gen3?▼

Run the Skill's tracking queries per upgrade area to inventory classic usage, classic configurations, readiness status, and gen3 adoption. Results show which classic features are active, what needs migration, and the recommended customer actions before Phase 3.

How to migrate classic AWS connections to Smartscape on Grail?▼

Discover classic connections via dt.entity.aws_credentials, scan dashboards, metric events, anomaly detectors, and SLOs for classic metric prefixes like dt.cloud.aws.*, map keys to new cloud.aws.* equivalents, then cut over with a zero-gap strategy of parallel old and new alerting.

What replaces classic Dynatrace metric event alerts in gen3?▼

Classic metric events (builtin:anomaly-detection.metric-events) are replaced by DQL-based anomaly detectors (builtin:davis.anomaly-detectors), and problem notifications move to Workflows. Management Zone migration must complete first since Workflow trigger filters replace MZ-based scoping.

Does the Dynatrace upgrade affect classic dashboards and USQL queries?▼

Yes. Dashboards Classic, Data Explorer, and USQL session queries are replaced by gen3 Dashboards, Notebooks, and DQL. The Skill provides tracking queries to find classic dashboard usage and USQL adoption so they can be rebuilt before Phase 3.

What is the difference between Dynatrace Phase 2 and Phase 3?▼

Phase 2 is dual mode where classic and gen3 features coexist, giving customers time to migrate configurations and adopt gen3 apps. Phase 3 removes classic features entirely, so all configurations must be migrated beforehand.

Why can't classic dashboards be scanned during cloud migration assessment?▼

Classic dashboards use the Config API v1 and are not accessible via dtctl get dashboards. Scanning them requires a separate DT_API_TOKEN with ReadConfig scope; without it, they must be reviewed manually.