Migrate from Slack to Mattermost

How to migrate from Slack to Mattermost without losing the history that matters

If your Slack renewal, licensing change or data residency concern is pushing you toward self-hosted chat, the Mattermost migration is documented as a Slack export converted with mmetl and loaded with mmctl. How much history you keep and how much rework follows depend mostly on three things: which Slack plan you export under, which integrations your teams rely on, and how far back the history you need actually goes. Start by deciding which of these you will accept losing before anyone runs an export. The export plan is the first gate. Every Slack plan can export messages and file links from public channels, but private channels and direct messages require a Business+ or Enterprise plan, and custom exports by member or conversation are limited to Enterprise. On a Free workspace, content older than one year is permanently deleted, so history you assume exists may already be gone. Confirm with the Slack workspace owner which export type was approved, then ask whether direct messages were included, because those are often the records a legal or HR team later needs. Plan for file links rather than files where the export only includes links, and decide whether attachments must be fetched separately. In practice, an internal platform team usually owns the migration, with an implementation partner handling the mmetl mapping, the import runs and the verification. Integrations, custom emoji images, user groups and Slack Connect channels do not move, so inventory them before cutover and assign an owner to rebuild each one. Effort and risk rise with the number of channels, the volume of attachments and the number of bots, and they fall when a test import into a staging Mattermost server confirms user matching and channel layout first. Ask any partner for a written scope that names the export plan, the staging run, the verification checks and the rebuild list, and do not agree to a timeline until those are documented.

Which Slack capabilities map to Mattermost, and which need rework

This table compares common Slack capabilities with their Mattermost equivalents and marks each row as clean, needs rework or gap. Use it to scope the migration before export, since the rework column tells you what your team must rebuild by hand. Confirm each row against your own workspace, because the plan and edition you choose decide several of the answers.

Slack capability	Mattermost equivalent	Migration note
Public channels	Public channels, imported through mmetl and mmctl	Clean. Channel names and membership move with the bulk import, so confirm name collisions before cutover.
Private channels	Private channels, imported when the export includes them	Needs rework. Slack exports private channels only on Business+ or Enterprise, so the export plan decides whether they come across.
Direct messages	Direct messages, imported when the export includes them	Needs rework. DMs also depend on the Slack export plan, so confirm access before you promise history to users.
Threads and replies	Threads, imported with the bulk import format	Clean. Confirm a sample thread after import, since reply order and edits should be checked on a test workspace first.
File attachments	Attachments uploaded during import	Needs rework. Confirm that the export contains the files themselves, because Slack Free and some plans provide file links only.
User accounts	Users created from the Slack export	Needs rework. Accounts move, but passwords do not, so plan how users log in on day one.
User groups	No documented import path	Gap. Recreate user groups in Mattermost and reassign channel membership by hand or with mmctl scripts.
Integrations and apps	Rebuilt as Mattermost integrations and bots	Gap. Integrations do not migrate, so inventory each app and recreate its webhooks or commands before cutover.
Custom emoji	Emoji must be re-uploaded	Gap. Custom emoji images do not move, so export the image files from Slack and upload them again.
Slack Connect channels	No equivalent in the import path	Gap. Shared channels with outside organizations do not migrate, so plan guest accounts or a separate federation approach.
SSO and SCIM-style provisioning	SSO (SAML, OIDC, OAuth) and AD/LDAP sync	Needs rework. These sit in paid Professional and higher plans, so Team Edition does not cover SSO-based provisioning.
Huddles	Mattermost Calls with the rtcd service, or another calls product	Gap. Calls are a separate component to deploy and size, so confirm media and TURN requirements before promising parity.

What data moves from a Slack export and what must be rebuilt

A Slack export decides what can reach Mattermost before any conversion starts. The cards below follow the path from the export plan through mmetl and mmctl to the items that never leave Slack, so you can inventory what must be rebuilt before cutover.

Export plan sets the scope

Every Slack plan can export public channels, but private channels and direct messages need a Business+ or Enterprise workspace and an approved export request. Custom exports by member or conversation are Enterprise-only. If your Slack workspace is on a lower plan, confirm the export scope with the workspace owner before planning the cutover, because a public-only export leaves private history behind.

Free plan deletion deadline

Slack Free keeps 90 days of message and file history, and content older than one year on Free workspaces is permanently deleted. If your workspace is on Free, start the export early, because history that has aged out cannot be recovered from Slack. Record the export date so you know which period your Mattermost archive covers.

mmetl converts the export

Mattermost's mmetl tool converts the Slack export into Mattermost's bulk import format. Run the conversion on a copy of the export, review the generated import file, and keep the original zip unchanged. Conversion errors, such as malformed channel names or unreadable message files, are easiest to fix before the load step.

mmctl loads users and history

The converted bulk file is loaded with mmctl, which creates users, channels, direct messages, threads and attachments on the target server. Test the load on a staging server first and compare channel counts and message totals against the Slack export. Plan the identity step with it: each Slack member must map to a Mattermost account, usually through matching email addresses, before messages can be attributed correctly.

Integrations and apps stay behind

Slack apps, bots, slash commands and incoming webhooks do not come across in the export. Each one needs to be inventoried from your Slack admin pages and rebuilt on Mattermost with its own endpoint, token and permissions. Assign an owner to each integration before cutover, because a message from a silent bot is only noticed after a process fails.

Emoji, groups and Slack Connect

Custom emoji images, user groups and Slack Connect channels do not move. Export the emoji list and images separately so you can re-upload them, record each user group and its members so you can recreate teams or channel membership, and list every Slack Connect channel with its external partners. Partner channels will need a different approach, such as guest accounts or a federation model, agreed with each external organization.

Migration sequence from inventory to Slack decommission

This sequence moves a Slack workspace into a self-hosted Mattermost server in controlled stages, so each stage produces evidence that the next one can rely on before Slack is switched off.

Inventory channels, members, integrations and retention needs
The workspace owner and a Slack admin list public and private channels, direct message groups, active members, guests, installed apps and webhooks, user groups, and any retention or legal hold obligations for the data. Compliance and legal stakeholders sign off on which history must be kept and for how long. The output is a written inventory that maps each channel to an owner, a business purpose and a retention decision, plus a list of integrations that will need rebuilding on Mattermost.
Confirm the export plan and request private channel access
Check the Slack plan on the workspace before relying on any export. Every plan can export public channel messages, but private channels and direct messages require Business+ or Enterprise, and custom exports by member or conversation are Enterprise-only. If the plan does not cover what the inventory requires, the workspace owner submits the export request through Slack and records the approval. The output is a confirmed export scope, with a note for each channel type stating whether it is included, and an approval reference for private data.
Run mmetl conversion on a copy of the export
Keep the original Slack export untouched and run the Mattermost migration tool, mmetl, against a copy. The tool converts the Slack export into Mattermost's bulk import format. Review the generated file for user mapping, channel names, thread structure and attachment references. Record any conversion errors and decide whether each affected item is fixed in the source, excluded, or handled manually. The output is a converted import file and a conversion log that the team can review line by line.
Pilot the import into a staging server on PostgreSQL
Install a staging Mattermost server backed by PostgreSQL, using the same Mattermost version planned for production. Load the converted file with mmctl and check a representative set of channels, direct messages, threads and attachments against the source export. Confirm that users, channels and message counts match the inventory. Test sign-in for a sample of users and confirm that integrations and custom emoji are known gaps that need a documented workaround. The output is a signed-off pilot report listing matches, mismatches and accepted gaps.
Run a parallel period with announced channel mapping
Publish a channel mapping that shows each Slack channel, its Mattermost destination, and the date each team will start using the new server for new messages. Keep Slack open for reading while teams post in Mattermost. Track adoption, open issues and any integration that stops working, and fix them in staging before the cutover. The output is a final mapping, a list of resolved issues, and an agreed freeze point for Slack message history.
Cut over with mmctl import and onboard users
Run the final import with mmctl against the production Mattermost server after the freeze point, then verify counts and sample threads against the source. Send onboarding instructions to every user, including how to sign in and where channels now live. Rebuild the priority integrations, slash commands and bots that were inventoried earlier. The output is a production import record, a verified checklist, and confirmed sign-in for the active user base.
Decommission Slack after verification
Once the team confirms the production data, has the archive it needs for retention, and no open cutover issues remain, the workspace owner schedules Slack decommission. Retain the original export and the conversion and import logs under the retention decision from step one, then remove Slack access for users and disable integrations that still point to it. The output is a closed Slack workspace, a stored archive with its retention record, and a final sign-off from the compliance owner.

How the migration changes by team size and starting point

A small team on Slack Free has the most urgent timeline, because Slack keeps 90 days of message and file history on Free workspaces and states that content older than one year is permanently deleted. Export before that history disappears, and treat the Slack export as the only copy of older conversations that you can count on. Public channel exports are available on every plan, so the first step is to confirm what you can actually pull.

Export now: Run the workspace export while older public channel history is still available, and record the date you took it.
Accept the Team Edition limit: Mattermost Team Edition is free, self-hosted and MIT-licensed, aimed at teams under 250 users that do not need single sign-on.
Plan for paid features later: SSO and AD/LDAP sync are in paid Mattermost plans, so a team that later needs them will pay for an upgrade.
Check file links: Free exports carry file links rather than the files themselves, so confirm which attachments you need to retrieve.

Confirm your user count and whether you need single sign-on before choosing an edition.

What drives migration cost and duration, and how to keep each down

This table lists the factors that change the cost and length of a Slack to Mattermost move, with the reason each one matters and how to shrink it. Read it before requesting a quote, because most of the variable cost sits in export approval, identity mapping and the edition you choose. Cost splits into a one-time migration effort and recurring hosting, licensing and overlap subscriptions.

Driver	Why it changes cost or effort	How to keep it down
Export plan and approval lead time	Private channels and DMs need a Business+ or Enterprise export, and Slack reviews the request. Without it, those conversations cannot be migrated and the scope shrinks or stalls.	Confirm the plan and submit the approval request at the start. Ask your Slack admin who must approve it and how long Slack takes.
Number of private channels and DMs	Each private conversation needs review for access rules, and DMs need a mapping decision. Large volumes add conversion and validation time.	Agree in writing which private channels and DMs are in scope. Archive stale ones before export rather than migrating them.
Integration count	Integrations do not move. Each Slack app, bot, slash command or webhook must be inventoried and rebuilt on Mattermost, which is recurring engineering work.	Export an inventory of installed apps and webhooks before cutover. Retire unused ones and rebuild only the rest.
Attachment volume	The export carries file links rather than all files in every case, so attachments need separate retrieval and storage. Storage and transfer time grow with volume.	Measure total attachment size per channel. Decide which files to keep, and plan storage capacity on the Mattermost side before import.
Identity mapping	Users must be matched between Slack accounts and Mattermost accounts, including email addresses and deactivated users. Errors create duplicate or orphaned accounts.	Compare the Slack user list with your identity directory first. Ask whether SSO or AD/LDAP sync is needed, since those are paid Mattermost features.
Mattermost edition and high availability needs	Team Edition is free but has no SSO or clustering. SSO and AD/LDAP sync start at Professional, and high availability requires Enterprise or Enterprise Advanced, which adds recurring seat licensing.	Match the edition to the features you need on day one. Ask for a written quote for each edition that lists the seat count and renewal terms.
Shared storage and database replicas for clusters	A high availability cluster needs shared file storage on S3, an S3-compatible service or NAS on every node, and local storage will not work correctly. Read replicas add database infrastructure to run and monitor.	Reuse existing object storage if it is available to all nodes. Ask the vendor or partner to confirm the sizing for your user count before buying hardware.
Parallel-run length	Running Slack and Mattermost side by side keeps the Slack subscription active and doubles support load. Every extra week of overlap adds recurring Slack cost and admin attention.	Set a fixed cutover date and a short overlap window. Confirm your Slack plan end date and whether seats can be reduced during overlap.

What usually goes wrong in a Slack to Mattermost migration

Most failed Slack to Mattermost migrations fail on timing, identity or infrastructure rather than on the import tool itself. The cards below cover the decisions and checks that connect export planning, cutover and the clustered server, so each risk has a named prevention step before work starts.

Export requested too late

Slack's export rules depend on plan. Every plan can export public channels, but private channels and direct messages need an approved Business+ or Enterprise export request, and that approval is not instant. Confirm with the workspace owner which plan you are on and submit the request in the first week of scoping. Without private channels and DMs, the migrated history has visible gaps that users will notice on day one.

Free history already deleted

On Slack's Free plan, content older than one year is permanently deleted, and visible history is limited to 90 days. If the workspace is on Free, messages that matter to the business may already be gone before the migration starts. Check the oldest surviving message in each key channel, record what is missing, and tell stakeholders before the export so the gap is a known scope item rather than a surprise.

Integrations assumed to carry over

The Slack import converts users, channels, direct messages, threads and attachments. It does not move integrations, so bots, slash commands and app-driven notifications stop working on the day of cutover. Build an inventory of every Slack app and webhook from the workspace settings, assign an owner to each one, and rebuild them on Mattermost before the freeze so that alerts and approvals keep flowing.

User groups lost

Slack user groups used for mentions, on-call rotations and access to channels do not come across in the import. Teams that rely on @-mentions of a group will find those mentions silently fail. Export the group membership lists before the migration, map each group to a Mattermost team or channel membership, and decide whether the group will be recreated manually or through your identity provider sync.

Unmapped identities create duplicate accounts

If a person's email address in Slack does not match the identity they use in Mattermost, the import can create a second account for the same person. Their history then appears under two users and mentions point to the wrong one. Compare the Slack user list with the directory before import, resolve mismatched or deactivated accounts, and decide the single source of identity for login, including whether SSO is needed, which Mattermost places in paid editions.

Local disk file storage in a cluster

A high availability Mattermost cluster needs shared file storage on Amazon S3, an S3-compatible service or a NAS mounted on each node. Local file system storage does not work correctly in a cluster and risks corrupting files, which is exactly where imported attachments land. Confirm the storage target before the import runs, test an attachment download from every application node, and treat the storage configuration as a precondition rather than a post-cutover task.

Questions buyers ask before moving Slack to Mattermost

How much effort and cost should we expect for a Slack to Mattermost move?

The effort depends on a few drivers rather than a fixed figure: how much history you need to keep, whether private channels and direct messages must come across, how many users, channels and attachments the export contains, and how many integrations you must rebuild. Costs fall into one-time work (export, conversion with mmetl, import with mmctl, testing, user communication, rebuilding integrations) and recurring work (hosting, database and file storage, upgrades, backups and admin time). Mattermost Team Edition is free to download and run, but SSO, AD/LDAP sync, clustering and compliance export sit in paid plans, so those licenses belong in the quote. Ask any implementation partner for a written scope that lists each driver and its assumptions.

How long does a Slack to Mattermost migration take?

The timeline is set mainly by two things: how long your Slack admins take to approve and receive the export, and how much data the export holds. Slack states that every plan can export public channel messages, but private channels and direct messages need an approved Business+ or Enterprise export, and custom exports by member or conversation are Enterprise-only, so the approval step can be the longest wait. Volume then affects conversion, import testing and validation. Plan separate phases for approval, a test import into a staging server, user review, and the final cutover. Ask your team to confirm the export scope in writing before any clock starts.

Can our internal team run a Slack to Mattermost migration alone?

Often yes, if you have someone comfortable with Linux, PostgreSQL, command-line tools and Mattermost administration. The core steps use mmetl to convert the Slack export into Mattermost's bulk import format and mmctl to load it, and Mattermost documents that path. The harder parts are rarely the import itself: they are agreeing on the export scope, deciding what to do with integrations, user groups and Slack Connect channels that do not move, setting up identity and file storage, and running a server your team will support after cutover. If the team lacks capacity or experience in one of these areas, a fixed-scope engagement can cover the gap. Confirm the internal skills gap before deciding.

What do we need from Slack admins and identity owners?

Slack admins need to decide the export plan, confirm who may approve private channel and direct message exports, and confirm which workspace data and file links the export should include. Slack Free workspaces also have history limits, so admins should check the retention window before requesting anything. Identity owners need to define how users sign in to Mattermost, whether through SSO with SAML or OIDC, AD/LDAP sync, or local accounts. Those options are paid features on Mattermost, so the decision affects the license choice. Both groups should agree on user matching by email address, handling of deactivated accounts, and who signs off on the final user list before import.

Can we keep Slack Connect channels and Slack integrations after moving to Mattermost?

No, not as they are. Mattermost's documented Slack migration path moves users, channels, direct messages, threads and attachments, but integrations, custom emoji images, user groups and Slack Connect channels do not come across. Slack Connect shared channels depend on Slack's cross-organization model, so you need a replacement plan for each external partner, such as guest accounts or a separate federation approach, each with its own review. Integrations must be inventoried and rebuilt on Mattermost, using webhooks, slash commands or bots, and tested before cutover. Treat the rebuild as a separate workstream with its own owner and acceptance tests.

Is Mattermost Team Edition enough to replace Slack?

Team Edition is free, open source and self-hosted, and it is aimed at teams under 250 users that do not need single sign-on. If your organization needs SSO, AD/LDAP sync, high availability clustering or compliance export, Team Edition will not cover those needs, and you must check the paid tiers. Mattermost Entry, the free tier of the commercial build, has a 10,000 message history cap and lacks compliance features and high availability. Confirm the user count, identity requirements, retention and audit needs, and uptime expectations against the editions documentation before you choose a license.

When should we bring in an implementation partner for Mattermost?

Bring in a partner when the migration depends on work your team has not done before, or when the scope carries regulatory or operational risk. Common triggers include a regulated environment needing audit-ready controls and evidence, a need for high availability with shared file storage on S3, an S3-compatible service or NAS, air-gapped deployment, or a large number of integrations to rebuild. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not publish prices, so ask for a quote built from your written scope.

How to run Slack and Mattermost in parallel before cutover

Run Slack and Mattermost side by side for a bounded pilot before any company-wide move. Pick two or three low-risk channels, such as an engineering team channel or a project room, and invite a small group of named users to a Mattermost team on your own server. The Slack export is a snapshot: it contains history up to the moment you ran it, so every message posted in Slack afterward needs either a second export or manual handling. Decide that now, because it determines how much of the pilot period you can keep in sync and how long you keep Slack open.

Announce a read-only Slack period with a date, and agree it with the Slack workspace owner and the people who administer it. During that window, move new discussion to Mattermost, post a pinned message in each Slack channel pointing to its Mattermost counterpart, and confirm that the channel is not being used for decisions. Keep the exported Slack archive as a separate, access-controlled record, because Slack's own retention limits on lower plans mean the archive may be your only complete copy. Confirm with Slack which plan your workspace is on and what it can export, since private channels and direct messages depend on it, as described in the Slack export guidance.

Plan for re-learning as well as migration. Users will lose Slack-specific habits such as its emoji reactions set, huddles, Workflow Builder steps and Slack Connect shared channels, and they will find that bots and slash commands need to be rebuilt before they behave the same way. Give each pilot group a short guide covering Mattermost notifications, where threads appear, and how to find old history in the archive. Track the open questions from the pilot, such as which integrations still need work, and only widen the cutover once those are resolved and the Slack read-only date is confirmed.

How DeployOpen scopes and runs a Slack to Mattermost migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Slack to Mattermost, we start with a written scope that covers your export plan, your user and channel inventory and your Mattermost deployment, then carry the migration through to a documented handover.

How we scope

Confirm which Slack plan produced the export and whether private channels and direct messages are included.
Inventory channels, users, integrations, user groups and Slack Connect channels that will not move automatically.
Agree in writing which Mattermost edition, hosting location and database setup the migration targets.

How we build

Convert the Slack export with mmetl and test the bulk import on a non-production Mattermost server first.
Load the data with mmctl, then check user, channel, thread and attachment counts against the source export.
Rebuild the integrations and user groups that did not transfer, based on the inventory agreed during scoping.

How we hand over

Deliver documentation of the import steps, mapping decisions, known gaps and the rollback procedure.
Walk your administrators through user provisioning, channel ownership and the cutover checklist before go-live.
Provide a record of what was migrated, what was rebuilt and what remains manual, for your own audit files.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan Mattermost server upgrades around the monthly release schedule and the published support end dates.
Confirm with your vendor which features need paid editions before you rely on them in production.