Migration Example: Users and Tokens with Resource-level Permission Restrictions

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.

The examples in this guide show how migration works when a user has resource-level permission restrictions configured as a part of their role in the legacy Permissions Management (RBAC) system.

These examples demonstrate how RudderStack preserves granular resource-level permissions during migration, maintaining the same restricted access the member had before.

Important: Service Access Tokens Migration

The migration examples in this guide also apply to Service Access Tokens with resource-level permission restrictions.

Connections Admin role

The example in this section covers a migration scenario for members with the Connections Admin role.

Scenario

A user with a Member role has the following access policy in the legacy RBAC system:

• Connections Admin role with permissions to create, edit, connect, and disconnect resources (sources, destinations, transformations, Tracking Plans, etc.)
• Full edit access to create, edit, and delete transformations and transformation libraries

In addition, the user does not have permissions to edit or make changes to 3 sources (configurable via the Permissions tab in the source page):

Migration result

This example assumes no changes were made to the Baseline Workspace Policy or the individual’s Member Workspace Policy in staging.

After migration, the user’s individual Member Workspace Policy in the new Access Management system will look as follows:

The member’s permissions are preserved, with full access to all resources and PII views, except for 3 sources where they no longer have edit permissions.

This is in contrast to the previous example, where the member had edit permissions for all sources.

Connections Editor role

The example in this section covers a migration scenario for members with the Connections Editor role.

Scenario

A user with a Member role has the following access policy in the legacy RBAC system:

• Connections Editor role with permissions to edit, connect, and disconnect resources (sources, destinations, transformations, Tracking Plans, etc.)
• No edit access to create, edit, and delete transformations and transformation libraries

In addition, the user does not have permissions to edit or make changes to 3 sources (configurable via the Permissions tab in the source page):

Migration result

This example assumes no changes were made to the Baseline Workspace Policy or the individual’s Member Workspace Policy in staging.

After migration, the user’s individual Member Workspace Policy in the new Access Management system will look as follows:

The member’s permissions are preserved during migration so that they:

• Can edit and connect resources except the 3 sources where they no longer have edit permissions
• Cannot create or delete resources
• Cannot edit, connect, or create/delete transformations and transformation libraries

Connections Viewer role

The Connections Viewer role is a read-only role and does not have Edit permissions by default. Hence, resource-level permission restrictions do not apply to them.

Their permissions will be migrated as explained in the No Resource-level Restrictions example.