How can I move a project workspace while preserving its team roles and access?

Treat the move as two separate jobs: moving project content and rebuilding access. First, make an inventory of people, roles, project or channel membership, and sharing rules. Then compare that inventory with the destination platform’s controls. Don’t assume a content import also transfers permissions: Slack says its workspace-to-workspace imports do not import workspace settings, access and security configurations, or other customizations, which must be set up in the destination. That statement is specific to Slack’s tools, not a guarantee about other platforms. [S1]

Record both, because a person’s general role and their membership in a particular project answer different questions. Use one row per person and project combination if access varies by project. For example, this is a planning template, not a claim about any platform’s features:

Person | Current role | Project | Current access | Shared items or groups | Destination role/control | Recreate? | Checked by

Use placeholders until you can fill in actual names and settings. In “Current access,” describe what the person can do in plain language—such as view, edit, or manage—rather than relying only on a role label. Check the source platform’s own role documentation for the permissions attached to each role. Slack, for example, documents different administrative capabilities for owners, admins, members, and other roles, with permissions varying by role and plan. [S2]

Compare capabilities, not names. A destination role called “admin” may not mean the same thing as an old platform’s “admin.” For each inventory row, ask whether the destination setup gives that person the access they need for that project—and no broader access than your team intends.

A simple comparison might look like this:

Old: [person A], [role], [project X], can edit project files. New: [destination role or setting], [project X membership], can edit project files: [confirm].

Mark each item “matched,” “needs setup,” or “unclear.” Treat “unclear” as a question to resolve with the destination platform’s documentation or an authorized administrator, not as proof that access transfers. The available Slack role reference is Slack-specific; it does not map Slack roles to another platform. [S2]

Use your inventory to check every access rule the team relies on, including project membership, shared groups or resources, and workspace-level settings you recorded. Whether a particular rule transfers depends on the platforms and migration method; Slack’s guidance establishes that its settings and access/security configurations are not imported, but it does not establish what another platform transfers. [S1]

Before treating the destination as ready, ask an authorized administrator to review the comparison, set up items marked “needs setup,” and confirm the intended access for each project. Where the platform and your organization allow it, test with a separate workspace or a controlled test project before the real move; Slack says owners can test an import in a separate workspace, but that does not establish a testing feature for other platforms. [S1] Keep unresolved permissions visible rather than marking them complete.