# Migration Example: Users and Tokens with No 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 **does not have** any [resource-level permissions]({{< 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" >}}). {{< 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" >}}) created in the [legacy RBAC system]({{< ref "archive/dashboard-guides/service-access-tokens.md#generate-service-access-token" >}}). For example, if a Service Access Token is created with the **Connections Admin** role, it will be migrated with the same permissions as a member with the **Connections Admin** role. {{< /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" >}} ### 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.webp" >}} {{< image src="images/access-management/migration/connections-admin-pii-post-migration.webp" >}} The member's permissions are preserved, with **full access** to all resources and PII views, maintaining the same access level they had before migration. ## 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" >}} ### 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.webp" alt="Migration example showing new permissions model for resources" >}} {{< 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 - **Cannot** create or delete resources - **Cannot** edit, connect, or create/delete transformations and transformation libraries ## Connections Viewer role The example in this section covers a migration scenario for members with the **Connections Viewer** role. ### Scenario {#scenario-viewer} 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 Viewer** role with read-only permissions to view resources (sources, destinations, transformations, Tracking Plans, etc.) - **No edit access** to create, edit, delete, or connect resources (sources, destinations, transformations, Tracking Plans, etc.) {{< image src="images/access-management/migration/connections-viewer-pre-migration-permissions.webp" >}} ### Migration result {#migration-result-viewer} {{< 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-viewer-resources-post-migration.webp" alt="Migration example showing new permissions model for resources" >}} {{< image src="images/access-management/migration/connections-viewer-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 view all resources but **cannot** edit, create, delete, or connect them.