Slack to Microsoft Teams Migration
Slack to Microsoft Teams Migration moves a Slack workspace into the Microsoft Teams you are already licensed for — planned, not dumped. IT Partner inventories every channel, member, file, app and workflow; maps Slack channels into a deliberate team-and-channel design instead of a one-to-one copy; runs the migration with Microsoft's native Slack to Teams migration tool in the Microsoft 365 admin center (public and private channels, threaded messages, reactions, channel files, canvases and lists, membership) or a third-party tool where direct messages or group chats genuinely have to come across; switches on Teams lifecycle governance on arrival — naming, expiration, guest policy — so Teams does not inherit Slack's sprawl; and runs the adoption communications and a read-only Slack cutover window so people know where their conversations went. $12 per user + $2,500 tenant fee (estimate, confirmed as a fixed written quote), about three weeks, and you pay after you approve delivery.
What this engagement is
Most organizations that run Slack alongside Microsoft 365 are paying twice for the same job: a per-member Slack subscription on one side, and Microsoft Teams — included in Microsoft 365 Business Basic, Business Standard, Business Premium, E3 and E5 — on the other, often with conversations, files and decisions split across both. Consolidating onto Teams is a straightforward cost case. What changed in early 2026 is that it became a straightforward migration too: Microsoft shipped a native Slack to Teams migration tool in the Microsoft 365 admin center that ingests a Slack export package and populates the Teams channels you map it to — public and private channels, channel messages with their threads and standard reactions, channel file attachments, canvases and lists (carried across as file attachments), and channel membership. What the native tool does not do, at the time of writing, is direct messages, group chats, Slack workflows, or custom app integrations — and it needs a Slack export that your Slack plan actually permits. Those two facts shape every honest Slack migration, and they shape this one. The engagement starts with an inventory, because a Slack workspace that grew for years is mostly archive: channels nobody has posted in since a project shipped, bots whose owners left, integrations that were somebody's experiment. We inventory channels (activity, members, files, whether public or private), members (and whether each maps to a Microsoft 365 account), apps and workflows, and retention settings. Then comes the design decision that separates a migration from a dump: a Slack workspace is not one team. Channels are grouped into teams by function or department, stale channels are archived at the source rather than copied, and private channels are placed with Microsoft's per-team limits in mind. The Slack export itself depends on your plan — Free and Pro plans export public channels only (and Free is limited to recent history), while private channels and direct messages require Business+ or Enterprise Grid and an application to Slack for the extended export — so we confirm what is exportable in week one, not on cutover day. Migration runs pilot-first: one team, verified message-by-message by its own owners, then waves. Where direct messages or group chats must come across, a third-party migration tool is used for that scope and named in the quote. Arrival matters as much as departure. A Slack workspace that sprawled will sprawl again in Teams unless lifecycle controls exist before people land — so this engagement switches on the governance baseline as part of the cutover: a naming convention, an expiration policy with owner renewal, guest-access settings, and the creation model you choose. If your existing Teams estate already has sprawl of its own, the deeper lifecycle implementation — sensitivity labels on teams, ownerless-team attestation, an archive-first cleanup wave — is our Microsoft Teams Governance and Sprawl Cleanup, and the two pair naturally. Adoption is handled as a plan, not a memo: a 'your Slack habits in Teams' guide, champion briefings, the announcement sequence, and a cutover day on which Slack goes read-only rather than dark. For teams that need structured training beyond the cutover kit, Microsoft Teams Adoption Training & Pilot continues the work. Two boundaries drawn up front. Slack workflows, bots and custom apps are inventoried and mapped to their Teams equivalents where a native option exists — but rebuilding a custom Slack app or a complex workflow as a Teams app is separate development work, scoped through Custom Microsoft Teams App Development. And while a clean, governed Teams estate is exactly the foundation Microsoft 365 Copilot needs, licensing, deploying and driving adoption of Copilot is its own program: Microsoft 365 Copilot Deployment and Adoption.
Success criteria
What you receive
How the work unfolds
Automated inventory of channels, members, files, apps and workflows; Microsoft 365 account matching; confirmation of what your Slack plan can export and, where needed, the application to Slack for private-channel and direct-message export. No user impact.
One working session with IT and the business owners of the busiest channels: which channels become which teams, what is archived at the source, private and shared channel placement, the naming convention, and the direct-message decision. Every mapping traces to a choice you made, with trade-offs on the table.
Slack export staged in Azure Blob Storage, admin consent granted, identity and channel mappings loaded, and one representative team migrated. Its owners verify messages, threads, reactions and files against the sampling checklist; defects are fixed before anything else moves.
Naming convention, expiration policy, guest-access settings and the team-creation model configured and tested; the announcement sequence, habits guide and champion briefing finalized with the pilot group's questions folded in.
Remaining channels migrated in waves with owner verification per team; direct-message scope executed via the third-party tool where agreed; announced cutover day with Slack switched to read-only and first-day support materials in place.
Final verification pass, defect log closed or assigned, decommission checklist and closeout report delivered, and the governance baseline handed over with the settings documented.
Prerequisites
Who does what
IT Partner
- Produce the inventory, the export readiness assessment and the team-and-channel design, and put every mapping decision in front of you with trade-offs.
- Prepare identity mappings and resolve unmapped accounts per your decision.
- Stage the export, configure and run Microsoft's migration tool pilot-first, and execute production waves with verification per team.
- Run the direct-message scope via the agreed third-party tool where included, and document fidelity before the run.
- Configure and test the Teams governance baseline before users land.
- Deliver the adoption kit and the cutover-day plan, and support the cutover window.
- Hand over the decommission checklist, the verification evidence and the closeout report.
Your team
- Provide the Slack export (or the export-role access to generate it) and, where required, submit the extended-export application to Slack.
- Make the design decisions in the workshop: team structure, archive-versus-migrate, direct messages, naming, cutover date.
- Ensure Microsoft 365 licenses and Entra ID accounts exist for every migrated user, and provide the Azure subscription and GDAP access requested.
- Assign channel owners to verify their migrated channels within the agreed window.
- Send the announcement sequence through your channel on the agreed schedule, and brief the champions.
- Keep Slack active and read-only through the agreed period, and own the Slack contract, its termination timing and any data-retention obligations.
What's not included
Limitations & technical notes
Frequently asked questions
Does Microsoft's native tool migrate everything from Slack?
No, and we would rather you hear that from us than discover it on cutover day. At the time of writing it migrates channel content: public and private channels, channel messages including threads and standard reactions, channel file attachments, canvases and lists (as file attachments), and channel membership. It does not migrate direct messages, group chats, Slack workflows or custom app integrations. For most organizations, channels are where the durable knowledge lives, so the native tool covers the bulk of the value at no license cost; the gaps are handled by decision — third-party tool, read-only Slack period, or deliberate retirement — not by surprise.
Can our direct messages come across?
Sometimes, and it takes three things: a Slack plan that permits exporting them (Business+ or Enterprise Grid — Free and Pro export public channels only), Slack's approval of the extended export, which it grants on a stated legal basis, and a third-party migration tool, because the native tool does not carry direct messages. That adds cost and time, and direct messages are personal by nature. Our honest experience is that many organizations choose a defined read-only Slack period instead, so people can look things up while the habit fades. We put both options, with costs, in front of you in the design workshop.
What Slack plan do we need to export our data?
Any plan can export public channel history. Free workspaces are limited to recent history, so what exists to export may be less than what was posted. Private channels and direct messages require Business+ or Enterprise Grid plus an application to Slack for the extended export — Enterprise Grid additionally exposes the Discovery API that third-party tools use. We confirm your position in week one, because an export limitation found late is the single most common reason a Slack migration slips.
Will messages show the right author and time in Teams?
Messages arrive under the Microsoft 365 account each Slack member is mapped to, which is why identity mapping is a deliverable rather than a checkbox — Microsoft provides a script to match Slack identities against Entra ID, and the tool accepts CSV mappings for scale. Accounts that cannot be mapped (departed staff, contractors, bots) need a decision before the run: map them to a designated account, or accept the placeholder attribution the tool applies. We record that decision, and the pilot verification shows you exactly how it looks before the production waves.
What happens to files that were shared in Slack channels?
Channel file attachments migrate with their messages and land in the Teams channel's SharePoint document library, so they open from the conversation the way they did in Slack. Two practical cautions: the files are retrieved during the run, which is why the Slack workspace stays active until verification is complete, and file volume is one of the factors we size in the quote. Files that were only ever in direct messages follow the direct-message decision.
Does our Slack workspace become one team in Teams?
Almost never, and it should not. A Slack workspace with a few hundred channels copied into one team is unusable and runs into Microsoft's per-team channel limits, especially for private channels. The design workshop groups channels into teams by department or function, archives stale channels at the source instead of migrating them, and places private and shared channels deliberately. Migrating less, on purpose, is how Teams ends up cleaner than the Slack it replaces.
What about our Slack apps, bots and workflows?
They are inventoried with an owner and a recommendation for each: many common integrations have a native Teams app or connector, Workflow Builder automations often map to Power Automate templates, and some are simply abandoned experiments nobody will miss. What has to be rebuilt — a custom Slack app, a complex multi-step workflow — is separate development work we scope through Custom Microsoft Teams App Development, with the inventory as the brief.
Is there downtime?
No. Slack and Teams coexist through the whole engagement; the migration reads from Slack and writes into Teams while both keep working. Cutover is a date, announced in advance, on which Slack switches to read-only rather than dark: people can still look things up, and read-only Slack is the rollback path in the days around cutover. The user-visible change is where new conversations happen, and the adoption kit exists to make that change land.
When can we safely cancel Slack?
After verification is complete, the read-only period you chose has run, retention exports are taken, and integrations that still point at Slack are rehomed — all of which is the decommission checklist. Cancelling before the migration is verified removes your rollback path and can remove access to files that have not yet been retrieved, so the checklist sequences it. Contract timing is yours to negotiate; we tell you when the technical conditions are met.
How is the price calculated?
$12 per user plus a $2,500 tenant fee, as an estimate that becomes a fixed written quote before work begins — you pay after you approve delivery. The tenant fee covers the inventory, the design workshop, the native-tool migration setup, the governance baseline and the adoption kit; the per-user component scales with the Slack members mapped into the migration. Direct-message scope via a third-party tool, multiple workspaces or Enterprise Grid organizations, and unusually large file volumes are priced in the quote rather than discovered mid-project.
Won't Teams end up as messy as Slack was?
Only if it lands ungoverned, which is why the governance baseline is part of the cutover, not a follow-up: a naming convention, an expiration policy that asks owners to renew, guest-access settings and a deliberate team-creation model are active before users arrive. The migration itself archives stale channels at the source instead of copying them. If your existing Teams estate already has sprawl — ownerless teams, forgotten guests — the deeper lifecycle implementation is our Microsoft Teams Governance and Sprawl Cleanup, and the two pair well.
We already use Teams for some things. Will the migration collide with what exists?
The design workshop starts from your current Teams estate, not from a blank tenant. Where a Slack channel has an obvious existing home, it is mapped into that team; where it does not, a new team is created under the naming convention. Nothing in the existing estate is deleted or restructured by this engagement, and channel owners verify their migrated content before it goes live for everyone.