Hi,
Yes, I think this is the key question, because this is usually where the difference comes from.
IMO the issue is that Classic Management Zones and the new Segments are not a 1:1 mapping, so the same problem counts will not always match after migration. Dynatrace even has a dedicated upgrade guide from MZ to Segments, which suggests adapting the use case rather than just copying the old filter logic.
Then your DQL:
fetch dt.davis.problems.snapshots
| filter dt.davis.is_duplicate == false
| dedup display_id
This can produce different numbers than Classic, because dt.davis.problems.snapshots works on problem snapshots over time, not simply on the list of unique problems. In the current Dynatrace documentation, the recommended dataset for unique problem queries is rather fetch dt.davis.problems, for example with not(dt.davis.is_duplicate), and for active problems additionally event.status == "ACTIVE".
So I would first test something like:
fetch dt.davis.problems
| filter not(dt.davis.is_duplicate)
| summarize problem_count = count()
or only open one:
fetch dt.davis.problems
| filter not(dt.davis.is_duplicate)
| filter event.status == "ACTIVE"
| summarize problem_count = count()
Also, with Segments it is very important to understand which entities are impacted by those problems. If the problems are tied to hosts, services, process groups, or other entity/data types, the segment needs to include the correct scope. Otherwise, the count shown in Dashboards/DQL may differ from what Classic MZ-based views displayed before. Dynatrace’s segment documentation also highlights that results depend on the correct data scope being included.
Documentation here:
Analyze monitoring data with segments
