What a Slack to Rocket.Chat migration involves
A Slack to Rocket.Chat migration moves users, channels and message history with Rocket.Chat's import tools, but it is not a single export-and-load step. Rocket.Chat provides three paths: the full Slack workspace export, Slack users from CSV, and a CSV importer for other sources. Teams with Rocket.Chat administration experience can often run a small import in-house. Most regulated or multi-workspace moves are scoped with a partner, because the decisions that matter sit outside the tool.
Common triggers include a licensing change, data residency requirements, identity consolidation and retention control. Each trigger changes what must be carried over. A licensing change may push you to move history in full, while data residency may rule out certain hosting locations for the imported archive. Confirm the trigger with your own stakeholders before you choose the import path.
Three areas need explicit decisions before the import runs. History: decide which channels, direct messages and time ranges move, and whether archived or private conversations are included. Files: confirm how attachments in the Slack export are stored and whether they land in your chosen file storage. Identities: map Slack accounts to Rocket.Chat users, including deactivated accounts, guests and bots, and decide who owns each mapped account after cutover.
Mattermost data follows a different route. Rocket.Chat expects Mattermost exports to be converted into the CSV format before import, so a Mattermost move is handled through the CSV importer. Check the current import documentation for the exact file layout and limits before you plan the conversion.
What the migration work includes
The migration runs as seven workstreams, each ending in a named deliverable that your team can review before the next one starts. Fidelity for each Slack feature is confirmed in test imports, not assumed from the product documentation.
Inventory and export sizing
We inventory the Slack workspace, including users, public and private channels, direct messages, files and integrations, and size the full export against your storage and import window. The deliverable is an inventory workbook with export size estimates and a list of content that will need a decision before import.
Identity and user mapping
Each Slack account is matched to its identity in your directory, with guest, deactivated and bot accounts classified separately. The deliverable is a user mapping file that records the source account, target username, email and role, and that your identity owner signs off before any user is created.
Channel and room mapping
We decide how each Slack channel maps to a Rocket.Chat room, including naming rules, visibility, owners and archived channels. The deliverable is a room mapping file with one row per channel and a list of exceptions that need an owner decision, such as channels to merge or retire.
Import runs with the Slack or CSV importer
We run the Slack importer on a full workspace export, or the CSV importer for Slack users from CSV and other sources such as Mattermost after conversion. Each run is performed on a non-production instance first. The deliverable is an import log per run with counts and errors, plus a record of any data type the importer does not carry.
Verification of messages and files
We compare imported messages, threads, reactions, edits and file attachments against the source using sampled channels and a fixed checklist. Any feature the importer does not carry is confirmed in testing before it is described to users as migrated. The deliverable is a signed verification checklist with each gap logged.
Staged cutover with user communication
Cutover moves teams in stages, with a freeze window for the final delta import, a rollback point, and a message plan for users about where history lives and how to sign in. The deliverable is a cutover runbook with timings, owners, go and no-go criteria, and the user notices to be sent.
Handover and post-cutover review
After cutover we hand over the mapping files, import logs, verification results and runbook to your operations team, and review open gaps and user questions. The deliverable is a handover pack with an open-issues register and a list of the Slack features your team should expect to rebuild or accept as unmigrated.
What drives migration cost and duration
This table lists the factors that most change the effort of a Slack to Rocket.Chat move, why each one matters, and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Total users and concurrent users | Starter allows up to 50 users and the free Community workspace allows up to 100 concurrent users, so headcount decides whether a paid plan is needed before any data moves. | Confirm active headcount and peak concurrency with Slack admins, then choose the plan before scoping the import. |
| Volume and age of Slack history | Full workspace exports grow with message count, years of history and attachments, which lengthens export handling, import runs and verification. | Agree a retention cutoff with business owners and import only the history they need, with older archives kept separately. |
| Number of Slack workspaces | Each workspace is a separate export, identity mapping and channel set, so consolidating or splitting them changes the number of import passes. | Decide early whether workspaces merge into one Rocket.Chat workspace and document the mapping for each source. |
| Slack Connect and shared channels | External channels involve partner organizations, so their members, ownership and retention rules need decisions outside your own directory. | Inventory shared channels, confirm which external parties stay in scope, and agree how each is recreated or retired. |
| Identity source and group structure | Users must match between Slack and Rocket.Chat, and group membership drives roles and channel access, so gaps in email or group data slow mapping. | Clean the directory before export, confirm LDAP or Active Directory group mapping, and resolve duplicate accounts in advance. |
| Number of target environments | Test, staging and production each need an import run, a verification pass and a rollback point, so more environments multiply the repeated work. | Keep test and staging to a representative sample, and reuse the same import scripts and mapping files across environments. |
| Compliance requirements on retention and audit trails | Retention settings, tamper-evident audit trails on paid plans and evidence of what was imported add review and documentation effort. | Ask compliance owners for written retention rules and evidence expectations before the first import run. |
| Edition chosen | Starter, Community and paid Commercial, Government or Defense plans differ in features such as audit trails, group mapping and failover, which changes what must be built and tested. | Select the edition from the written requirements, and confirm feature availability with the vendor plan documents. |
| Customized channel rules and integrations | Custom permissions, bots, webhooks and connected business systems must be recreated or re-pointed, which adds design and test work beyond the message import. | Limit the first migration to required integrations, and list each one with an owner and a cutover test. |
Migration phases and what each produces
The sequence moves Slack users, channels and history into a Rocket.Chat instance you run, with a checkpoint and a written output at every phase so that each cutover decision rests on evidence.
Confirm discovery and scope
We review the Slack plan and retention settings, the workspace owners, integrations and the channels in scope, and agree which history, files and users move. The output is a written scope and a sizing report covering exported data volume, file count and user count. The phase closes when the client signs off the scope.
Run export and size the data
We request and receive the Slack workspace export, check that it is complete and readable, and separate message history, attachments and user records. The output is an export inventory and a sizing estimate for the target storage. The phase closes when the inventory reconciles with the channel list agreed in discovery.
Map identities and channels
We build the mapping sheet that links Slack users to identity provider accounts, decides how deactivated and bot accounts are handled, and maps Slack channels, private groups and direct messages to Rocket.Chat rooms and naming rules. The client approves the sheet before any import runs. The output is the signed mapping sheet.
Build the target instance
We deploy the Rocket.Chat target in the environment you control, using a version that is inside its support window, with MongoDB 8.0 or later running as a replica set. The build includes identity sign-in, TLS, backups and storage. The output is a build record and a runbook for the target, and the phase closes when a health check passes on the target.
Run a trial import
We run the Slack import into a non-production instance using the mapping sheet and capture the import log, including skipped records, failed uploads and warnings. The output is the trial import log and a list of defects with owners. The phase closes when the log has no unexplained gaps.
Verify and fix in cycles
We compare imported users, rooms, message counts and file links against the export inventory, fix mapping or import issues, and repeat the trial until the results match the agreed criteria. The client's business owners test sample channels and access. The output is signed-off test results that name each accepted exception.
Cut over a pilot group and then everyone
A pilot group of users moves first, with the rollback steps in the runbook ready, and the team reviews issues before the full cutover. The full cutover then imports the final export, freezes Slack use for the migrated scope, and opens Rocket.Chat to all users. Hypercare follows, with a support queue and an agreed handover. The outputs are the cutover record and a hypercare handover document. Timing for each phase is set in the written scope.
What to keep in-house and what to outsource
This table splits Slack to Rocket.Chat migration work between your internal roles and a partner, with the skill each part needs, so you can see where your own people must stay in the loop.
| Role or work area | Who owns it | Skill it needs | Decision point for a small or regulated move |
|---|---|---|---|
| Identity and directory owners | Internal | Knowledge of your identity provider, user lifecycle and how Slack accounts map to employees | Small single-workspace move: confirm email matching only. Regulated or multi-workspace move: they sign off on the user mapping file before import |
| Slack workspace administrators | Internal, with partner guidance | Slack plan owner rights to run full workspace exports and confirm which data your plan includes | Confirm export scope early, since admin access and export availability depend on your Slack plan and admin settings |
| Data owners for retention and channels | Internal | Business knowledge of which channels, private conversations and history must move, be archived or be dropped | Regulated moves need written decisions per channel and per retention category before any conversion starts |
| Platform engineer for MongoDB and Rocket.Chat | Internal, with partner support | Operating MongoDB as a replica set and running Rocket.Chat 8.x upgrades and backups | Single-instance pilot may fit one engineer; a multi-workspace or regulated rollout needs a named owner for the replica set and backups |
| Security reviewer for access and retention settings | Internal | Review of account roles, MFA, retention policies and where exported Slack data is stored during the move | Regulated moves need this reviewer to approve retention settings and the handling of export files before import runs |
| Import scripting, CSV conversion, verification and cutover | Partner, with internal sign-off | Writing Slack importer runs and CSV conversion for other sources, reconciling counts and supporting the cutover window | Small moves may use the built-in Slack importer alone; multi-workspace or non-Slack sources usually need scripted conversion and a verification plan |
What usually goes wrong and how to prevent it
Most Slack to Rocket.Chat migration problems come from data and decisions made early, and they surface late. Each risk below has a check to run before the import reaches production users.
Incomplete or unexpected export contents
A Slack workspace export may not contain everything the team expects, and gaps often appear only after the first import run. Before committing to a date, compare the export against a list of channels, direct messages, users and file types you need, and confirm with the Slack workspace owner which content your plan and settings include. Run a full test import on a copy of the export.
Identities that do not match the directory
Slack usernames, email addresses and display names often differ from the records in your identity provider, so imported messages can end up attributed to accounts that no one can sign in to. Build a mapping table from Slack user IDs to directory identities, and agree with HR or the identity team who owns each mapping. Resolve mismatches before the import, not during it.
Duplicate and merged users
People with multiple Slack accounts, shared accounts, bots and departed staff can produce duplicate or merged users in the target workspace. Check the export for accounts that share an email address or appear under several names, and decide in advance which identity keeps each person's history. Record every merge decision so that support staff can explain it later.
Channel name collisions and archived channels
Channel names that are unique in Slack can collide after normalization, and existing Rocket.Chat rooms may already use the same names. Archived Slack channels may be imported as active rooms and clutter navigation. List every name conflict and archived channel, then decide on renames, merges and whether archived history is imported read-only or left out.
Files and attachments that do not carry over as expected
Attachments, shared files and avatars may be missing, unreadable or stored in a different location after import, and file references in old messages may break. Sample messages with files from several years and channels, open them in the target system, and confirm the storage configuration can hold the total volume. Plan how users will find files that could not be imported.
Timestamps and time zone differences
Message times can shift when the export's time values are read in a different time zone, which makes conversations appear out of order or on the wrong day. Confirm how the export records timestamps, set the server time zone deliberately, and compare a set of messages from known times in both systems. Keep the check results with the cutover record.
Target MongoDB not sized for the import
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a large import writes heavily to the database. A replica set sized only for steady-state chat can slow the import, delay the server, or fill storage. Confirm the MongoDB version and members with your database team, test the import against a representative export, and measure disk and memory headroom before setting a date.
Cutover without rollback or user communication
A cutover without a documented rollback path leaves the team with no safe way back if the import fails or users cannot sign in. Define the freeze point, the time Slack becomes read-only, the criteria for rolling back, and who makes that call. Tell users what changes, when, how they sign in and where to get help, and rehearse the steps on a staging copy.
How the work changes by starting point
Rocket.Chat's Slack importer accepts a full workspace export, which can carry users, channels and message history together. Most of the effort goes into preparing the export and resolving identities, not into the import itself.
- Confirm the export type: Ask the Slack workspace owner which export your plan allows and what date range it covers, and request it early.
- Size the export: Message history and attachments drive import time and storage more than user count. Estimate both from the export before scheduling.
- Decide the scope: Confirm which public channels, private channels, direct messages and archived channels move, and whether the importer handles each type as you expect.
- Map identities: Match Slack accounts to Rocket.Chat accounts, and decide what happens to deactivated users and bot accounts.
- Run a test import: Load the export into a non-production instance and check channels, membership and message counts before the cutover.
When message history stays in Slack, the CSV user import creates accounts only. Channels and messages do not follow, so the first task is identity, and the rollout is planned around people rather than content.
- Prepare the user file: Export the member list from Slack and confirm the column layout against the format the CSV importer expects.
- Fix missing or duplicate emails: Accounts without a unique email often fail to match, so resolve these in the source list before import.
- Align the identity source: If sign-in will run through LDAP, Active Directory or SSO, make sure the imported usernames and emails match what that provider issues.
- Plan channel creation: Your teams will create or recreate channels after import, so decide who owns that work and which channels are needed on day one.
- Decide on Slack's future: Confirm whether Slack remains available as a read-only reference and for how long.
Mattermost data moves by converting its export into the CSV format that Rocket.Chat's importer reads. Other tools also use the CSV importer, so the conversion work is the main engineering task.
- Define the export contents: Confirm which users, channels, posts, threads and attachments the Mattermost export includes before writing any conversion code.
- Build and test the conversion: Write or review the transformation into the CSV layout, then run it on a small sample and check the result in a test instance.
- Handle attachments separately: Confirm how files are referenced in the source export and whether they need a separate transfer step.
- Check timestamps and ordering: Verify that message dates, thread replies and sequence survive the conversion, because these errors are easy to miss in bulk.
- Record source versions: Note the source tool's version and confirm the export is complete, so the conversion is repeatable at cutover.
Importing into a Rocket.Chat instance that already has users and channels raises the risk of duplicates and naming collisions. Importing into a new instance means the platform foundation must be ready before any data moves.
- Existing instance: Inventory current users, channels and usernames to find collisions, and decide how each duplicate will be resolved.
- Confirm the version: Check that the running Rocket.Chat version is still supported, since unsupported versions stop receiving security fixes.
- New instance: Confirm the MongoDB version and replica set are in place, because Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set.
- Confirm the plan: The free Starter plan allows up to 50 users, so confirm whether your user count needs a paid plan before the import.
- Choose the target path: Decide whether data goes into production directly or first into a staging copy that the team can review.
In isolated networks or Kubernetes clusters, container images, the Helm chart and the import tooling must be staged inside the boundary before any data moves. Air-gapped deployment is a paid-plan capability, not available on Starter.
- Confirm the plan first: Verify that your Rocket.Chat plan includes air-gapped deployment before any staging work begins.
- Stage the artifacts: Copy the images, Helm chart and import tooling into your internal registry and confirm the exact versions match.
- Control file transfer: Move export files through an approved path and apply your scanning and approval steps before they reach the import host.
- Check storage and database placement: Confirm storage classes and MongoDB placement in the cluster, since large imports write heavily to the database.
- Verify client and notification behavior: Confirm how mobile and desktop clients connect and how push notifications behave without internet access.
What you need to provide before work starts
Most of the migration schedule depends on inputs that only your organization can supply, so collect them before scoping is finalized. The first is Slack access: a workspace owner or admin must run the full export that the Rocket.Chat Slack importer reads. Ask that administrator to confirm which export type they can produce on your Slack plan and whether it contains the message history your retention rules require. Approval sits with the Slack workspace owner.
Next, provide the list of Slack workspaces and channels in scope, along with an export of users and groups from your identity source, whether Active Directory, LDAP or an SSO provider. The identity owner approves the user export, and each channel owner confirms which channels move, merge or stay behind. The number of users in that export also drives the edition decision: the free Starter plan covers up to 50 users, Community covers up to 100 concurrent users, and larger deployments need a paid plan. The CIO or budget holder approves the edition and user count.
On the target side, the platform team must prepare a Rocket.Chat 8.x environment backed by a MongoDB 8.0 replica set, with a three-member set recommended for high availability, plus a documented network plan for ingress, DNS and outbound access. Named owners must also decide retention periods and which channels or direct messages are excluded. Records management or legal signs off on retention, and the platform owner approves the network plan. Confirm the exact MongoDB and Rocket.Chat versions with the vendor documentation before the environment is built.
Two final inputs keep the trial and cutover on track. Provide a sample of Slack data, chosen by the workspace owner and security team, so the team can run trial imports and check how users, channels and attachments map. Then agree a cutover window with the business owners of each affected team, including a freeze on new Slack activity for the agreed period and a rollback decision point. Business owners approve the window, and the executive sponsor approves any change to it.
Frequently asked questions
What drives the cost and timeline when moving from Slack to Rocket.Chat?
The cost and timeline follow from a written scope, because DeployOpen does not publish a list price. The main drivers are the size of the Slack export, the number of users and channels, how identities map to your directory, whether Mattermost or other sources are included, and the Rocket.Chat plan and hosting you choose. Ask for one-time migration work and recurring items such as support and upgrades to be itemized separately. Rocket.Chat's paid plans are also priced by quote, so request that figure from Rocket.Chat directly.
Can our internal team move from Slack to Rocket.Chat alone?
Yes, an experienced internal team can run the migration, since the import tools are documented and the work is mostly planning, testing and administration. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, so confirm that platform skill exists before starting. Your side will need a Slack owner or admin to run the export, directory access for identity mapping, decisions on channel and retention mapping, hosting ready, and time for test imports and user communication. A partner is useful when staff are short or several sources are involved.
Does a Slack export bring all message history into Rocket.Chat?
The Rocket.Chat importer supports full Slack workspace exports, but whether every item comes across depends on what your Slack export contains for your workspace and plan. Confirm with your Slack admins which users, channels, messages and files the export includes. Run test imports and compare counts for channels, users and sample threads before the cutover. Record any gaps in writing so the business knows what is not carried over and can plan for it.
Can Mattermost and other chat tools be migrated to Rocket.Chat?
Yes, Rocket.Chat's CSV importer handles other sources, and Mattermost data is migrated by converting its export into the CSV format. Each source needs its own mapping for users, channels, timestamps and attachments, so the conversion work should be tested on a sample first. Confirm which fields the importer expects and how the source handles files and direct messages. Include the conversion effort in the written scope, since it often drives the timeline more than the import itself.
Can free Rocket.Chat plans host users moved from Slack?
Yes, for smaller groups. The free Starter plan allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. The free Community workspace allows up to 100 concurrent users with core messaging. Larger groups need a paid plan, and air-gapped deployment is only available on paid plans. Confirm current plan limits with Rocket.Chat before you decide, since your user count determines the fit.
What happens to our Slack workspace during the Rocket.Chat cutover?
The old Slack workspace stays in use until the cutover plan says otherwise, so the team needs a staged plan. A typical plan sets a cutover window, announces the date to users, runs both systems during a defined period, and then decides how Slack is used afterward, such as limiting new activity or keeping it for reference. Confirm with your Slack admins which settings your plan allows, and keep the Slack export as a record before any change is made.
How DeployOpen runs Rocket.Chat migrations
DeployOpen plans and runs Slack to Rocket.Chat migrations inside your own infrastructure, using the Slack importer and CSV importer with written scope, tested imports and a staged cutover. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- We size the Slack workspace export, including channels, users, files and history span, before agreeing the scope.
- We map Slack identities to Rocket.Chat accounts and decide how departed or guest users are handled.
- The written scope lists which sources are imported, which channels move, and what is left behind.
How we build
- We stand up a Rocket.Chat target in your environment, with the MongoDB replica set the chosen version requires.
- We run test imports against a copy of the export and review users, channels and message history.
- We rehearse the staged cutover, including user communication, freeze windows and a rollback path.
How we hand over
- We document the import runbook, identity mapping decisions and the list of skipped or transformed items.
- We record verification results so your team can see which channels and users were checked and how.
- We train administrators on the post-cutover tasks, such as retention settings and channel ownership cleanup.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the cutover.
- Post-migration support can cover issues found by users in the first weeks after the cutover.
- We can plan Rocket.Chat version upgrades so the target stays within a supported release line.
