Launch Slack Enterprise Grid Migration
Learning Objectives
After completing this unit, you’ll be able to:
- Explain how the migration process works.
- Describe the purpose of Slack Enterprise Grid.
Slack Enterprise Grid Migration
It’s helpful to understand why a client pursues a grid migration. It’s relatively common for different teams within an organization to spin up their own Slack workspaces as needed. If the organization wants to bring all those disparate workspaces under one roof, they need to migrate those workspaces to an Enterprise Grid plan.
Here are a few common scenarios of when grid migrations are needed.
- When a client has allowed for workspace creation (and sprawl) outside of their grid environment and has decided to bring these workspaces into the grid.
- If a client acquires a company that is also on Slack and has existing workspace(s), but is not on grid.
- To house all of their owned workspaces under one grid instance with a common set of policies and settings.
One of the most important aspects of launching Slack Enterprise Grid for clients is the preparation involved. You need to understand how the grid migration process works, deliver a grid migration overview, and define the premigration activities for the client. Together, these activities ensure a successful launch.
Define Slack Enterprise Grid
Slack Enterprise Grid is designed to mirror the way a company is structured by providing unlimited workspaces that are connected within the container of an organization. Workspaces are often provisioned for business units, departments, or subsidiaries but are flexible enough to support an organization’s unique needs. Enterprise Grid is the only Slack plan in which an organization can have multiple workspaces in Slack.
Enterprise Grid allows an organization to bring multiple existing Slack workspaces together into one unified grid.
The first step in the process is to unify multiple workspaces under a single grid organization, also known as grid migration or migration.
Migration Process
In most cases, clients have existing pockets of Slack usage across one or more workspaces before deciding to invest in Enterprise Grid as their platform of choice. Often these workspaces contain valuable data that the client wants to retain and incorporate into the Enterprise Grid through the migration process.
So what does a grid migration look like? During a migration, data from the migrating workspace is moved to the grid in its entirety rather than being copied or selectively migrated. However, some data moves to the organization (org) level while other data remains at the workspace level.
Data point |
Migrates to organization level |
Remains at workspace level |
---|---|---|
User profiles and settings |
X |
|
Custom profile fields |
X |
|
Direct messages |
X |
|
Files |
X |
|
Custom emojis |
X |
|
Channels |
X |
|
Channel content |
X |
|
App |
X |
|
Bots |
X |
|
User groups |
X |
Understand Elements of Org-Level and Workspace-Level Data
You might wonder, “Why does it matter where the data is?” Good question! There are many benefits of Enterprise Grid, such as the option for multiple workspaces where users can collaborate within or across workspaces contained within the client’s larger organization. The location of data has benefits for a multi-workspace grid structure.
The graphic represents the migration process from two separate workspaces to a consolidated Enterprise Grid.
Org-Level Data
Certain data will now reside at the organization level by default with the migration to the grid. The client can have multiple workspaces within their grid. And the client’s users can now collaborate across all workspaces and benefit from consistent policies and assets (like files and emojis).
For example, users can direct message (DM) anyone in the org, no matter what workspaces(s) they belong to.
Workspace-Level Data
Any data that doesn’t move to the org level remains contained within the workspace. By staying at the workspace level, these aspects of Slack have the ability to work collaboratively with the rest of the org.
For example, a channel can be made available only in one workspace or it can be shared across multiple workspaces in the org.
One way to think about grid migration is to imagine your migrating workspace as a house and the grid environment as the gated community that it’s being moved into. To take this metaphor further, everything in the house is preserved during the move, but it’s now a part of the gated community and governed by its rules. As more people move in, more houses can be built to meet the needs of this growing community. Similarly, as your client’s organization continues to evolve, more workspaces can be added to their grid environment to reflect the makeup of their organization.
Phases of Grid Migration
Since a grid migration is a movement of data, the amount of time it takes to migrate a workspace depends on the amount of data that needs to be moved. There are three main phases of a grid migration.
-
Hard downtime: Workspace is unavailable to end-users while custom emojis, user profiles and settings are migrated.
-
Open phase (workspace available with limitations): All channels are available and the workspace is accessible to end users, but some message history may be temporarily unavailable, including direct messages and files.
-
Reindexing: This is a post-migration phase. All the new data from the migrated workspace is reindexed to the grid instance and search results may be temporarily incomplete.
Sum It Up
You’ve gotten an overview of Slack Enterprise grid migration which covered why it’s done, how it works, and what data goes where. Now, dive deeper into the essential preparation activities for migration.