Perform Premigration Clean-Up Activities
Learning Objectives
After completing this unit, you’ll be able to:
- Define and execute the premigration activities.
- Evaluate migration readiness.
The last and most important step in the premigration process is premigration cleanup. It involves walking your client through a premigration report and ensuring all user data is accurate and all conflicts are addressed.
This activity includes:
- Premigration report
- Email and user role conflict cleanup
Premigration Report
The purpose of a premigration report is to identify potential conflicts between the migrating workspaces and the grid, such as duplicate usernames or role conflicts. The premigration report offers a high-level analysis of potential issues, but it’s not a comprehensive list for all issues that a client may need to address before the migration. These reports have a 24-hour delay, so recent conflicts that are resolved may not be reflected until after this period.
You work with your client’s designated Slack CSM or can reach out directly to Customer Experience to request a premigration report for all the migrating workspaces. When making a request for a premigration report, specify the grid org that the workspace will migrate into and the workspace URLs or IDs that will be migrating.
The premigration report contains several sections that cover different elements of migration. Learn more about each section below:
Shared Channels
This section lists out all of the Slack Connect connections that a client has on the migrating workspace. While there are no action items here, this section may be helpful in identifying channels that are shared with the grid org that the client is migrating into.
During the hard downtime, Slack Connect channels are unavailable for both the migrating team and any other connected external parties.
Regular (Non-multi-Org) Scenario
This section of the report lists out all privacy mismatches between the Slack Connect channels that the migrating workspaces have with the grid org. Any channels listed in this section will be converted to a private multi-workspace channel post migration. Per the Slack Connect Migration FAQ document available in the Resources section, any Slack Connect channels between the migrating workspace and grid org will be converted into multi-workspace channels post migration. When it comes to channel visibility (public/private), the channel will be converted to private as long as one side has the Slack Connect channel as private.
Users on All Workspaces
This section provides clients with a list of all users in the migrating workspace(s), their current email address, role and whether they are in an enabled or deactivated state. This section is probably the most useful in the report because customer can use this list to compare against their IDP as part of the premigration cleanup. All migrating users should have their Slack emails updated to match the IDP. If they aren’t updated before the migration, duplicate accounts will be created in the grid environment.
Locked Preference Settings
This section of the report compares any workspace level settings on the migrating workspace against any existing org-level settings on the grid and will flag any differences. If the client hasn't set up any org-level policies and settings yet, this section will likely be pretty bare. The key settings to check are the data retention and sign in settings. If there are differences in settings, let the admins know that the org level settings always supersede the workspace level and any differences is overwritten by the org-level preference post migration.
The following settings are always overwritten by the org settings because they don’t exist at the workspace-level for grid.
- All sign in settings (including SSO, Mandatory Two-Factor Authentication, Session Duration)
- File Retention
- Direct message retention
Duplicated and Illegal Usernames
This section is an effort to identify potential duplicates between the migrating workspace(s) and the grid org based on users who have the same username in Slack. There are several possible scenarios when an “illegal” username is identified in the report.
- Two users (with different emails) share the same username. This is a “false positive.” There won’t be any duplication issues, but one of the usernames will be appended with extra digits upon migration so the two users don’t end up with the same handle.
- The same user (with multiple emails) utilizes the same username. This is a “true positive.” One of the user’s emails needs to be updated so that both match. If this is not done, then two different accounts are created for the same person.
Emails with Conflicting Roles
This section is a list of all users who have conflicting roles between the migrating workspace(s) and the org. This includes deactivated accounts since they get merged during migration. Role conflicts occur when a user is a Member, Single or Multi Channel Guest in one workspace and is a different role in another. If the role conflicts aren't resolved before the migration, they'll be auto-resolved during the migration.
Here’s how auto-resolution works.
- If one of the accounts is deactivated: The deactivated account gets promoted or demoted to match the account type of the enabled account.
- If both accounts are enabled: The account with the higher role is kept and access to the workspace(s) where the user has a lower role is removed.
Custom Profile Fields
This section highlights whether the migrating workspace(s) have any custom profile fields and may help decide if they’d like to import them.
Cleanup Email and User Role Conflicts
Now that you're aware of all the sections within a premigration report, it’s time to resolve any email mismatches and user role conflicts.
User Email Conflicts
Instruct your client to follow these steps to manually update a user email.
- Reference the Duplicated and Illegal Usernames tab of the premigration report to identify any users with duplicate accounts on one or more workspaces.
- Reference the Users on All Workspaces tab of the premigration report to identify user emails in Slack that are not consistent with the client’s SSO.
- Update all user emails to match SSO to prevent duplicate users and login issues.
Slack can also assist in this process by performing a bulk email update. In order to complete this process, the client must provide a worksheet stating the current email (column A), future state (column B) and Team ID where update should occur (column C).
User Role Conflicts
User role conflicts are generally caused by the user’s role being different between the migrating workspace and the grid.
Instruct your client to follow these steps to update user roles.
Steps:
- Reference the Emails with Conflicting Account section of the premigration report.
- Determine the role that a user should have in the grid environment.
- Update the user role in the migrating workspace(s) to what it should be in the grid.
If a duplicate account is created and the user logs in to one of the duplicate accounts, they only see the history of their channels, files, or direct messages of that account. All prior history is found under the original user account. User data does not merge for duplicate user accounts.
Once the customer has resolved all the conflicts, consider rerunning the premigration report to see if any of the issues persist and confirm that everyone migrating has access to Grid SSO and user emails have been updated to match the IDP.
Service Engagement Example–Techset
Follow along with the example company, TechSet, as they prepare for grid migration. As a part of premigration cleanup, TechSet needs to resolve user email conflicts and user role conflicts using the steps outlined above.
Identifying User Email Conflicts
Reviewing the Duplicated and Illegal Usernames section (image follows) of the premigration report, notice three users who have different emails in the two migrating workspaces. In this example, TechSet is using firstname.lastname@techset.com as their SSO email structure.
- A user with the username “queenbree” is using the email address bree.kallar@techset.com on the TechSet workspace and bree@techset.com on the Tech-Set social workspace. To resolve this issue, bree@techset.com should be updated to match SSO, which uses the email address bree.kallar@techset.com.
- Similarly, jleger@techset.com should be updated to john.leger@techset.com on the tech-social workspace.
- And swilliams@techset.com should be updated to sara.williams@techset.com on tech-social.com.
In addition to resolving duplicate accounts, TechSet should also review the section for Users on All Workspaces and ensure that those emails match SSO. In this example, TechSet reviews this section of the report and notices the following emails don’t match TechSet's SSO email structure (firstname.lastname@techset.com).
- adam.schuester@yahoo.com
- taylor.smith@gmail.com
- reese.walker@technologyset.com
- lebron.johnson@lks.com
To resolve these conflicts, all of these email addresses need to be changed to match SSO prior to migration to avoid duplicate Slack accounts.
Identifying User Role Conflicts
Reviewing the Emails with Conflicting Accounts tab of the premigration report, notice that there are three users with different roles across the two migrating workspaces.
- mindy.raghan@techset.com is a full member of the techset-social workspace and is a Multi-Channel Guest in the techset workspace.
- amy.brin@techset.com is a full member of the techset-social workspace and is a Single-Channel Guest in the techset workspace.
- james.marte@techset.com is a full member of the techset workspace and a Multi-Channel Guest in the techset-social workspace.
To resolve these conflicts, TechSet should determine the role that each of these users should have on grid and change their role assignment in the migrating workspaces.
Wrap Up
In this unit, you explored the crucial premigration cleanup activities, learning how to interpret premigration reports to identify and resolve email and user role conflicts. You also learned how to ensure all user data is accurate and ready for a smooth migration. Now you’re ready for the final steps to ensure your client's migration is fully prepared.