How to Migrate from Slack to Mattermost Safely
Mattermost has official transformation and bulk-import tooling, but the real migration boundary is set by Slack export permissions, file availability, user identity, and workflows that do not move.
- Published
- 26 July 2026
- Reading time
- 13 min
- Evidence
- 4 primary sources
Treat it as an ETL project, not a chat export.
Define exactly which conversations and files Slack will let you export, validate the original ZIP, transform it with Mattermost’s mmetl tool, trial the bulk import on a fresh staging team, and rebuild integrations before a controlled final cutover.
- Export scope depends on Slack plan, role, approval, law, and retention.
- Standard Slack JSON exports contain file links, not the files themselves.
- Apps, workflows, canvases, profiles, and some thread relationships need manual work.
Resolve the Slack export boundary first.
A public-channel export and an all-conversations export are materially different migrations. Do not promise history that your plan, role, retention rules, or approvals cannot produce.
Record the Slack plan, workspace or Grid scope, retention settings, and authorized export owner.
List channels that must move, channels that may be archived, and history that may be left read-only.
Count active, deactivated, guest, external, and bot identities separately.
Inventory Slack Connect channels, apps, webhooks, slash commands, Workflow Builder flows, canvases, and user groups.
Decide whether files must be preserved as binaries, because ordinary JSON exports contain links rather than the files.
| Export | Usually includes | Primary limitation |
|---|---|---|
| Public channels | Public channels, messages, users, and file links | No private channels or direct messages |
| All conversations | Public and private channels, DMs, group DMs, users, and file links | Plan, owner access, approval, and legal conditions apply |
| Enterprise Grid | Organization or workspace data with multi-workspace complexity | Shared channels require explicit team mapping |
Build a disposable staging destination.
Mattermost recommends trial imports because large or complex workspaces usually need iteration. The first destination should be a place you can reset without damaging production.
- 01
Deploy a current supported Mattermost server.
Create the destination team before import and confirm database, file storage, email sign-in, user and channel limits, and the largest allowed attachment. For a large export, plan storage for the ZIP, unpacked content, transformed data, and import workspace.
PASS: Staging team and capacity settings ready. - 02
Back up before importing into anything valuable.
The cleanest path is a fresh installation. If the destination already matters, back up its database and data directory so a failed import can be rolled back.
PASS: Rollback tested or fresh staging confirmed. - 03
Choose the final identity source.
Decide whether users will activate by email/password reset or whether LDAP or SAML will become authoritative. Missing Slack email addresses become placeholder addresses that an administrator must resolve.
PASS: Identity and placeholder-email plan approved.
Keep the Slack ZIP original, then transform it.
The migration tools expect Slack’s directory structure. Preserve the original ZIP as evidence and recovery material.
- 01
Export and preserve the original ZIP.
Do not unzip and rezip the only copy. Slack and Mattermost both warn that altering the archive can break expected structure.
PASS: Original ZIP stored read-only with a second copy. - 02
Check the Slack archive with mmetl.
Run Mattermost’s documented Slack validation before transformation. Resolve structural errors before creating an import package.
PASS: mmetl check completes without unexplained errors. - 03
Transform into Mattermost bulk format.
Use the destination team name and create the JSONL plus data directory. Review the transformed user records for placeholder @example.com addresses before packaging.
PASS: JSONL, attachments, and identity exceptions reviewed. - 04
Validate the Mattermost import archive.
Package the JSONL and data directory together, then run mmctl import validate before upload and processing.
PASS: mmctl validation passes before server upload.
Test what matters—not just row counts.
An import job can complete while the migration is still unacceptable. Validate user identity, conversation shape, time, files, and search with named examples.
Open known public channels, private channels, one-to-one DMs, group DMs, and long threads that are inside the authorized export scope.
Confirm authors and original timestamps on old and recent messages.
Test reactions, pinned content, edited messages, attachments, and file links with concrete examples.
Search for known phrases from early, middle, and recent history.
Check active, deactivated, guest, external, and renamed users against the identity plan.
Review unread state and search indexing after the import job completes.
Record every unsupported item and its manual replacement owner.
Run a short, reversible cutover.
The final migration should differ from the successful rehearsal only by export time and approved scope.
- 01
Announce a Slack change freeze.
Publish the time after which new Slack messages, channel changes, and integration edits may not be included. Name the help channel and the fallback owner.
PASS: Freeze, support, and rollback messages sent. - 02
Repeat the tested pipeline.
Generate the final authorized export, preserve it, validate, transform, validate again, import, and reindex using the same versions and documented settings as rehearsal.
PASS: Final run matches the rehearsed runbook. - 03
Activate users and integrations.
Resolve placeholder emails, complete password or identity-provider activation, recreate critical apps and webhooks, and verify notification delivery.
PASS: Identity and critical workflow owners sign off. - 04
Keep Slack read-only during acceptance.
Do not immediately delete the workspace. Retain access according to policy while channel owners verify history and teams learn the replacement.
PASS: Acceptance window and final decommission owner set.
Continue with the product decision.
Confirm that Mattermost is the right trust and operating model before committing to the migration. Private Slack alternatives.
If files, meetings, and identity matter as much as chat, compare the wider collaboration-stack decision. Open-source Microsoft Teams alternatives.
Primary sources and review status.
Product interfaces and migration rules change. Check the linked documentation again before a destructive cutover.
The export boundary is the migration boundary.
Resolve Slack permissions and file availability first, rehearse Mattermost’s documented validation and import pipeline on a disposable environment, and cut over only after named examples—not just totals—pass review.
How we built this guide →