# Pre-migration Considerations


{{< 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.

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

Before you begin migration to the new [Access Management system]({{< ref "access-management/overview.md" >}}), 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](#import-strategy-decision).

## 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]({{< ref "access-management/service-access-tokens.md" >}}) in all workspaces in your organization are migrated to the new Access Management system together

{{< warning >}}
If your organization has multiple workspaces, make sure to check and fine-tune each workspace's [baseline policy]({{< ref "access-management/migration-steps.md#step-2-configure-policies" >}}) before deploying the new Access Management system.
{{< /warning >}}

## 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]({{< ref "access-management/members.md" >}}).

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. 

{{< success >}}
This approach gives Admins more granular control over individual member permissions while maintaining the same access levels they had before.
{{< /success >}}

## Baseline Workspace Policy

New members added to a workspace after migration will inherit its [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) by default.

{{< warning >}}
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]({{< ref "access-management/baseline-workspace-policy.md" >}}) to grant the default permissions you want new members to have when they join your workspace.
{{< /warning >}}

Also, note that unless configured by Admins, the baseline workspace policy contains [view-only permissions]({{< ref "access-management/baseline-workspace-policy.md#default-behavior" >}}) for all resources with restricted access to PII.

## Granular resource-level permissions

Admins will be able to grant [**Edit**, **Connect**, and **Create & Delete**]({{< ref "access-management/policies-overview.md#edit-connect-and-create--delete-permissions" >}}) 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]({{< ref "access-management/members.md" >}}). | You want to retain the existing user permissions as is, without having to modify them later. | 

{{< info >}}
Service Access Tokens will be automatically imported with their current permissions in both import strategies.
{{< /info >}}

## Data Privacy permissions

In the legacy [Permissions Management (RBAC) system]({{< ref "access-management/glossary.md#role-based-access-control-rbac" >}}), the **Data Privacy** setting in **Settings** > **Workspace** > **Data Management** controls who can view PII in [Live Events]({{< ref "monitor/live-events.md" >}}) and debug logs across various resources.

{{< image src="images/access-management/migration/legacy-data-privacy-settings.webp" alt="Legacy Data Privacy settings in Workspace settings" >}}

Under **Who can view restricted data?**, you choose one of two options:

| Legacy setting | <div style="width: 300px;">Behavior</div> |
| :---- | :---- |
| **Anyone on your team** | All workspace members can view PII in live events and debug logs. |
| **Only people you select** | Only members on the allowlist can view PII in live events and debug logs. |

During import, Data Privacy permissions follow the same [import strategy]({{< ref "access-management/pre-migration-considerations.md#import-strategy-decision" >}}) 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.

### Allowlist members

If a workspace uses **Only people you select**, members on the **Data Privacy** allowlist are migrated with the following permissions in their [Member Workspace Policy]({{< ref "access-management/members.md" >}}):

| Resource | Permission | Resource ID |
| :---- | :---- | :---- |
| Event Stream Sources | Live Events PII | All resources |
| Destination | Live Events PII | All resources |
| Destination | Failure samples PII | All resources |
| Transformation | Live Events PII | All resources |
| Transformation | Failure samples PII | All resources |

In the policy editor of the new Access Management system, they appear as **Event Stream Source Live Events**, **Destination Live Events**, **Destination Failure Samples**, **Transformation Live Events**, and **Transformation Failure Samples** under the [PII permissions]({{< ref "access-management/policies-overview.md#pii-permissions" >}}) section.

Members **not** on the allowlist do not receive these permissions through the Data Privacy allowlist mapping.

### Important considerations

- Review the Data Privacy setting for **each workspace** before import. Organizations with multiple workspaces may use different settings per workspace.
- If you choose **Import members with policies**, verify allowlisted members receive the expected PII permissions in staging before deployment.
- If you choose **Import members** (**Start fresh**), no legacy Data Privacy permissions carry over. You will need to configure PII access in your [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}), [Group Workspace Policies]({{< ref "access-management/groups.md" >}}), and [Member Workspace Policies]({{< ref "access-management/members.md" >}}) before deploying the new system.
- The Data Privacy setting controls access to PII in Live Events and debug logs. Other [PII permissions]({{< ref "access-management/policies-overview.md#configurable-permissions" >}}) — for example, Tracking Plan violations or Reverse ETL failure samples — come from legacy role permissions and are migrated separately when you choose **Import members with policies**.
- If a workspace uses **Anyone on your team**, member PII access during import comes from legacy role permissions rather than the Data Privacy allowlist.

## Migration process

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

Note that:

- While Access Management is in **Preview Mode**, Admins can add members and configure policies in the new system **without affecting** permissions in the current [Permissions Management (RBAC) system]({{< ref "archive/dashboard-guides/user-management.md" >}}).
- Legacy RBAC permissions remain in effect until you deploy. For ongoing tasks, continue granting access through the legacy RBAC system. Update policies in staging in parallel so your deployed configuration matches the access you intend to enforce.
- When you deploy the new Access Management system, the legacy RBAC system is removed from your workspace and all policies you configured in staging take effect.
- In **Preview Mode**, members invited in the Access Management system will not get workspace access until you deploy. To invite users immediately, use the [Invite users]({{< ref "archive/dashboard-guides/user-management.md#invite-users" >}}) flow in the RBAC system.

See [Migration Steps]({{< ref "access-management/migration-steps.md" >}}) for step-by-step instructions.

## See more

- [How Migration Works]({{< ref "access-management/how-migration-works.md" >}}): Learn about the technical process of migration
- [Key Concepts]({{< ref "access-management/concepts.md" >}}): Understand the core concepts of Access Management