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


{{< announcement >}}
**Permissions Management (RBAC) deprecation timeline**

The legacy [Permissions Management (RBAC) system]({{< ref "access-management/glossary.md#role-based-access-control-rbac" >}}) will be **deprecated on October 31, 2026**. RudderStack recommends completing your migration before this date.

- [Understand the pre-migration considerations]({{< ref "access-management/pre-migration-considerations.md" >}})
- [Start your migration now]({{< ref "access-management/migration-steps.md" >}})
- [Learn how the migration works]({{< ref "access-management/how-migration-works.md" >}})
{{< /announcement >}}

The examples in this guide show how migration works when a user has [resource-level permission restrictions]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) configured as a part of their role in the [legacy Permissions Management (RBAC) system]({{< ref "archive/dashboard-guides/user-management.md#role-permissions" >}}).

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

{{< info >}}
**Important: Service Access Tokens Migration**

The migration examples in this guide also apply to [Service Access Tokens]({{< ref "archive/dashboard-guides/service-access-tokens.md" >}}) with resource-level permission restrictions.
{{< /info >}}

## Connections Admin role

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

### Scenario {#scenario-admin}

A user with a [Member]({{< ref "archive/dashboard-guides/user-management.md#organization-roles" >}}) 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

{{< image src="images/access-management/migration/connections-admin-pre-migration-permissions.webp" >}}

In addition, the user **does not** have permissions to edit or make changes to **3 sources** (configurable via the [Permissions]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) tab in the source page):

{{< image src="images/access-management/migration/source-permissions.webp" alt="Source permissions configuration showing restricted access" >}}

### Migration result {#migration-result-admin}

{{< info >}}
This example assumes **no changes were made** to the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) or the individual's [Member Workspace Policy]({{< ref "access-management/members.md" >}}) in [staging]({{< ref "access-management/migration-steps.md#step-2-configure-policies" >}}).
{{< /info >}}

After migration, the user's individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}) in the new Access Management system will look as follows:

{{< image src="images/access-management/migration/connections-admin-resources-post-migration-restricted.webp" >}}

{{< image src="images/access-management/migration/connections-admin-resources-post-migration.webp" >}}

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.

{{< info >}}
This is in contrast to the [previous example]({{< ref "access-management/migration-examples/no-resource-level-restrictions.md#connections-admin-role" >}}), where the member had edit permissions for all sources.
{{< /info >}}

## Connections Editor role

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

### Scenario {#scenario-editor}

A user with a [Member]({{< ref "archive/dashboard-guides/user-management.md#organization-roles" >}}) 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

{{< image src="images/access-management/migration/connections-editor-pre-migration-permissions.webp" >}}

In addition, the user **does not** have permissions to edit or make changes to **3 sources** (configurable via the [Permissions]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) tab in the source page):

{{< image src="images/access-management/migration/source-permissions.webp" alt="Source permissions configuration showing restricted access" >}}

### Migration result {#migration-result-editor}

{{< info >}}
This example assumes **no changes were made** to the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) or the individual's [Member Workspace Policy]({{< ref "access-management/members.md" >}}) in [staging]({{< ref "access-management/migration-steps.md#step-2-configure-policies" >}}).
{{< /info >}}

After migration, the user's individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}) in the new Access Management system will look as follows:

{{< image src="images/access-management/migration/connections-editor-resources-post-migration-restricted.webp" >}}

{{< image src="images/access-management/migration/connections-editor-pii-post-migration.webp" alt="Migration example showing new permissions model for PII" >}}

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]({{< ref "access-management/migration-examples/no-resource-level-restrictions.md#connections-viewer-role" >}}).