Mattermost migration from Slack and other platforms

What a Mattermost migration involves

A Mattermost migration moves the conversation record: channels, messages, users, files, team and channel membership, and channel structure. It does not move integrations. The Slack export does not include them, so apps, slash commands, webhooks and bots must be rebuilt or replaced in Mattermost and tested separately. Before scoping, list every Slack app your teams rely on, who owns it, and what it posts or reads. That list often changes the plan more than the message history does.

Most projects start from a trigger rather than a technical goal. Common ones include a Slack contract approaching its end, rising per-seat cost, a data residency requirement that the current service cannot meet, or a decision to consolidate several chat tools into one. The trigger shapes the deadline and the acceptable cutover window. A residency or consolidation driver usually means every workspace and channel must be accounted for, while a contract deadline often forces a fixed date that the import plan has to fit around.

The documented Slack path has three stages. You export the workspace from Slack, transform that export with the mmetl tool into a bulk import JSONL file plus an attachments set, then upload and process the result with mmctl. Each stage has its own failure modes, such as unmapped users, attachments that did not come through the export, or timestamps and threading that need checking after processing. Mattermost also documents migration paths from Rocket.Chat and GitLab Omnibus. Those paths are separate and need their own checks against the source system before you rely on them.

The short answer: a team with Linux server administration and scripting experience can run a small test import in-house, using a non-production Mattermost server and a limited set of channels. Most organizations bring in a partner for the full history, which brings volume, identity mapping across SSO and email, validation of message counts and files, and a planned cutover. Confirm the current export format, mmetl and mmctl versions, and any Slack plan limits with the vendor before you start.

What the work includes

The migration is delivered as a set of workstreams, each with a written deliverable. Scope, deliverables and timelines are agreed in writing before work starts, so the list below can be checked against your own source platform and retention needs.

Source inventory and data scope

We inventory workspaces, channels, users, guests, deactivated accounts and file attachments in the source platform, with counts per category. This shows which data exists, what volume must be moved, and which records need special handling before any decision about what to keep is made.

Retention and what-to-move decision

You decide, with our input, which channels, history periods, guests and archived content move into Mattermost and which stay behind in the source system. The decision is recorded in the scope document so the import and the validation checks follow the same rules.

User and identity mapping file

We build the mapping that links source accounts to Mattermost users by email and username, including guests and deactivated accounts. Mismatches are listed for your review, because wrong mappings cause messages to post under the wrong identity or fail to import.

mmetl transformation and import package

We export from the source, transform the data with mmetl into a bulk import JSONL file with attachments, and prepare the package for upload with mmctl. Each run is repeatable, so the same transformation can be rerun after a source correction without manual editing.

Rehearsal imports into staging

We run full rehearsal imports into a staging Mattermost server that matches the production configuration as closely as possible. Each rehearsal shows processing time, failed records and storage use, which lets you plan the production window from observed results rather than estimates.

Validation reports

After each rehearsal we produce a validation report that compares channel, message, user and file counts against the source inventory and lists exceptions with their causes. You review the report and sign off each exception, so open issues are visible before cutover.

Integration inventory and rebuild plan

Integrations, bots, webhooks and slash commands do not transfer from Slack exports, so we list each one, its owner and its purpose, then plan how it will be rebuilt or retired in Mattermost. This is often the largest source of post-cutover work, so the inventory is reviewed early.

Cutover runbook

We write the step-by-step cutover runbook covering source freeze, final export, import, validation, user communication, rollback criteria and the decision points where go or no-go is taken. Your operations team rehearses it against staging before the production date.

Hand-over of scripts and records

At close we hand over the transformation scripts, mapping files, rehearsal logs and the validation record, along with the runbook as it was executed. Your team keeps everything needed to rerun or audit the migration without depending on our staff.

What drives cost and duration

Each row names one driver of Mattermost migration effort, why it adds work, and what the client can do before the partner starts to keep it under control.

Driver	Why it raises effort	How to keep it down
Volume of message history and attachments	Every message, file and thread is transformed, uploaded and processed, and large attachment sets take longer to move and verify.	Agree a retention cut-off with the business, archive old history outside the migration scope, and confirm the total size of attachments before scoping.
Number of source workspaces or instances	Each Slack workspace or Rocket.Chat or GitLab Omnibus instance needs its own export, transformation and mapping, and merged workspaces create naming conflicts.	Consolidate or retire source workspaces before export, and decide which instance is the system of record.
Identity mapping complexity	Mattermost users must be matched to people in the target directory. Email mismatches, duplicate accounts, guests and deactivated users each need a decision before import.	Clean the directory before mapping, agree rules for guests and deactivated accounts, and confirm which email address is authoritative for each person.
Channel structure	Private channels, archived channels, direct messages and group messages each have different membership and visibility rules that must be reproduced correctly.	Decide which archived channels migrate, document membership for private channels, and confirm who owns group message history.
Integrations to rebuild	Slack integrations, bots and apps are not included in the export and cannot be migrated, so each one must be rebuilt, replaced or retired in Mattermost.	Inventory every integration in use, rank them by business need, and approve a retire-or-rebuild decision for each before cutover planning.
Source platform and version	Slack, Rocket.Chat and GitLab Omnibus each have different export formats and version-specific behavior, so the transformation path and checks change with each source.	Record the exact source platform and version, and confirm which export options the owner can enable before the project starts.
Number of rehearsal runs	Each test import reveals mapping, attachment or permission issues that must be fixed and re-tested, so repeated runs add time to the schedule.	Agree the rehearsal count and acceptance criteria up front, and have business owners sign off sample channels between runs.
Retention or legal hold obligations	Records that must be preserved, or that are under legal hold, may need extra export, verification and chain-of-custody steps.	Ask legal and records teams for written requirements before export, and identify any holds that apply to Slack data.
Compliance evidence needs	Assessors may expect proof of what was migrated, what was excluded and who approved the decisions, which means logs and reconciliation reports.	Define the evidence list early, such as import logs, record counts and approval records, and store them with the project files.
Sign-in method for users	Migrated users must authenticate against the chosen identity provider, so provisioning and sign-in design affects account mapping and cutover.	Plan sign-in separately using the Mattermost SSO and identity integration topic before the directory is cleaned for migration.

Migration phases and outputs

The sequence moves history, users and files out of the old tool in a controlled order, with a named output at each phase so each handover can be checked.

Inventory the source workspace
Map workspaces, channels, private conversations, users, guest accounts, file attachments and installed integrations in the source tool. The team producing this should be the same people who own the source workspace, so gaps are caught early. The output is an inventory report listing volumes and owners, plus a list of integrations that will not transfer and need replacements.
Decide history scope and retention
Agree which channels, date ranges and file types move, and which stay in the old tool as read-only archive. Compliance, legal hold and data retention obligations drive these decisions, so involve your records and security owners. The output is a signed scope decision record that names exclusions, retention periods and who approved them.
Map identities and channels
Build the user mapping from source accounts to Mattermost accounts, including email matching, deactivated users and bots, and the channel mapping for team and channel names. Confirm how identities will be provisioned before import, because Mattermost SSO and directory sync decide which accounts exist. The output is a reviewed mapping file that the transform step will read.
Build the transform pipeline
Convert the source export into the Mattermost bulk import format using the mmetl tool, producing a JSONL import file and an attachments set. Run the transform on a copy of the export so the source data stays unchanged. The output is a versioned import package with the transform settings, mapping file and a log of skipped or unmapped items.
Rehearse the import on non-production
Load the import package into a non-production Mattermost instance using mmctl bulk import tooling, on a server configured like the target. Record run time, errors, failed attachments and any users that did not resolve. The output is a rehearsal log and a defect list, and the import is repeated until the defect list is empty or each remaining item is accepted in writing.
Validate against sample data
Check a sample of channels, threads, reactions, edits, files and user memberships against the source, and run permission checks for private channels and guests. Compare counts from the inventory with the imported totals. The output is a validation report signed by a business owner for each team, with each failed check linked to a fix or an accepted exception.
Run cutover with freeze and final delta
Freeze posting in the source tool, run a final incremental export and import for messages created after the rehearsal snapshot, then switch users to the new server. The cutover runbook lists the freeze window, rollback point, owner for each action and the go or no-go criteria, and is rehearsed before the event. The output is a completed cutover log and confirmed user access.
Hypercare and decommission the old tool
Watch support queues, login failures, missing history and integration replacements for an agreed period after cutover. Once the source is no longer needed, archive the export and shut the old tool down according to the retention decision from the scope step. The output is a closure report listing open defects, the archive location and the decommissioning sign-off.

What to keep in-house and what to outsource

This table shows who usually owns each migration step, the skills it needs, and whether an internal team, a partner or both should cover it, with business owners signing off on validation and retention decisions.

Migration part	Skills required	Usually covered by	Notes for the decision
Retention and business decisions	Data and records management, business owner review	Internal team (business owners and records or legal staff)	Business owners decide what history moves and what stays archived. A partner can document options but should not own these calls.
Directory cleanup and identity mapping	Slack or source platform admin access, Linux and PostgreSQL administration, data management	Both (internal identity team with partner scripting support)	Map source accounts to Mattermost users and SSO identities. Confirm which deactivated or guest accounts need to move.
mmetl transformation and scripting	JSON and scripting, Slack or source platform admin access	Partner, with internal review	Transformation converts the export into a bulk import JSONL file plus attachments. Internal staff should review mapping output before import.
Rehearsal imports and mmctl runs	Linux and PostgreSQL administration, JSON and scripting	Both (partner runs rehearsals, internal team owns target environment)	Repeat rehearsal imports on a non-production instance to measure timing and catch failures before the production run.
Validation sampling	Data and records management, business owner review, Slack or source platform admin access	Both, with business owners signing off	Channel, message, user and file samples must be checked against the source. Business owners approve the sample and the acceptance result.
Integration rebuild	Slack or source platform admin access, JSON and scripting, Linux administration	Internal team (integration owners), with partner help on webhooks and bots	Slack integrations are not included in the export and cannot be migrated, so each one must be rebuilt or retired.
User communications and cutover	Business owner review, data management	Internal team (leadership and communications), with partner cutover runbook	Announce the change, explain what does not transfer and set the freeze window. Owners approve the cutover go or no-go.
Post-cutover decommissioning	Slack or source platform admin access, data management, business owner review	Internal team, with business owner sign-off	Disable the source workspace only after validation and retention sign-off. Confirm export archives are stored under the retention policy.

What usually goes wrong

Each risk below has a prevention step to complete before the cutover. Most of them are easier to fix in a rehearsal import than after people start posting in Mattermost.

Integrations assumed to transfer

Slack integrations, bots, slash commands and app connections are not included in the Slack export and cannot be migrated into Mattermost. Teams often assume they carry over and find out after cutover. Before the cutover, inventory every integration and webhook in use, record its owner and purpose, and plan a Mattermost replacement or reconnection for each one.

Account and private channel mismatches

Users whose Slack email addresses differ from their identity provider addresses can end up as duplicate accounts, and mentions, message ownership and private channel membership then point at the wrong person. Compare the exported user list with the identity directory, choose one canonical address per person, and confirm that each private channel's members map to the correct accounts before import.

Missing or oversized attachments

Files are the largest part of most workspace histories and the most likely to be incomplete. Attachments can be absent from the export, exceed the file size limit set on the target server, or point to links that no longer resolve. Check the export against a sample of channels, confirm the server file limits and storage capacity, and decide which older files will be archived outside the chat.

Threads and timestamps that shift

Replies, thread structure, edited messages and timestamps can display differently after import, which makes historical context hard to follow. Time zone settings can also change how dates appear to each user. Import a sample channel with long threads and check reply order, authorship, edits and dates for users in each time zone before the full load.

Split conversations and retention during cutover

In a long cutover, some teams keep posting in Slack while others move to Mattermost, so decisions and history fragment across two systems. Retention settings on the target can also delete imported history on a schedule nobody reviewed. Set a source freeze date, announce it in advance, and review Mattermost retention policies before any content is imported.

Skipping rehearsal imports

Teams that load the full export once, directly into production, find mapping errors only after people rely on the system. A rehearsal import into a staging server exposes problems with users, channels, files and timing while they are still easier to correct. Run at least one full rehearsal with a production-sized export, compare the results against a written checklist, and repeat after each fix.

How the work differs by source

Slack is the source with the most documented path. Mattermost documents a sequence of export from Slack, transformation with the mmetl tool into a bulk import JSONL file plus attachments, and then upload and processing with mmctl. Plan around these points:

Export: Confirm with your Slack plan and workspace owner which history, channels, direct messages and files the export will include before you agree on scope.
mmetl transformation: Map Slack users, channels and teams to Mattermost users, teams and channels, and decide how to handle deactivated accounts and renamed channels.
JSONL and attachments: The import file and the attachment folder must stay in step. Check file references after each test run.
Integration gap: Integrations are not included in the Slack export and cannot be migrated. Inventory every app, bot and webhook your teams use and plan how each one will be rebuilt or retired.
Confirm: Verify the current mmetl and mmctl steps and supported versions with Mattermost before you plan.

What the client needs to provide

The migration team cannot start extraction or mapping until the client supplies a short list of access, decisions and environments. Admin access or export rights to the source workspace come first. For Slack, that means an owner or admin who can run the workspace export and who knows which channels, private channels and direct messages are covered by it. Without this, the team works from partial data, and the gaps surface only after users have started to work in Mattermost.

A named business owner for each team and channel group is needed to decide which channels become teams, which are archived, and which are merged. Without owners, mapping decisions default to whoever answers first, and archived channels that people still rely on are discovered after cutover. The client should also supply the identity directory and email conventions, such as how usernames are formed from email addresses. Mismatched conventions produce duplicate accounts or messages attributed to the wrong person.

Decide which history and files move and for how long. Full history is not always the goal. Many organizations move a fixed window of messages and attachments, then keep the rest in an archive. Each choice changes file volume, import time and the storage sizing discussed in the implementation plan. The retention and legal hold position must be written down before import, since imported messages are subject to the same obligations as native ones, and any hold that applies to a source channel must be honored during export.

Provide a staging Mattermost with a PostgreSQL database and file storage already running, so imports can be rehearsed against the target version and settings. Without a rehearsal environment, the first real run becomes the test, and problems with user mapping or file paths appear in production. Finally, agree an approved cutover window and name the communication owners who will tell users when the source workspace goes read-only, when Mattermost opens, and where to ask for help. Integrations do not transfer from Slack, so the client should also list the bots and webhooks that must be rebuilt before that window.

Frequently asked questions

How much does a Mattermost migration from Slack cost?

The cost follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of workspaces, channels and users in the export, how much message history and how many files are in scope, whether Slack integrations must be rebuilt, the target deployment and its PostgreSQL and file storage, and how many test imports and validation rounds the work includes. Most of this effort is one-time. Mattermost subscriptions are prepaid annually and based on seat licenses, and infrastructure and support recur. Ask for the quote to show each of these as a separate line item.

How long does a Mattermost migration from Slack take?

Duration depends on the scope, so the timeline is set in the written agreement before work starts. The main drivers are the size of the Slack export, the volume of history and attachments to move, the number of integrations to replace, the readiness of the target platform and its identity setup, and how many test imports the team agrees to run. Cutover planning, including a user communication window and a point after which Slack is no longer written to, adds further time. Ask which phases the timeline covers and who signs off each one.

Can our own IT team run a Slack to Mattermost migration?

Yes, a capable team can follow the documented path itself: export from Slack, conversion with the mmetl tool into a bulk import JSONL file plus attachments, then upload and processing with mmctl. The hardest parts are usually the surrounding decisions. These include mapping users and channels to the right teams and identities, checking a sample of messages and files after each test import, deciding what happens to each integration, and running a cutover that every user can follow. Teams short on time often hand validation and cutover planning to a partner while keeping ownership of the decisions.

Do Slack integrations and bots move to Mattermost?

No. Mattermost documents that integrations are not included in the Slack export and cannot be migrated. Start by inventorying every app, webhook, slash command and bot in Slack, recording what each one does and who depends on it. Then decide, item by item, whether to rebuild it with Mattermost webhooks, slash commands, bots or plugins, or to retire it. Confirm each replacement with the integration's owner and test it in staging with realistic message flows before cutover. Treat this as a separate workstream with its own effort estimate.

Can message history and files be kept when moving from Slack?

Mattermost documents a path that imports message history and attachments: the Slack export is converted with mmetl into a bulk import JSONL file plus attachments, which are then uploaded and processed with mmctl. Whether every message type, thread, edit, reaction and file maps cleanly depends on the contents of your export, so confirm it with test imports. Ask for a validation report that samples channels, threads, direct messages, users and files. Also settle the target file storage location and any retention rules before the first full import.

Does DeployOpen issue compliance certificates for a migration?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, such as migration records, access settings, validation results and change logs. Independent auditors and certification bodies issue audit reports, attestations and certifications. For a migration, the evidence can show who had access to the export, how the data was converted, what was validated, and how retention was configured, so an auditor can test each point. Confirm the scope of the evidence set in writing before work starts.

How DeployOpen runs Mattermost migrations

DeployOpen plans and runs Mattermost migrations from Slack, Rocket.Chat and GitLab Omnibus inside infrastructure you control, with the export, transformation, import and validation steps agreed in writing before work starts. Integrations that do not transfer are inventoried and rebuilt as a separate, scoped piece of work.

How we scope

Engagements are fixed-scope, with the source platform, channels, users, files and date range written into the agreement before work starts.
The written scope lists which integrations, bots and webhooks are inventoried for rebuild, since the Slack export does not carry them.
Cutover approach, validation criteria and the sign-off owner are agreed in writing so the migration has a defined finish point.

How we build

We run the export, mmetl transformation and mmctl bulk import in a staging Mattermost environment before any production load.
Users, channels, memberships and attachments are checked against counts and samples from the source platform after each import pass.
Each import run is logged and repeatable, so a failed batch can be rerun without duplicating content in the target.

How we hand over

You receive the migration runbook, mapping decisions, validation results and the list of items that did not transfer.
Cutover steps, rollback points and the final import record are documented so your team can repeat or audit the process.
Knowledge transfer covers mmctl operations, user onboarding after cutover and where the migration artifacts are stored.

How we support

Post-cutover support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
Rebuilt integrations and bots can be supported through the same retainer once they are live in your Mattermost instance.
Ask us to confirm which Mattermost release line your target will run on, since upgrade planning depends on it.