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.
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:
app = easytradeapp = hipstershopUsers 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.
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 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:
primary_tags.app = easytrade; this covers all environments for easytradeprimary_tags.app = hipstershop; this covers all environments for hipstershopprimary_tags.stage = production; this covers all applications in productionprimary_tags.stage = development; this covers all applications in developmentUsers 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.
Before decommissioning classic management zones, verify that enrichment coverage is high enough for segments to provide equivalent data scope.
To track enrichment coverage
primary_tags.app—and validate against it before proceeding.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.
Return to Upgrade management zones to IAM & segments to continue your upgrade.