With the release of Microsoft Teams, many organizations have been exploring what a Slack-to-Teams migration would entail. Only recently has Microsoft provided APIs to allow the ingestion of data types. This has left organizations looking to undertake a Slack-to-Teams migration with limited options: users self-migrating, abandoning the Slack source environment altogether, or running two platforms.
Let’s review why organizations are keen to make this change and the top challenges they face when taking on a Slack-to-Teams migration project.
Why migrate off Slack?
Slack users are passionate. Many correlate Teams to being an iPhone and Slack being an Android. In basic terms, Slack has traditionally provided far more APIs and options. As time has gone on, Microsoft has provided more and more options in Microsoft Teams. This has been bringing Teams closer and closer to the parity of Slack. As this keeps happening, organizations are looking to get more from their large Office 365 investments. With Microsoft being aggressive in encouraging organizations to centralize on its platform, many organizations are now ready to tackle their Slack-to-Teams migration projects. For those willing to make the move, here are the typical drivers:
- Cost savings – Direct
Cost savings is becoming the biggest motivation for Slack-to-Teams migration projects. Because Teams is part of the Office 365 bundle, IT organizations can remove the extra spend of Slack. For some, this can also remove some other tooling required to manage Slack, such as enabling users, syncing users, monitoring and eDiscovery.
- Cost savings – Indirect
Centralizing productivity with one platform. This means users know where to go when collaborating and are not trying to hunt for the right platform or have split conversations on multiple platforms.
- Data risk and security
Where organizations already need to protect Office 365, they want to reduce their data footprint and focus their efforts on protecting one system.
Common migration challenges
This blog covers many of the core changes, however, there is more guidance on this topic. Microsoft has highlighted some common issues companies experience with Slack-to-Teams migrations. As a migration specialist, let me provide some practical advice: This will not be an easy project (perhaps this should be the title of this blog?). Organizations with heavy Slack usage and years of experience find these projects to be extremely difficult. Let’s dive into the common issues with Slack-to-Teams migrations.
Passionate user bases
Most Slack users love Slack. Its user following has a great reputation with developer communities and start-up cultures. This creates a cult-like following in organizations and, is in itself a massive barrier, despite the significant changes to Teams over the years to obtain feature parity.
Culturally, issues are difficult to describe, quantify, and address. Being known as the person that got rid of Slack might harm a leader politically, or even limit the days the person is in the organization. My joke that we should bundle a resume builder in with these projects continues to fall flat.
To break this culture, you need to rally everyone towards the cause. As with any difficult change, you need to provide open transparency and support for your change management experience. This isn’t a simple change, but a manageable one.
I go into greater detail about the planning and change management of Slack-to-Teams migration projects in this article on Practical 365: How to plan your Slack-to-Teams migration project.
No 1:1 function mapping
There are four major differences between Slack and Teams. All of these areas below need to be addressed to have a successful migration. For many, this can seem overwhelming at first. However, with a good plan, these differences can be properly controlled.
1) Slack workspaces are different than Teams
Slack doesn’t have the same structure that Microsoft Teams does. Instead, Slack has large workspaces (in many cases just one) and loads of channels below them. Depending on your license level, your company could have only one workspace or several.
In reality, most organizations will migrate channels into several teams, some in a “1 channel to 1 team” ratio. Others will need to organize channels into teams. If you need to reorganize, this can be quite a burden. (You should never put 3,000 channels into one team!).
Re-organizing channels into teams is reported as perhaps the largest burden.
2) Slack channels
Slack channels migrate pretty easily into Teams channels. The main hiccup is the issue mentioned above regarding the organization of these channels.
3) Apps and integrations
In terms of functions, this is the main hang-up in a Slack-to-Teams migration. For Slack, BOTs and integrations are the classic advantages of its platform. However, many may be surprised to see identical BOTs or integration options for most functions in Teams.
For other functions, there is likely a method, but you will need to do it differently. There aren’t many functions left that you can only do in Slack. With the limited Teams migration APIs, these are manual configurations in the Teams target. Even as more and more APIs come out, there is still manual work required by Slack admins and end-users. At a minimum, they will need to re-authenticate add-ons. Dependent upon the function, there could be a great deal of work.
Some custom developments continue for integrations, and many companies that started with integrations have not changed to the new method for their applications. This can add additional complexity to the planning. Both custom integrations and applications need to be properly analyzed.
One solution. Many workloads.
4) Direct messages
One of the major API challenges with Slack-to-Teams migrations has been the inability to migrate private messages. This is slowly getting better. Some vendors have been successful at streaming direct messages into Teams, however metadata is lost. Again, this is a space to watch, since it is one of the most requested features by every migration administrator worldwide.
Avoiding migration failures
Many people use the moving truck analogy when referring to migration projects. They advocate that you don’t want to bring junk to the new house, so you should downsize prior to the move. Although there is some truth to this, you want to be careful that you do not go too far. Otherwise, to continue the analogy, the truck will show up, and nothing will be packed. Too much change can add confusion.
My advice is: If you do too much cleanup in advance, it may not be successful. If you want to do it as part of the migration, the migration could get blamed for the issue and possibly interrupt the project. This could result in users and management that may feel that data is missing and be less concerned that expired data was not migrated per legal and compliance policies.
Recommended practices:
- Delete workspaces and teams that are not in use 30 days before the project
- Remove BOTs and external connections 30 days before the project
Not recommended:
- Not moving data that looks old, since you will likely end up moving it anyway if others are looking for it or voicing concerns
Preparing for successful migrations
A Slack-to-Teams migration can be a difficult undertaking politically. Regardless of how often you communicate that something isn’t migrating, the expectation is that the same function will be working on Monday if it worked on Friday. Migration projects boil down to three steps: Plan, move and manage. When performing migration projects that are not moving between the same systems, you need to plan accordingly, dive into discovery and try to identify highly utilized features. You can’t focus on everything, but the “80/20” rule certainly applies here.
