Upgrade from Classic maintenance windows to Latest maintenance windows
- Latest Dynatrace
- Upgrade guide
- 5-min read
- Published Sep 09, 2026
Dynatrace Classic and Latest Dynatrace both support maintenance windows, but their underlying models differ. Latest Dynatrace scopes windows with DQL matcher expressions on Grail data instead of management zones, and suppresses notifications through a workflow Problem trigger filter instead of built-in detection modes. Classic maintenance windows are not migrated automatically, so use this guide to recreate them in Latest Dynatrace.
Why upgrade?
The Latest Dynatrace platform gives you several improvements:
- Query maintenance history using DQL to audit past windows or correlate them with metric anomalies.
- Scope maintenance windows with the same DQL matcher syntax you already use in
Dashboards, 
Notebooks, and 
Workflows. - Filter directly on maintenance state from workflows and DQL queries, without extra lookups.
- Cover complex schedules with fewer maintenance windows using extended scheduling rule options.
What is new?
Latest Dynatrace introduces the following changes to maintenance windows:
Latest Dynatrace supports up to 100 upcoming maintenance window configurations. Grail stores historical windows, which do not count against the limit.
- Configure maintenance windows under Settings > General > Maintenance windows, or via the Settings API (schema
builtin:maintenance-windows). - Window scope uses DQL matcher filter criteria on Grail primary fields and tags. Grail stores maintenance state as start and end events and as enrichments on affected telemetry, giving you both current and historical context. Dynatrace always detects problems. A workflow Problem trigger filter handles notification suppression during a maintenance window. Schedule maintenance windows for a future date or a recurring future pattern. Retroactive maintenance windows are not supported.
What will you do?
You need to recreate Classic maintenance windows manually in Latest Dynatrace. Classic maintenance windows aren't migrated automatically. You'll export your Classic configurations, translate the management zone and entity ID scope into DQL matcher expressions, and verify that notification suppression works in the Problem trigger of the workflow.
Before you begin
Review the following breaking changes before you start your migration.
Breaking changes
Latest Dynatrace supports up to 100 upcoming maintenance window configurations, compared to two thousand in Dynatrace Classic. If you currently use more than 100 active or upcoming maintenance windows, you need to consolidate them before migrating.
To reduce the number of windows, use the Configuration API to export the full list, identify redundant or overlapping windows, and merge them where possible. Latest Dynatrace has more expressive scheduling rules, so a single maintenance window can often replace several Classic maintenance windows.
How to upgrade Classic maintenance windows
Step 1: Recreate your maintenance windows
To recreate your maintenance windows in Latest Dynatrace:
-
Export your existing configurations. Use the Configuration API to list all maintenance windows and identify which ones are still relevant.
-
Create a maintenance window in Latest Dynatrace.
-
Translate the scope from management zones and entity IDs to DQL matcher filter criteria on Grail primary fields.
Step 2: Verify notification suppression
-
Go to
Workflows. -
Open your workflow.
-
In the Problem trigger of your workflow, add
maintenance.is_under_maintenance == falseas a filter to exclude problems that occur during a maintenance window.
For more information, see How can I prevent sending notifications during a maintenance window?.
For full reference on maintenance windows in Latest Dynatrace, see Maintenance windows.
FAQ
How can I prevent sending notifications during a maintenance window?
In the Problem trigger of your workflow, use maintenance.is_under_maintenance == false as a filter query to only trigger the workflow when the problem didn't occur during a maintenance window.
What replaces the classic problem detection modes?
Classic maintenance windows offered three problem detection modes: detect and send alert, detect but suppress alerts, and disable problem detection entirely.
Latest Dynatrace always detects problems.
To suppress notifications during a maintenance window, add maintenance.is_under_maintenance == false as a filter in your workflow Problem trigger. There is no equivalent to disabling problem detection entirely.
Davis AI continues to detect problems, but you control whether they trigger notifications via workflows.
Can I create a maintenance window retroactively?
No. In Latest Dynatrace, you must schedule maintenance windows for a future date or a recurring future pattern. Creating windows for a past date is no longer supported.
In Dynatrace Classic, you could use retroactive maintenance windows to correct availability metrics after an unplanned outage. In Latest Dynatrace, Grail records maintenance start and end events when the window runs, so a window you create now cannot reclassify past downtime. If your availability reporting relies on retroactive maintenance windows, plan for that gap as part of your upgrade.