***

title: Migrate your Enterprise team to an organization
early\_access: true
plan: preview
updated: 2025-11-12T00:00:00.000Z
---------------------------------

When you migrate your Enterprise team to an organization, your organization initially contains a single team that includes all the original team’s shared workspaces.

These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team.

This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple organization teams, to take full advantage of organization benefits.

## Determine the structure of your teams and memberships

A team within an organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled.

By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn’t moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team.

Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces.

To determine the team membership, do the following:

1. The [Organization Manager (or Super Admin)](/docs/administration/roles-and-permissions/) creates a team and assigns a Team Manager to it.

   The Team Manager is the delegated owner of the team’s content and membership and controls how the team’s content is shared. The Team Manager is the leader of people responsible for the team’s content.

2. Determine how restricted the team access should be. All organization teams have two [settings](/docs/administration/managing-your-team/team-settings/):

   * **Allow anyone from the organization to join as a Member, or require Team Manager approval to join** — Turn on if you want to strictly control access to teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control.
   * **Allow anyone on the team to share content with the larger organization, or require Team Manager approval to share outside the team** — Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled.

3. Populate the team with the members who are responsible for the team’s contents.

   * If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the teams open for any user to join.
   * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining team memberships.

## Move work into teams

You can move work into teams manually, but if a significant number of workspaces need to be moved, you can move it in bulk.

Any Workspace Admin can move their workspaces into any team where they are a member, so the responsibility of migrating work can be delegated to all the members of the team that was created.

If you can identify team workspaces ahead of time, Postman provides public API endpoints and collections that you can use to move large numbers of workspaces in bulk.

After you move workspaces, do the following:

1. Determine the Admins for each workspace from the list of workspace users.
2. Review the roles on the workspaces you moved, and align them with these best practices:

   * If the workspaces were previously shared with the organization, ensure they remain shared with the organization.
     * If the APIs are intended to be consumed by others, ensure those people still have access to view them.
     * If you require limited sharing, consider sharing APIs with specific teams that are interested in them, leveraging the team memberships, rather than inviting individuals.
   * Ensure that workspaces are viewable by the team it was moved into, unless there is a specific reason it shouldn’t be shared with other team members.
   * Make the workspace editable by the team.
     * Because teams can have both Members and Guests, set up a pattern where team members are the primary contributors to the work, and Guests, having only view access, are the consumers.
     * The team membership can continue to grow and change, and the users with edit access to the team’s workspaces will adapt accordingly.
   * Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive team to hold such workspaces if they are no longer needed or active.

Learn more about [creating organization teams and workspaces](/docs/administration/managing-your-team/create-org/).