Moving off Oso Cloud? Sort your Polar rules into three piles first

Oso Cloud was acquired by Tiny, and the deal closed on October 1. Oso says Cloud keeps running as usual, and most of the team has joined Temporal. If production authorization runs through it, it is reasonable to want a migration plan on paper before you actually need one. This is the order I would work in.

Sort your Polar into three piles

Most policies mix three patterns, and each one moves differently.

• Role blocks, like "read" if "viewer"; inside a resource block. That is plain RBAC, and it maps to roles and permissions in almost any system.
• Roles derived through relations, like "reader" if "member" on "organization";. That is ReBAC. Whatever you move to needs relationship tuples and role derivation, so a simple roles table will not cover it.
• Attribute rules, like allow(user: User, "view", doc: Document) if user.clearance_level >= doc.classification;. These become conditions in Rego, Cedar or whatever you pick, and the attributes have to be available when the check runs.

Count what lands in each pile. A codebase that is mostly role blocks moves quickly. One built on nested relations needs real modeling time first.

Get your facts out

The rules are only half of it. Every has_role and has_relation fact you have sent to Oso Cloud is data your app depends on. Find every place your code writes facts and make sure you can rebuild all of them from your own database. If you cannot, fix that before anything else, because it is the hardest piece to reconstruct later.

Find your list queries

Single checks like authorize(user, "read", doc) port easily. "Show me every document this user can read" is harder. Look for every list call and every spot where you use local authorization to filter in SQL, then confirm the new system can answer the same question at your data size.

Run both side by side

Before you cut over, call the new engine next to Oso on real traffic. Keep enforcing Oso's answer and log every disagreement. The mismatches usually point straight at a derived role or an attribute you mapped wrong.

I work at Permit, so I am biased about where you end up. We wrote up how each of these Polar patterns maps to Permit, with code for each: https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration&utm_content=gabriel-post