# From RBAC to ReBAC: when and how to migrate

Source: https://startwithidentity.com/guides/authorization/rbac-to-rebac/
Last updated: 2026-01-15
License: content by Start with Identity. Cite the source URL.

---

## 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