Prepare to Migrate

Learning Objectives

After completing this unit, you’ll be able to:

Define the premigration activities.
Execute the premigration activities.

It’s time to review the activities that need to happen before you can effectively migrate a client to Enterprise Grid. The Grid Migration Checklist is a helpful document to share with your client and to reference as you prepare to migrate.

Plan the Migration Overview Presentation for the Client

A migration overview presentation is critical in preparing your client for their grid migration and should happen early in the process. It sets expectations about what happens before, during, and after a migration. Here’s what should be included.

Roles and Responsibilities

The project team
Key stakeholders who will work on SSO configurations and data cleanup ahead of migration
Project team managers responsible for change management

Process Overview

Migration basics
Preparing for a migration
What to expect during the migration
What to expect after the migration

Timing for Activities

Typically, this session should happen relatively early in the project because it provides a rundown of the grid migration process and kicks off the premigration activities.

Once you have selected a target date, work with Slack to schedule the migration. It's important to schedule the migration well in advance.

At a high level, the premigration activities include the following.

Grid org setup
Premigration planning
Premigration cleanup

The following sections provide more detailed information about steps and best practices to complete each activity in the Grid Migration Checklist.

Grid Org Setup

Before you migrate a workspace into a grid environment, the grid org needs to be set up. This includes creating the destination org and choosing a Primary org owner to complete the setup process. If your client is new to grid, the license signature triggers an email invite to perform the initial setup. If they have been on grid for some time, this grid org setup is already complete. This activity includes Enterprise Grid destination and Single Sign-On (SSO).

It’s a requirement to set up SSO on the grid before the migration because this is how users sign into their grid environment.

Enterprise Grid Destination

Before planning for a migration, make sure that the Enterprise Grid destination (org.enterprise.slack.com) is set up. To do that, advise your client to choose a Primary org owner who receives an email to set up the grid org and complete the initial setup click-through. We recommend that the Primary org owner uses a service account to complete this setup (for example, slack_service_account@company.com).

In addition, work with the Slack team to link the billing for all the workspaces that your client is migrating to the Enterprise Grid org. A paid workspace can't be scheduled to migrate into the grid if the billing hasn’t been linked to it. The billing link will group the migrating workspaces into the overall grid license, and the client will no longer be billed for the standalone workspace. This is especially important when it comes to mergers and acquisitions.

Lastly, if a client plans to conduct testing prior to the migration, work with Slack to set up a grid sandbox environment.

Single Sign-On (SSO)

Once you have completed the above prerequisites, ensure that the client sets up SSO on the destination grid before the migration. Members logging in to the grid environment are required to authenticate through an identity provider (IDP), like Okta, therefore setting up SSO is a requirement. Guests, however, can bypass SSO if the customer enables that option for them (most customers don’t require SSO for guests).

If there are other users that should bypass SSO, there's an option to bypass SSO for those specific members by adding them to the SSO exclusion list. This feature offers flexibility for certain users, but it shouldn’t be used as a scalable solution to bypass SSO overall.

It’s not recommended that clients preprovision users into their grid before a migration because that increases the duration of the migration process due to profile matching.

Premigration Planning

Once the grid org is set up, the next series of steps in the premigration planning ensure that users are properly informed about the migration and that the right workspaces are ready to migrate at the scheduled time.

Tip: Your client assigns different Slack roles to resources on their team, including product owner and admin roles. These roles have responsibilities in the premigration planning steps.

Reference the Slack Help Article in the Resources section to learn more about the roles specified.

End-User Communication

Since a grid migration has an impact on Slack user experience and data, you should remind the client to send out communications to the rest of the organization ahead of the migration. The most disruptive aspect of the migration is the hard downtime where employees are unable to access Slack.

Clients can use the Communication Template as a starting point to:

Provide details on when the migration is happening.
Ensure workspace administrators who are helping with migrations stay informed on what to expect.
Ensure end users update to the latest version of the desktop and mobile apps.
Provide instructions on how to log in post-migration if this is the first time implementing SSO.

If undergoing a large migration, consider recommending change management efforts that include creating a dedicated support channel post-migration, holding office hours, and identifying power users to help support other users.

Tip: Weeknight or weekend migration slots are highly encouraged for longer migrations (12+ hours of hard downtime) to limit ‌disruption to users in their day-to-day work.

Workspace Audit Review

Typically, the migrating workspaces are listed in the SOW, but it’s still wise to confirm this information with your client as a part of migration planning. You can also work with the Slack Account team to pull a workspace audit and give your client a complete view of all the workspaces associated with their domain(s). This helps confirm the migrating workspaces and create a plan for the remaining workspaces.

Migration Scheduling

After you’ve confirmed the migrating workspaces, Slack can schedule the migrations. You need to work with your Slack representative, who can help you book a time slot in the migration calendar and schedule the grid migration in the system.

Here are recommended steps to flow when scheduling a migration.

Determine initial migration time estimates.
Work with your client's Slack CSM to find availability for migrations.
Add holds for potential dates, but remember to remove holds that aren’t used.
Communicate and confirm dates.
Reach out to the CSM to confirm and schedule the Grid Migration in the Slack systems.

Migration Settings

To execute migration scheduling, migration settings need to be selected. These include automated communications and custom profile field settings. Provide your customer with the options (image follows) and relay their selections to your Slack representative, who will be scheduling the migration.

By default, the Skip SSO token migration box is left unchecked when scheduling migration. However, there are some use cases where the SSO token information shouldn’t be migrated. These cases include when a client is switching from one IDP to another with their upgrade and in merger and acquisition scenarios.

Custom Profile Settings for SSO

Accepting Slack-Initiated Migration Invitation

Once Slack schedules a migration, it needs to be accepted by the customer before the scheduled time. The migration communication is as follows.

All org owners and Org Primary Owner receive a Slackbot notification.
The migrating Workspace Primary Owner receives a Slackbot notification and email.

Even though multiple people can receive that invitation, only one person has to accept the invitation in order for the migration to run. Similarly, any of the recipients can reject the invitation at any time leading up to the migration. If your customer is managing multiple migrations, they can also accept the migration in bulk via the organization settings dashboard for the Enterprise Grid.

There are two scenarios where a migration doesn't run due to invitations.

If the invitation is rejected by either the grid Org Primary Owner or Workspace Primary Owner, the migration won't run.
If scheduling a date for a migration, it needs to be within 30 days from the request date. If the invitation is pending over 30 days, it expires. This is particularly important if scheduling a migration for a future date. In these scenarios, ask Slack to resend the invite to migrate the workspace.

Domain Claiming

Domain claiming is an Enterprise Grid feature that gives Org Primary Owners control over who can create workspaces using their company email address. Previously, when employees on grid orgs were first learning to use Slack, they would accidentally create dozens of workspaces in an attempt to join their company’s Slack instance. Users may also have created additional workspaces before the company had an Enterprise Grid plan with their company email addresses resulting in rogue workspaces.

Domain Claiming does not retroactively impact existing workspaces or users within those workspaces. To claim the domains, instruct the client to email the Customer Experience team with the request.

Once the domains are claimed, users are redirected to the org when trying to create a new workspace using their company email address. A typical scenario is that an employee goes to slack.com to create a new workspace. They receive an email with a six-digit confirmation code to confirm that they own the email address. Once they’ve confirmed, they either receive a message that lets them know they don’t have access to create new workspaces in the org, or they receive an email stating that their organization is already using Slack, and they’re prompted to sign in with SSO to create their account.

Sum It Up

You know all the crucial prep work for your Slack Enterprise Grid migration, including setting up your organization, planning communications, and handling user data. Next, we look at the Migration Portal.

时间估计

主题

需要帮助？