Moving from Slack to Teams (or back): what happens to message history?

What happens to message history when you switch?#

Message history in a Slack-to-Teams or Teams-to-Slack switch survives in three possible forms: migrated into the new tool, exported to an archive, or left in the old tool in read-only mode. Each keeps different context, and none keeps everything.

The products structure conversations differently. Slack organizes work into channels with threads, direct messages and channels shared across companies. Teams groups channels under teams, keeps one-to-one and group chats separately and relies on other Microsoft 365 services for files. A migration tool has to translate between those models, and translation loses detail.

Three options and what each loses#

The three options are not exclusive. Many companies migrate recent, active channels, archive the full original export and keep the old tool readable for a transition period, which is the fourth row below.

Direction matters: leaving Slack versus leaving Teams#

Direction matters because each product stores and exports history differently. Leaving Slack, the export you can take depends on your plan and role: Slack says exports of private channels and direct messages are offered only on Business+ and Enterprise, and Workspace Owners or Org Owners must apply to use them. On the free plan, Slack says messages and files more than one year old are permanently deleted, so that history is already gone.

Leaving Teams, Microsoft states that chat messages are stored in a hidden folder in the mailbox of each user in the chat, and channel messages in a similar hidden folder in a group mailbox, searched through eDiscovery rather than opened directly. Files sit separately in SharePoint and OneDrive, so conversations and file libraries are collected as two jobs. Microsoft Graph documentation says the Teams export APIs are no longer metered as of August 25, 2025.

Check each point against current vendor documentation before planning, since export features, admin roles and plan requirements change. Also confirm whether your migration tool reads from an export file or from live APIs, because live API access is governed by the vendor's terms.

Context that rarely survives a migration#

Context that rarely survives a migration is the part that explains how a conversation unfolded. A migrated message usually keeps its text and, depending on the tool, an author and a timestamp, but the surrounding signals thin out.

Some gaps also exist on the Teams side before any migration. Microsoft states that code snippets, voice memos recorded in the Teams mobile client, thumbnails, announcement images and emoticon reactions are not retained by Teams retention policies, so a compliance copy of Teams history is not a complete one either.

For everyday use much of this loss is acceptable. For a legal matter, an incident review or any later analysis of how decisions were made, it is exactly the context needed, which is why the original export has to be kept.

• 1Thread structure, flattened into a sequence of messages or a quoted block.
• 2Edits and deletions, which usually arrive only as final text.
• 3Reactions that signaled agreement or sign-off.
• 4Bot, workflow and integration messages from tools such as Jira, GitHub or PagerDuty.
• 5Original timestamps, which some tools preserve and others replace with the import time.
• 6Channel membership history: who joined, left or was invited.
• 7File links that point back to the old tool and break when it closes.
• 8Channels shared with other companies, which are partly theirs.

Identity mapping and departed employees#

Identity mapping decides whose name appears on each migrated message. Active users map by email to their new accounts; departed employees have no account in the destination, so their messages may be attributed to a placeholder, credited to the person running the migration or dropped, depending on the tool.

Build the mapping file before migrating, including deactivated users, and decide how former employees should appear. Keep the mapping with the archive. If a legal hold covers a departed employee, preserve that person's messages from the original export rather than relying on the migrated copy.

The order of operations for a switch#

The order of operations matters more than the choice of migration vendor, because most lost history is lost by doing steps out of sequence. The sequence below works in either direction.

Skipping the test step is the most common shortcut. A trial run on two or three busy channels shows, before cutover, exactly how threads, timestamps and authorship will look in the destination.

• 1Check legal holds and pause any retention change in the old tool.
• 2Take the fullest original export your plan and role allow, files included.
• 3Verify the export against channel and message counts, and have a second person open it.
• 4Build the identity map, including deactivated and departed users.
• 5Run a test migration on sample channels and review the result with the channel owners.
• 6Migrate the agreed scope, then keep the old tool read-only until the archive is signed off.
• 7Close the old subscription only after counsel and the archive owner confirm.

Illustrative: a telematics software company moves back to Slack#

Illustrative: a fictional fleet telematics software company moved from Slack to Teams after joining a larger software group, then returns to Slack when the group is restructured. Its engineering and support history is split across both tools: older work in a Slack export, recent work in Teams channels and chats.

The CTO decides not to migrate Teams history into Slack. IT exports Teams conversations, collects the SharePoint and OneDrive files behind them and stores them with the original Slack export in one indexed archive. Only a handful of active project channels are recreated in Slack, each with a pinned pointer to the archive.

The Teams tenant stays readable until the archive is verified and counsel confirms no hold requires the live system. The company ends up with one record of both eras, with threads and timestamps intact in the original exports.

How SourceX looks at chat history after a switch#

SourceX looks at chat history after a switch with provenance first: which system each record came from, whether it is an original export or a migrated copy, and what was lost on the way. Original exports are usually preferred because they keep threads, timestamps and authorship.

In the Rights step of the SourceX five-step transaction, DMs, HR channels and channels shared with other companies are typically excluded, and the Preparation step removes personal and confidential details from engineering and support conversations. The SourceX Evidence Packet records the provenance chain, including each migration, so the supplier and the buyer see the same account of where the records came from.