Pre-migration Considerations
Understand what to expect before migrating to the new Access Management system.
Self-serve migration availability
The self-serve migration feature for users on the legacy RBAC system is currently gated and will be generally available on March 16, 2026.
Contact RudderStack Support if you’d like to enable it for your organization in the meantime.
Before you begin migration to the new Access Management system, it is important to understand how your current permissions will map to the new system and what changes to expect. This will help you make informed decisions during the migration process, particularly when choosing your import strategy.
Migration scope
Migration to the new Access Management system happens at the organization level, not at the workspace level. This means:
- When you migrate, the migration applies to all workspaces within your organization
- You cannot migrate individual workspaces separately
- All members and Service Access Tokens in all workspaces in your organization are migrated to the new Access Management system together
If your organization has multiple workspaces, make sure to check and fine-tune each workspace’s
baseline policy before deploying the new Access Management system.
Roles to member permissions
After migration, the permissions a user had in the legacy Permissions Management (RBAC) system (Viewer, Connections Editor, Connections Admin, etc.) will be mapped to their individual Member Workspace Policy.
This means that instead of assigning specific roles to members, each member will have their previous permissions preserved as a customized workspace policy applicable for them.
This approach gives Admins more granular control over individual member permissions while maintaining the same access levels they had before.
Baseline Workspace Policy
New members added to a workspace after migration will inherit its Baseline Workspace Policy by default.
This behavior is different from the legacy RBAC system where new members inherited permissions based on their assigned role.
After migration, you will need to explicitly configure the Baseline Workspace Policy to grant the default permissions you want new members to have when they join your workspace.
Also, note that unless configured by Admins, the baseline workspace policy contains view-only permissions for all resources with restricted access to PII.
Granular resource-level permissions
Admins will be able to grant Edit, Connect, and Create & Delete permissions independently on specific resources.
This provides more flexibility than the legacy RBAC system, where permissions were bundled into roles. You can now configure permissions at a more granular level, allowing you to grant specific actions on specific resources without giving broader access.
Import strategy decision
During migration, you will need to choose an import strategy that determines how your existing permissions are translated into the new system:
| Strategy | Implications | Ideal if |
|---|
| Start fresh | RudderStack imports members with baseline, view-only permissions. | You want to start with a blank slate and build permissions policies from the ground up. |
| Use existing policies | RudderStack imports members with their existing permissions. Current user roles will be mirrored into the individual user’s Member Workspace Policy. | You want to retain the existing user permissions as is, without having to modify them later. |
Service Access Tokens will be automatically imported with their current permissions in both import strategies.
Migration process
See the Migration Guide for step-by-step instructions on performing the migration.
See more
Questions? We're here to help.
Join the RudderStack Slack community or email us for support
