Upgrade engagements often run into trouble not because of technical complexity, but because of misaligned expectations about what "done" looks like. These best practices give you a repeatable approach to scope the upgrade confidently so that all technical work proceeds against a shared, signed-off baseline.
Before scaling the upgrade across all teams and applications, run the full upgrade end-to-end with a single pilot team. Use the pilot to validate your approach, capture lessons learned, document the repeatable process, and refine any technical or organizational gaps. Once the approach is proven, use the resulting guidance and assets to scale the upgrade across additional teams.
When selecting the pilot team, look for the following characteristics:
Avoid piloting with teams that own critical ITSM integrations such as ServiceNow or PagerDuty. Defer those teams to a later wave.
Decide whether the upgrade targets a single team, a full environment, or multiple environments. Identify the applications and hosts included in the first wave, and document any dependencies between teams that affect sequencing.
For each team in scope, capture:
Get written sign-off on the out-of-scope list from the project sponsor before technical work begins. Stakeholders may add items mid-engagement without adjusting the timeline or effort, so a signed scope document is your primary protection against scope creep.
With scope defined, work with the team to identify every classic asset that needs to be upgraded. The goal is not just a count: it is a shared understanding of what exists, who owns it, and what it does. The Dynatrace Admin knows what is in the environment; the application team leads know what is actually used.
Populate one row per asset category in your scope document. The following table shows an example:
| Asset type | Count | Owner | Disposition |
|---|---|---|---|
Management zones | 2 | Platform team | Upgrade to IAM and segments |
Dashboards | 3 | Application team | Upgrade 1, retire 2 (no active users) |
Alerting profiles | 1 | Platform team | Upgrade |
Problem notifications (ServiceNow) | 1 | ITSM team | Defer (ServiceNow integration out of scope) |
Problem notifications (email) | 1 | Application team | Upgrade |
SLOs | 1 | Application team | Upgrade |
Synthetic monitors | 0 | — | Not applicable |
API tokens (v1) | 2 | Application team | Upgrade |
Maintenance windows | 1 | Platform team | Upgrade |
Use three dispositions for every asset in the inventory:
| Disposition | Meaning |
|---|---|
Upgrade | Rebuild as the Latest Dynatrace equivalent in this engagement |
Retire | No longer needed; confirm with the owner before deleting |
Defer | Not in scope for this engagement; assign an owner and a target date |
Document success criteria with the project sponsor before starting technical work. Agree on what a completed upgrade looks like, including the definition of done for enrichment coverage, segment validation, and decommissioned classic assets.
Get written sign-off on the scope document—including the out-of-scope list—before any technical work begins. Undiscovered dashboards, alerting rules, or integrations that surface after migration starts force re-scoping and timeline slippage.
Return to Scope your upgrade to Latest Dynatrace to continue your upgrade.