Migration strategy for permanent role-based assignments in Azure for resources in a subscription:

This article describes a logical end state that becomes possible after an initial review, cleanup and optimization and justifies it to stakeholders who often want to contend that delivery requirements can be met by cleanup and optimization alone. The state is realized through an entitlement model that separates business access decisions from Azure implementation details, which allows the access model to survive platform, application, and organizational change over many years.

First, we must acknowledge that there are near-term economics in doing just cleanup without imposing any model or organization. Converting existing permanent assignments into eligible PIM assignments, consolidating resource-level role assignments to resource-group scope, and reducing the number of direct RBAC assignments is probably the fastest path to risk reduction. It produces measurable audit benefits quickly, requires relatively little redesign, minimizes disruption to application teams, and largely preserves today's operational model. This is an infrastructure optimization exercise. It makes today's model cleaner without fundamentally changing how access is governed.

Second, we are solving a problem we typically uncover in the analysis that this is a dual problem of RBAC-assignment and identity-governance. Same combinations of Azure roles repeat across users over and over again but often manifest through many different groups and custom-role variations. While we can reduce those patterns into a relatively small number of reusable job-function personas and highlight where custom roles represent specialized business functions rather than merely technical permissions. The fact that the same role combinations repeatedly emerge is evidence that people naturally organize around business responsibilities such as application development, application operations, platform engineering, storage administration, integration engineering, and data engineering, not around individual Azure resources. The entitlement catalog therefore models the way work is performed rather than the way Azure resources happen to be arranged today. The entitlement model separates "what job a person performs" from "where resources happen to live." In effect, the model transforms access management from a collection of infrastructure-specific permissions into a business-driven authorization framework that can evolve independently of resource groups, subscriptions, applications, and cloud platforms

Third, resource groups are not stable business constructs. They are deployment constructs. Applications move between subscriptions, environments are restructured, landing zones evolve, new resource types are introduced, acquisitions occur, and cloud architectures change. A resource-group-centric model assumes that the resource-group boundary is the most important long-term boundary. History shows that those boundaries change frequently. Job functions, however, change much more slowly. There will almost certainly still be application developers, platform engineers, storage administrators, and integration engineers five years from now, even if the names of the subscriptions, resource groups, AKS clusters, Key Vaults, Databricks workspaces, Event Hubs namespaces, or storage accounts have changed entirely. Because personas are aligned with enduring business responsibilities, they are inherently more resilient than resource-centric RBAC designs.

Fourth, custom roles are where the resource-group approach becomes increasingly difficult to maintain. While we can create custom roles that span multiple resource types within a resource group, that. works successfully only when there are a small number of applications and a small number of resource patterns. Eventually, however, they proliferate and differ only slightly from one another. At that point nobody can confidently answer simple questions such as "What does a Data Engineer receive?" or "Why does this application team need this custom role?" The entitlement model addresses this by making roles implementation details and personas the primary unit of governance. A manager approves "Data Engineer" or "Platform Engineer." The underlying RBAC bundle can evolve without repeatedly re-educating reviewers and makes subsequent access reviews more transparent and easier to complete for managers.

Fifth, the entitlement model scales much better for certification, audit, and compliance activities. Resource-group-based reviews require reviewers to evaluate technical assignments and with full purview of current landscape and historical context: Contributor on resource group A, Key Vault role on resource group B, Event Hubs role on resource group C, and so forth. A persona model allows reviewers to answer a far simpler question: "Does this person still perform the duties of a Platform Engineer?" Most auditors, application owners, and managers can answer that question confidently; far fewer can evaluate dozens of Azure RBAC assignments in context. The result is better access reviews and lower risk of rubber-stamp approvals.

Sixth, the entitlement model future-proofs hybrid and multi-platform environments. Today's discussion centers on Azure RBAC, but tomorrow there may be a need to govern Azure, Databricks, Snowflake, GitHub, ServiceNow, Kubernetes, SaaS platforms, and on-premises systems together. Resource-group-driven governance does not extend naturally beyond Azure. Personas do. A "Data Engineer" entitlement can someday include Azure roles, Databricks workspace permissions, GitHub repository access, and Snowflake roles. That makes the model extensible in directions that are probably impossible to predict today.

Seventh, initial reviews often find that users cannot cleanly fit into a reusable entitlement and therefore require exceptions or that users wear multiple hats and can change them. In other words, the model does not merely assign people to personas; it reveals complexity that currently exists but is hidden behind groups and custom roles. That transparency is valuable because exceptions become specific, measurable, and reviewable instead of remaining embedded inside opaque group memberships and custom role definitions.

Eighth, this model is not an all-or-nothing proposal. Immediate and interim exercise and the entitlement strategy are complementary. First consolidate RBAC to resource-group scope, remove unnecessary direct assignments, and convert elevated permissions to PIM eligibility. Once that cleanup is complete, the entitlement catalog becomes the governance layer above it. In that model, resource groups remain the technical enforcement boundary while personas become the business-access boundary. Engineers implement RBAC. Managers approve personas. Identity governance teams maintain mappings between the two. Each layer serves its appropriate purpose.

A cleanup approach optimizes the current state, while the entitlement approach creates a durable operating model. One reduces administrative effort today. The other reduces administrative effort every year thereafter. If the organization expects the application portfolio, cloud footprint, custom roles, and hybrid platforms to continue growing, then investing in personas is not a fad. It is the architectural layer that prevents access management from becoming increasingly tied to the accidental structure of today's Azure environment. The reason to adopt personas is that they are the only abstraction in the model that represents stable business responsibilities rather than transient cloud infrastructure.