Stay on Track with the Migration Portal
Learning Objectives:
After completing this unit, you’ll be able to:
- Learn how the migration process works.
- Use the Migration Portal to manage migration tasks.
The Migration Portal
You now have access to a new Migrations detail page for upcoming migrations. This page is available once both the org owner for the destination Grid org and the migrating workspace Primary Owner have approved the intent to migrate.
To initiate this, follow the four steps outlined and the following screenshots.
- An Owner on the Grid Org starts from the Workspaces | Migrations page of the org owner dashboard, and select the Migrate Workspace option in the upper-right corner.
- Enter the workspace ID (which always begins with a T) and the workspace URL for your migrating workspace(s) and press Send Migration Request. If you are unsure of how to locate the Workspace ID, refer to the Locate your Slack URL or ID article on the Slack Help portal.
- If migrating more than one workspace, you need to repeat this process for each migrating workspace.
- If migrating more than one workspace, you need to repeat this process for each migrating workspace.
- When successfully submitted, the org owner sees that the migration they initiated on the Migrations page is Pending workspace approval. At this point, only the Workspace Primary Owner needs to approve the migration, as the approval on the Grid Org side is now done.
- The migrating workspace Primary Owner receives a Slackbot message and an email asking them if they agree to approve the migration. The migration does not begin automatically once Approve Migration is selected, it simply completes the migration approval.
Migration Details Page and Checklist
Once you have approved the migration action, you can access the Migration Dashboard and checklist where you can accomplish all premigration preparation tasks. Org owners can access this page by selecting the name of the migrating workspace listed on the Workspaces | Migrations page in the org owner dashboard.
Migration Checklist Items
The list of migration to-do’s are as follows.
- Add org owners
- Configure Okta
- Merge Matching Accounts
- Resolve conflicts for migrating users
- Review conflicting settings
- Schedule migration
Using the Migration Portal Checklist
The Migrating users tab and full checklist take roughly 24 hours to load after it’s approved. And the user data refreshes roughly every 24 hours.
Merge Matching Accounts
Merge Matching displays the number of workspace users with exact matches in the org. If the org owner wants to review the users individually to confirm they should merge during the migration, they can download a CSV by selecting the download a CSV link. The org owner needs to confirm these user accounts should merge before the migration can be scheduled.
After selecting Confirm, org owners see a confirmation asking them to confirm their decision. Selecting I agree saves the decision to merge all workspace users with an exact match on the org during the migration (no changes are applied before the migration begins). If new exact matches are discovered prior to the migration, this step does not need to be completed again. Those accounts also automatically merge, with the org user’s account details taking precedence.
Resolve Conflicts for Migrating Users
Resolve Conflicts displays the number of workspace users with a partial match in the org. The org owner needs to review and resolve these user accounts before the migration can be scheduled. They can view all unresolved user conflicts by selecting the Review Conflicts button or the Migrating users tab at the top of the page.
The Migrating users tab displays all of the users that migrate in from the source workspace. By default, the page is sorted to show users with Conflicts as these users require an action before the migration can be scheduled. Using the filter in the top-right of the page, org owners can also view All users or Resolved users (users with no conflicts or for whom a merge or keep separate decision was already saved).
For each workspace user whose account details have a partial match with an org user, this page displays CONFLICT in the Status column. Action is required for these users. If a workspace user matches with more than one org user, all org users with a partial match are displayed. The org owner must choose whether they want the workspace user to merge or be kept separate (and thus migrate as a new account into the org) with a matching org user by selecting Merge Accounts | Select User and Merge or Migrate as New Account.
Here’s a view of a single account conflict.
This is what a multiple account conflict looks like.
If the workspace user should merge with one of the org users, the org owner should select Merge Accounts and Select User and Merge. This opens a modal where they can complete the next steps.
If a workspace user has account conflicts with multiple users on the org, the org owner first needs to choose which account they want the workspace user to merge into. If there is only a single account conflict, the org owner can skip this step.
Next, the org owner needs to choose which account data to use if the workspace user and org user have different values for some fields. By default, data for the org user is selected.
If a user’s access level changes as a result of the org owner’s selections, they see a message asking them to confirm that they’re OK with this before saving their changes.
After saving all changes, the workspace user now displays RESOLVED in the Status column and shows which accounts merge during the migration.
If the accounts shouldn’t merge, the org owner can select Migrate as New Account. This opens a new modal where the org owner can make changes to the workspace user’s account details that are currently duplicated in the org user in order to keep the two accounts separate and migrate in the workspace user as a new account on the org.
After saving all changes, the workspace user now displays RESOLVED in the Status column and shows that a new account will be created on the org after the migration.
It’s possible for new user account conflicts to come up after the migration is scheduled but before the migration happens if changes are made to user accounts on either the workspace or org side. If this occurs, org owners receive a Slackbot message and email prompting them to take action and resolve the conflicts before the migration starts. Otherwise, the migration won't proceed as scheduled.
Review Conflicting Settings
Review Conflicting Settings in the checklist displays the number of conflicting settings between the migrating workspace and the org. An org owner can select Review Settings Conflicts to see which settings are mismatched. They can also click the Settings changes tab to see the settings.
This page displays up to 15 settings that are misaligned between the workspace and the organization. Compliance and ML Opt-Out settings apply the more restrictive setting from either the workspace or the organization. Security and retention settings force the workspace to adhere to the organization’s policies.
The settings don't need to be changed before submitting the acknowledgment and selecting the Confirm Settings button. Many of the settings can only be changed by contacting Slack, so as long as the org owner is comfortable with how the settings update during the migration, they just need to submit their acknowledgment of what will change to move on to the next step.
After selecting Confirm Settings, the org owner sees a modal prompting them to confirm they approve all settings changes that will take place. Selecting Confirm completes this step.
Set Up Schedules
Org owners are able to schedule their migration from the Grid migration detail page. Scheduling is possible after all prior checklist items have been completed. This includes setting up SSO, resolving all user account conflicts, and reviewing and acknowledging settings conflicts. Additionally, migrations can't be scheduled when the migrating workspace has an import running.
Schedule Your Migration
The Grid migration detail page starts with showing the estimated migration downtime and migration. Once all prior checklist items are complete, the Schedule Migration button is no longer disabled and can be used to schedule a migration.
Schedule your migration on the Grid migration detail page displays both the migration duration estimate and migration downtime estimate. Once all checklist items are complete (and there is not an import running), the migration is ready to be scheduled. The org owner can click Schedule Migration to proceed with scheduling (this is only available to click once Steps 1 to 5 of the checklist are complete).
The Schedule your migration modal displays the migration duration estimate and prompts the org owner to select a start date and start hour. Once the start hour is selected, the org owner can select when to start the migration, which is a specific start time within the start hour. The estimated time of migration completion shows at the bottom, based on the start time. Selecting Schedule Migration completes this step, and unless the migration is canceled, rescheduled, or additional premigration conflicts arise, the migration runs at the selected date and time.
The start date picker only highlights dates available for the migration. For the date to be available, there must be at least one slot on that date that is long enough for the estimated migration duration. Migrations into the same destination Grid org are only allowed to be scheduled a minimum of 24 hours apart. Migrations can be scheduled between 60 seconds to 90 days in advance of the start time.
The start hour picker only shows hours on the selected start date that are available for the migration.
The start time picker only shows times within the start hour that are available for the migration to begin.
If a time becomes unavailable during the scheduling process, an error message appears on the modal. The org owner can select a different start date, start hour, and start time to move forward with scheduling.
Once the migration is scheduled, the org owner can adjust the time slot by clicking Manage. Clicking Reschedule migration opens the Schedule your migration modal. Clicking Cancel scheduled time opens the Cancel scheduled time? modal.
The org owner can click Cancel Scheduled Time to cancel the scheduled migration. The migration can be rescheduled from the Grid migration detail page at any time. Clicking Cancel on the Cancel scheduled time? modal returns to the Grid migration detail page.
Migration Day: What to Expect
Migration Flow
Post-Migration Smoke Testing:
After your migration to Slack Enterprise Grid, perform the following smoke tests to ensure everything functions properly:
Post-Migration Support or Issues
If you have any issues during or immediately following your migration, please contact the Customer Experience team by emailing feedback@slack.com. They are available 24/7 and are your fastest path to immediate assistance.
Sum It Up
In this unit, you reviewed using the Migration Portal to manage your premigration tasks, including initiating requests, using the dashboard, and resolving account and setting conflicts. In the next unit, you focus on essential cleanup activities to ensure all user data is accurate and ready for migration.