Groups Migration

This guide outlines the migration process for StrongDM customers transitioning from the classic "StrongDM Role" to the new groups/roles modality.

In October 2025, StrongDM released groups. Previously, roles at StrongDM performed two functions: A role was a collection of users but was also a way to provide a set of permissions to that collection of users. Now, organizations have the ability to separately have groups of users and then apply various roles to those groups to grant them permissions.

No migration is required for existing organizations. The preexisting roles behavior continues to function as it always has.

If your organization uses roles to manage collections of users, and you wish to learn more about migrating from legacy roles to the new groups/roles structure in your StrongDM organization, and how that might be beneficial for you, read this guide. The guide outlines the migration process to the new design with separate roles and groups.

This guide is only applicable to customers whose accounts predate the groups feature becoming generally available on October 2, 2025. For accounts created after that date, Groups will just work as described in the Groups documentation.

Q&A Regarding the Migration

For customers whose organizations existed before October 2, 2025:

• Can I keep operating as I am with roles? Yes. There is no requirement to migrate to groups.

• Do my roles get converted? Not automatically, but you can do so with the CLI (described below).

• Will my provisioning start creating groups instead of roles? Not until you ask Support to make that happen.

Why should I migrate to groups?

There is no requirement from StrongDM to migrate to the new groups feature. Your organization can continue to function without making the change.

However, migrating brings three benefits:

• Role and group flexibility: Abstracting groups from roles allows you more flexibility in how you assign access. You can create smaller “right sized” roles that represent work tasks and are assigned to many groups, making it easier to see which groups use which permissions so you can reduce standing privilege.

• Future feature compatibility: Future StrongDM features will rely on groups instead of roles to represent groups of users because of the flexibility and alignment with IAM patterns noted above. As more features that use groups are released, the value of completing the migration increases for your organization.

• Alignment with IAM patterns: Migrating to the new groups feature aligns your StrongDM architecture with the rest of your IAM stack (the groups in your IDP will align with groups in StrongDM, rather than roles in StrongDM).

All members of a group inherit the permissions assigned to that group.

Backwards compatibility

To reduce risk to your operations, the post-migration state is backwards compatible with your pre-migration state. The migration process ensures that users will not lose access to the resources they need. Furthermore, you can iterate on small sets of roles to ensure that you understand the changes and to see that user access and experience is not affected by the change.

Migration Steps

Follow these steps to migrate your organization to use the new groups feature along with existing roles.

1. Plan for the Role/Group Split

Before initiating the migration, you should analyze your existing roles. Any roles that contain users should be targeted for migration in the role/group split. Migrating those roles will bring your StrongDM architecture in line with the rest of your IAM estate and allow more flexibility in how you assign access to groups of users.

Many StrongDM organizations will want to test the migration process on small sets of roles before rolling it out to their entire organization. Analyze your roles to find roles with a combination of high visibility to your team and low consequence to your users. These are usually test roles created explicitly for the migration or roles that are used by the team that manages StrongDM:

• High visibility: Selecting roles that are used by you and your team means that you don’t have to wait for user feedback to see that the migration process preserves user access to resources. You can check your own access to resources immediately after migrating a role to a group.

• Low consequence: Although the migration process preserves user access to resources to ensure business continuity, selecting roles that have low importance to the business (for example, roles that are used for access to test/dev systems rather than prod) will ensure that you and your stakeholders can see the migration results and confirm access continues to work uninterrupted before continuing to migrate more business-critical roles.

2. Initiate Migration by Creating Groups From Roles

To begin the transformation, administrators will use the sdm admin groups create-from-role CLI command on a chosen role(s). This command turns a role with members into a role and an assigned group, ensuring no interruption to end user access, SCIM provisioning, or approval workflows. More than one role can be selected at once. When the command is run without the --commit flag, it is treated as a dry run, so that you can see what changes would have been performed. Add the --commit flag to actually make the changes.

This command performs the following critical actions:

• Creates a new group with the same name as the existing role

• Transfers all users from the existing role to the newly created group

• Reassigns any approval workflows that used the role as an approver to use the new group as an approver instead

• Assigns the original role, which now only functions as a collection of access rules, to the new group, ensuring that all users in that group maintain their existing access permissions post-migration

• Points any SCIM provisioning updates from your provider at the newly created group (when you update group membership in your SCIM or other provisioning provider, you will see that update reflected in the StrongDM group, not the StrongDM role)

After this initial migration step, StrongDM will automatically handle provisioning updates to the newly created group. Any changes to group membership in your SCIM provider will be reflected in the new group, ensuring up to date access for users.

3. Tiered Approach for Progressive Migration

You should continue the migration process using a "tiered" approach, moving from lowest-risk/highest-feedback user groups to tiers of higher consequence/lower feedback groups. This strategy builds certainty and confidence that end-user access is consistently maintained as expected throughout the entire migration.

4. Migrate All Remaining Roles

Once you are comfortable with the results of the phased migration, you can start migrating roles en masse. Use the StrongDM CLI sdm audit commands to pull a list of roles that have members. Pass the role IDs from your CLI audit into the sdm admin groups create-from-role command. This process allows you to migrate all remaining roles with members in StrongDM.

5. Enable Group Migration SCIM Switch

Once your migration is complete, you can opt to make this behavior the default for SCIM provisioning updates by contacting StrongDM Support.

To learn more about how to manage groups at StrongDM, see the Groups section.