Measuring Role Mapping Quality Before Go-Live

Every migration project reaches a point where the team needs to answer a straightforward question: is the role mapping good enough to go live? In most projects, this question is answered through a combination of gut feeling, UAT pass rates, and stakeholder sign-off. These inputs are useful but incomplete. They don't provide a quantitative measure of the mapping's quality across the dimensions that matter for long-term access governance.

A more rigorous approach uses a set of measurable indicators that can be tracked throughout the mapping process and evaluated against defined thresholds before go-live.

Coverage Rate

The most fundamental quality metric is coverage: what percentage of users in scope have been mapped to at least one role in the target system? A coverage rate below 100% means some users will go live without defined access, which creates either a business disruption (they can't work) or a workaround risk (they get emergency access that bypasses the governance process).

Coverage should be measured at multiple levels. User-level coverage tells you how many individuals have at least one role assignment. Permission-level coverage tells you what percentage of each user's source-system permissions are accounted for by their target-system roles. A user might be "covered" at the user level but have significant permission gaps if their target roles don't include all the functions they need.

A healthy mapping typically achieves 95%+ user-level coverage and 85%+ permission-level coverage before go-live. The remaining gaps should be documented with a plan for resolution during stabilization.

SoD Compliance Rate

The SoD compliance rate measures what percentage of user-role assignments are free of segregation of duties conflicts. This metric should be calculated against the organization's approved SoD ruleset, including any rules that are specific to the target platform.

A realistic target is 90-95% SoD compliance at go-live. Achieving 100% is theoretically desirable but practically difficult in large environments. The remaining violations should have documented mitigation controls or approved exceptions, not just undocumented acceptance.

The compliance rate should be tracked over time, not just measured once before go-live. If the rate is declining as more users are mapped, the role design may have a structural problem that's producing conflicts at scale. If it's improving, the team is successfully resolving violations as they work through the population.

Right-Sizing Score

Over-provisioning is one of the most common quality problems in migration role mappings. A right-sizing score compares the permissions each user is receiving in the target system against what they actually used in the source system. If a user executed 15 transaction codes in the source system but their target roles grant access to 150, they're significantly over-provisioned.

This ratio provides a quantitative measure of access bloat. A score of 1.0 means the target permissions exactly match the source usage (unlikely in practice, since role boundaries rarely align perfectly with individual usage). A score of 3.0 means the user is receiving three times the access they demonstrated needing. Scores above 5.0 suggest the role design is granting broad access without sufficient granularity.

For a well-executed mapping, the median right-sizing score across the user population should be between 1.5 and 3.0. Scores in this range indicate that the target roles are somewhat broader than individual usage (which is expected and acceptable) but not dramatically over-provisioned.

Persona Utilization

For persona-based migrations, persona utilization measures how effectively the persona framework covers the user population. Key indicators include the number of users per persona (are some personas too narrow or too broad?), the percentage of users assigned to exactly one persona versus multiple personas, and the percentage of users who don't fit any defined persona and require custom role assignments.

A well-designed persona framework assigns 80%+ of users to a single persona. If a high percentage of users need multiple personas or custom assignments, the persona definitions may not accurately reflect the organization's actual work patterns.

Documentation Completeness

While less quantitative than the other metrics, documentation completeness is a practical quality indicator. For each mapping decision, can the team produce the rationale (why this role for this user), the evidence (what data supported the decision), and the approval (who signed off)?

A documentation audit of a random sample of 50-100 user mappings before go-live reveals whether the team's process is producing audit-ready records or leaving gaps. If more than 10% of sampled mappings lack adequate documentation, the process needs adjustment before the remaining population is finalized.

Using Metrics as Go/No-Go Criteria

These metrics are most useful when defined as explicit go-live criteria early in the project, not introduced as a last-minute quality gate. When the mapping team knows from the start that they need to achieve 95% coverage, 90% SoD compliance, a median right-sizing score below 3.0, and complete documentation for all assignments, they can manage their work toward those targets.

The metrics also provide objective data for the go/no-go conversation that happens before every migration cutover. Instead of debating whether the mapping "feels" ready, the team can present quantitative evidence of where it stands against defined criteria. If the metrics are met, the decision is straightforward. If they're not, the data shows exactly where the gaps are and how large they are, enabling an informed risk decision rather than an uninformed one.