# How Migration to New Access Management System Works


{{< 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" >}})
{{< /announcement >}}

This guide explains how RudderStack transitions the members, [Service Access Tokens]({{< ref "access-management/service-access-tokens.md" >}}), and [Personal Access Tokens]({{< ref "access-management/personal-access-tokens.md" >}}) within your workspace to the new [Access Management system]({{< ref "access-management/overview.md" >}}) once you [migrate to it]({{< ref "access-management/migration-steps.md" >}}).

## Migration overview

During migration, RudderStack considers your [import strategy]({{< ref "access-management/pre-migration-considerations.md#import-strategy-decision" >}}) and maps permissions accordingly.

- If you choose **Import members**, RudderStack imports all members to the new Access Management system with baseline, view-only permissions instead of their existing permissions.
- If you choose **Import members with policies**, RudderStack imports all members to the new Access Management system with their existing permissions, ensuring each member's [effective access policy]({{< ref "access-management/concepts.md#access-policy" >}}) has the same permissions as before.
- Data Privacy (PII) permissions also follow this strategy: **Import members** does not preserve legacy member PII access, while **Import members with policies** preserves existing PII permissions and their resource-level scopes.

Service Access Tokens are migrated with their existing permissions, while Personal Access Tokens continue to inherit permissions from their associated users.

## Members

When you migrate members using the **Import members with policies** [import strategy]({{< ref "access-management/pre-migration-considerations.md#import-strategy-decision" >}}), RudderStack performs the following assessment:

- **Analyzes current permissions**: RudderStack reviews each user's assigned roles and permissions in the legacy Permissions Management (RBAC) system — this includes their [role-level]({{< ref "archive/dashboard-guides/user-management.md#resource-roles" >}}) and [resource-level]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) permissions.
- **Maps roles to policies**: The permissions a user had in the legacy RBAC system are mapped to their individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}).

For example, if a user had the **Connections Admin** role with permissions to create, edit, connect, and disconnect resources, these permissions will be preserved in their [Member Workspace Policy]({{< ref "access-management/members.md" >}}) after migration.

### Role mapping reference

The table below shows how roles in the legacy RBAC system map to the new Access Management system:

| Legacy RBAC role | New Access Management equivalent | Notes |
| :----------------- | :------------------------------- | :---- |
| **Admin** | Organization Admin + Full workspace permissions | Admins retain full control. Organization-level Admin role is separate from workspace permissions. |
| **Read-Write** | Member Workspace Policy with Edit, Connect, Create & Delete permissions | Configure via [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) or individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}). |
| **Read-Only** | Member Workspace Policy with View-only permissions | Default for new members. Can be set via [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}). |
| **Custom roles** | [Group Policies]({{< ref "access-management/groups.md" >}}) | Create groups (Data Engineers, Marketers, etc.) with specific permission sets. |

{{< info >}}
When you choose the **Use existing policies** [import strategy]({{< ref "access-management/pre-migration-considerations.md#import-strategy-decision" >}}), RudderStack automatically maps your current roles to individual Member Workspace Policies. You can then organize members into Groups for easier management.
{{< /info >}}

## Service Access Tokens

Service Access Tokens created in the [legacy RBAC system]({{< ref "archive/dashboard-guides/service-access-tokens.md#generate-service-access-token" >}}) are automatically imported during migration and follow the same migration patterns as members.

During migration, RudderStack:

- **Analyzes Service Access Token permissions**: RudderStack reviews each Service Access Token's assigned roles and permissions in the legacy RBAC system — this includes their [role-level]({{< ref "archive/dashboard-guides/user-management.md#resource-roles" >}}) and [resource-level]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) permissions.
- **Maps roles to workspace policies**: The token's permissions in the legacy RBAC system are mapped to its workspace-level access policy in the new Access Management system.

For example, if a Service Access Token had the **Connections Admin** role with permissions to create, edit, connect, and disconnect resources, these permissions will be preserved in its workspace policy after migration. 

See the [Migration Scenarios]({{< ref "access-management/migration-examples/" >}}) guide for more information on how Service Access Tokens are migrated.

## Personal Access Tokens

{{< info >}}
[Personal Access Tokens]({{< ref "access-management/personal-access-tokens.md" >}}) are tied to individual users — they inherit permissions of the user who created them.
{{< /info >}}

After migration, Personal Access Tokens:

- **Inherit user permissions**: Personal Access Tokens continue to inherit the permissions of the user who created them. Since user permissions are migrated to their [Member Workspace Policy]({{< ref "access-management/members.md" >}}), Personal Access Tokens automatically reflect those permissions.
- **Maintain scope behavior**: Personal Access Tokens created with **Read-Only** or **Read-Write** scopes continue to work as before, with their effective permissions determined by the user's [Individual Workspace Policy]({{< ref "access-management/members.md" >}}).

See the [Migration Scenarios]({{< ref "access-management/migration-examples/personal-access-tokens.md" >}}) guide for detailed examples of how Personal Access Tokens are migrated.

Note the following:

- To change a Personal Access Token's permissions after migration, you will have to either:

  - Modify the user's [Member Workspace Policy]({{< ref "access-management/members.md" >}}) 
  - Create a new Personal Access Token with the desired scope
- **You cannot create new Personal Access Tokens with Admin scope**. However, any existing Personal Access Tokens with Admin scope will continue to work as before, even after migration.

{{< tip >}}
Use Personal Access Tokens only for development, testing, and personal use cases.
{{< /tip >}}

## Resource-level permissions

{{< info >}}
**What are resource-level permissions?**

[Resource-level permissions]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) allow Admins to restrict editing particular resources to specific users or Service Access Tokens. Admins can configure an allowlist of members and tokens who can edit a resource.
{{< /info >}}

During the assessment, RudderStack considers whether [resource-level permissions]({{< ref "archive/dashboard-guides/permissions-management.md#restricting-edit-permissions-for-individual-objects" >}}) are configured for users and Service Access Tokens in the workspace.

If resource-level permissions are configured, RudderStack automatically configures the user's individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}) and the Service Access Token's [workspace policy]({{< ref "access-management/concepts.md#workspace-policy" >}}) to have the same permissions as before during migration.

For example, if a user had edit permissions for only 10 out of the 100 sources in the workspace, their [Member Workspace Policy]({{< ref "access-management/members.md" >}}) will reflect [**Edit** permission]({{< ref "access-management/policies-overview.md#edit-connect-and-create--delete-permissions" >}}) only for those 10 sources after migration.

See the [Migration Scenarios]({{< ref "access-management/migration-examples/" >}}) guide for more information on how migration works in different scenarios.

## Data Privacy permissions

During import, workspace Data Privacy permissions are handled using the same strategy as other member permissions:

- With **Import members** (**Start fresh**), member PII permissions from the legacy system are not migrated. Members start with baseline access and you configure required PII permissions in staging.
- With **Import members with policies** (**Use existing policies**), RudderStack carries forward member PII permissions as part of the migrated workspace policies.

See [Pre-migration Considerations]({{< ref "access-management/pre-migration-considerations.md#data-privacy-permissions" >}}) for guidance on how to handle Data Privacy permissions before migration.

## Staging area

During migration, the new Access Management system is in **Preview Mode** — a staging area where you configure and preview policies before deployment. 

In Preview Mode, you can review how permissions map to the new system and adjust policies **without affecting** permissions enforced in the [Permissions Management (RBAC) system]({{< ref "archive/dashboard-guides/user-management.md" >}}).

{{< info >}}
Your existing RBAC permissions remain in effect until you deploy. When you deploy, the RBAC system is removed from your workspace and the policies you configured in the staging area take effect.
{{< /info >}}

## What happens after migration

After migration, members and access tokens in your workspace will experience the following changes:

- **Admins**: [Admins]({{< ref "archive/dashboard-guides/user-management.md#organization-roles" >}}) in the legacy RBAC system will continue to have the same level of access.
- **Members**: Members in the legacy RBAC system will have their permissions mapped to their individual [Member Workspace Policy]({{< ref "access-management/members.md" >}}).
- **Service Access Tokens**: Service Access Tokens will have their permissions mapped to workspace-level access policies, maintaining the same access levels they had before migration.
- **Personal Access Tokens**: Personal Access Tokens continue to inherit the permissions of their associated users, now defined by the user's [Member Workspace Policy]({{< ref "access-management/members.md" >}}).
- **Interface**: Admins will be able to manage permissions through the new Access Management interface, which includes an intuitive policy editor to manage the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}), [Group Workspace Policies]({{< ref "access-management/groups.md" >}}), and [Member Workspace Policy]({{< ref "access-management/members.md" >}}).
- **New users**: New members added to the workspace after migration will inherit the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) by default.
- **Baseline Workspace Policy**: If you selected the [**Import** option]({{< ref "access-management/pre-migration-considerations.md#import-strategy-decision" >}}) during migration, the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) will be set to **view-only** for resources and **restricted access to all PII views** by default, providing Admins with a blank slate to configure workspace permissions from scratch.

## See more

- [Migration Steps]({{< ref "access-management/migration-steps.md" >}}): Step-by-step instructions for performing migration to the new Access Management system
- [Migration Scenarios]({{< ref "access-management/migration-examples/" >}}): Understand how Access Management migration works in different scenarios