Try it free

Best practices for upgrading management zones to segments

  • Latest Dynatrace
  • Best practices
  • Published Aug 24, 2026

Classic management zones combined multiple data dimensions into a single static grouping. Segments replace them with a dimension-based model that is dynamic, scales without multiplication, and integrates with IAM access control. There is no 1:1 mapping from management zones to segments; understanding why not is key to a successful migration. These best practices help you decompose existing management zones into well-designed segments.

Decompose management zone compound names into separate dimensions

Classic management zones typically encoded multiple dimensions into a single name. For example, a team might have created separate management zones for each application-environment combination:

  • easytrade_prod (application: easytrade, stage: production)
  • easytrade_dev (application: easytrade, stage: development)
  • hipstershop_prod (application: hipstershop, stage: production)
  • hipstershop_dev (application: hipstershop, stage: development)

This approach works but scales poorly. Adding a new environment (for example, qa) or a new application multiplies the number of management zones, and permissions become hardcoded into names.

Segments use dimensions (attributes) and their values. Instead of four management zones, you create two dimensions:

  • Segment for app = easytrade
  • Segment for app = hipstershop

Users can then combine segments dynamically—for example, filter by app = easytrade AND stage = production—without requiring a pre-created management zone for each combination.

Decompose each management zone name into its constituent dimensions before designing segments.

Enrich telemetry before creating segments

Segments filter data based on enrichment fields. If the required enrichment fields are not present on signals, segments do not return data and appear empty.

Before creating segments, confirm that all monitored signals carry the enrichment attributes you plan to use as dimensions. For example, if you want a segment that filters by primary_tags.app = easytrade, every span, log, metric, and event related to the easytrade application must carry primary_tags.app.

Complete the metadata enrichment and post-ingest enrichment stages before starting segment configuration.

Segments created before enrichment is complete will appear to work but return incomplete data. Teams validating against incomplete data may report false confidence in access control. Always validate segment completeness against a known full data set.

Create segments per dimension, not per management zone

Create one segment per dimension, not one segment per management zone. This is the most important structural difference between classic management zones and segments.

For the example above:

  • Create a segment for primary_tags.app = easytrade; this covers all environments for easytrade
  • Create a segment for primary_tags.app = hipstershop; this covers all environments for hipstershop
  • Create a segment for primary_tags.stage = production; this covers all applications in production
  • Create a segment for primary_tags.stage = development; this covers all applications in development

Users and dashboards combine these segments to get the scoped view they need. This approach means you never need to create a new segment when you add a new application or environment; you just add the enrichment to the new signals.

Configure each segment to include classic compatibility for dashboards and alerts that still reference management zone filtering, until those are fully upgraded.

Track enrichment coverage before cutover

Before decommissioning classic management zones, verify that enrichment coverage is high enough for segments to provide equivalent data scope.

To track enrichment coverage

  1. Use the Enrichment Coverage notebook to measure what percentage of each signal type carries the required enrichment fields.
  2. Set a coverage threshold—for example, 95% of all signals must carry primary_tags.app—and validate against it before proceeding.
  3. Identify the source of any gaps: hosts without host group configured, Kubernetes workloads missing namespace labels, or cloud resources not connected to the latest cloud connection.
  4. Resolve gaps and re-validate before removing management zones.

Track enrichment coverage per dimension across the environment. An application team may report good coverage for their own signals but miss coverage gaps in shared platform infrastructure that affects their segments.

Ready for more?

Return to Upgrade management zones to IAM & segments to continue your upgrade.

Related tags
Dynatrace Platform