From RBAC to ReBAC: when and how to migrate

Why teams migrate

RBAC is great until your customers need to share individual resources, not entire roles. The moment you find yourself adding a 50th role named like editor_for_project_xyz, you've outgrown RBAC. Document-level, record-level, and resource-level access call for ReBAC.

Recognize the signs

• Role explosion: more roles than active users
• Sharing patterns: "share this with Bob but not Alice" can't be modeled
• Inheritance gone wrong: nested folders, organization hierarchies, team trees
• Multi-tenant SaaS where tenants have their own access patterns

What to migrate to

The dominant pattern is Google Zanzibar-style ReBAC. Implementations:

• OpenFGA / Auth0 FGA: Cloud and self-hosted. Open-source spec.
• Authzed SpiceDB: Commercial-grade Zanzibar implementation.
• Permify: Open-source, simpler to operate.
• Oso: A different model (Polar policy language); evaluate as a peer option.

The migration

1. Model first. Write the schema in your chosen tool. Don't migrate code yet — get the model right.
2. Dual-write. Existing RBAC checks continue. Mirror writes to ReBAC.
3. Shadow reads. Compare ReBAC decisions to RBAC decisions in production logs. Alert on divergence.
4. Cutover by call site. One endpoint at a time. Roll back is trivial.
5. Decommission RBAC. Only after weeks of shadow agreement.

Common pitfalls

• Treating ReBAC as a code library instead of a system of record
• Not designing for "negative permissions" (deny rules) early — they're hard to add later
• Failing to budget for latency — every request now hits the authz service
• Cache invalidation: relationship changes must propagate or stale auth decisions leak