Migrate from Slack to Rocket.Chat: what the move involves
Most teams leaving Slack for Rocket.Chat are reacting to a renewal, a data residency requirement, lock-in or a cost review, and the move is an import plus a rebuild, not a lift. Rocket.Chat's built-in importer brings across users, channels and messages from a Slack export, but the integrations, bots and workflows that depend on Slack have to be inventoried and recreated on the Rocket.Chat side. Plan the project as a migration of data and a re-implementation of connected tools, with the chat server itself as the smaller part of the work.
The work is usually run by a platform or IT team that owns the Rocket.Chat server, with an implementation partner such as DeployOpen handling installation, hardening, the importer runs and the integration rebuild. The effort and risk depend less on the chat software than on two inputs: which Slack plan the organization is on, and how much of its history it exported. Slack's export scope is set by plan. Public channels can be exported on every plan, while private channels and direct messages require Business+ or Enterprise, so a Free or Pro workspace may be missing content the organization assumes it has. Confirm the export scope with Slack before anyone plans the cutover, and check the Slack export guidance for the current rules.
Before scheduling anything, decide three things with the business owners: which history must move and which can stay archived, who owns the rebuilt integrations after go-live, and whether the Rocket.Chat deployment will run on a plan that supports the required features. The import steps, file splitting and integration work are covered in the sections that follow, so this part of the plan only needs to fix scope, owners and the target plan. Ask any implementation partner for a written scope that names each of these items before work starts.
Which Slack capabilities map to Rocket.Chat, and which need rework
This table maps the main Slack capabilities to their Rocket.Chat equivalents and labels each as clean, needs rework or gap. Read the plan column alongside the row, because several features only appear on Commercial or Government plans. Confirm each row against your own export and plan before committing to a cutover.
| Slack capability | Rocket.Chat equivalent | Status and plan notes |
|---|---|---|
| Public channels and messages | Channels imported from the Slack export through Manage, Workspace, Import | Clean. Available on the free Starter and Community tiers within user limits. |
| Private channels and direct messages | Imported when the Slack export includes them | Needs rework. Confirm your Slack plan can export private channels and DMs before planning the import. |
| Threads | Threaded replies in Rocket.Chat channels | Needs rework. Check thread structure in a test import because layout can differ from Slack. |
| File attachments | Files stored on the Rocket.Chat server or configured file storage | Needs rework. Slack exports may hold file links rather than files, so confirm what the export contains. |
| User accounts and profiles | Users imported from the export or from Slack users in CSV | Needs rework. Passwords are not migrated, so users must reset access after import. |
| Search across history | Built-in message search over imported history | Needs rework. Confirm search results on imported history during a pilot. |
| Slack apps, bots and webhooks | Rebuilt as Rocket.Chat integrations, incoming and outgoing webhooks or apps | Gap. Integrations are not carried over by the importer and must be inventoried and recreated. |
| Omnichannel customer chat | Rocket.Chat Omnichannel, where applicable to your use | Gap. Slack does not provide this equivalent, so confirm it is covered by your plan before relying on it. |
| SSO and LDAP sign-in | LDAP and Active Directory on Starter, SSO and SAML group mapping on paid plans | Clean for LDAP and AD on Starter. SAML user group mapping and audit trails require Commercial or Government plans. |
What Slack exports carry and what must be rebuilt
A Slack export decides what history reaches Rocket.Chat, and the export plan sets the ceiling. Some items come across through the importer, while integrations, custom emoji and user groups need hand work after the import finishes.
Public channel exports on every plan
Every Slack plan can export messages and file links from public channels, so this is the baseline any migration can rely on. Before you request the export, confirm which workspace owner or admin will run it and whether the export contains the channels your teams actually use. Treat the export as the source of truth for what Rocket.Chat receives, and compare channel counts against Slack after the import.
Private channels and DMs need a paid plan
Exporting private channels and direct messages requires Business+ or Enterprise, and custom exports by member or conversation are limited to Enterprise. If your workspace is on Free or Pro, plan for a gap in private history and confirm with your Slack owner whether an approved application is possible before cutover. Record what is missing so users are not surprised later.
File links, not file contents
Slack exports carry file links rather than the files themselves, and those links can stop resolving once the workspace plan changes or the Free history limit applies. Decide early whether attachments must be preserved, then download them while access still works and plan where they will be stored in Rocket.Chat. Check that attachment references in imported messages point somewhere your users can still reach.
Importer path and file splitting
In Rocket.Chat, go to Manage, then Workspace, then Import to load a full Slack workspace export, or import Slack users from a CSV. Rocket.Chat recommends splitting large exports into files under 15 MB, so run a test import on a copy of one large channel first. Keep the split files in a fixed naming order so a failed batch can be rerun without duplicating messages.
Integrations and bots to rebuild
Slack apps, incoming webhooks, slash commands and bots do not carry over with the message history, so each one must be inventoried and recreated against Rocket.Chat's own integration settings. List every app installed in Slack, the channel it posts to and the system that receives its payloads. Assign an owner to each integration and test it in a staging workspace before users depend on it.
Custom emoji and user groups by hand
Custom emoji images and Slack user groups are not part of the importer output, so they must be re-uploaded or recreated manually. Export the emoji list from Slack, collect the image files, and rebuild each group with the same membership used for mentions and access. Test a mention of each group in a pilot channel, since users often rely on these shortcuts daily.
Migration sequence from inventory to decommission
This sequence takes a Slack workspace from an inventory of what exists to a Rocket.Chat deployment that has proven its imports, run in parallel with Slack, and then replaced it as the system of record. Each step closes with a named artifact that the next step depends on.
Inventory channels, members, integrations and retention
Export the Slack workspace data according to your plan, then list every public channel, private channel, direct message group, member, installed app, incoming webhook and slash command. Record which channels hold records you must keep and for how long, since Slack Free workspaces lose content older than one year. Confirm with your compliance lead whether private channels and DMs are needed, because your Slack plan determines whether they are in the export at all. Done when you have a signed inventory that names an owner for each integration and a retention position for each channel group.
Build the channel and user map
Decide which Slack channels become Rocket.Chat channels, which merge, which are archived rather than imported, and how Slack user accounts map to Rocket.Chat accounts, including identity source if you use LDAP or Active Directory. Document each decision in a channel map that lists the source channel, target channel, visibility and owner. Done when the channel map and user map are reviewed by the business owners of the channels they affect.
Split large exports into files under 15 MB
Rocket.Chat recommends splitting large exports into files under 15 MB before import. Break the Slack export into parts by channel or by date range, keeping each message set intact so threads are not split across files. Record each part with its size and content in a split-file plan. Done when every file is under the 15 MB guidance and the plan shows that the parts together cover the full export without gaps or duplicates.
Pilot the import on a test MongoDB replica set
Stand up a non-production Rocket.Chat instance on a MongoDB replica set running a version Rocket.Chat 8.x supports, then run the import through Manage, Workspace, Import using one split file. Compare imported users, channels, message counts, threads and file attachments against the source. Note any errors in the import log and fix the mapping or split files before repeating. Done when a pilot import completes with a validated import log and the checked counts match the inventory.
Run the full import and rebuild integrations
Import all split files into the production-candidate instance in the order set by the split-file plan, then compare the final counts with the pilot and the inventory. Re-create each integration, bot and slash command from the inventory, since exports do not carry them across, and test each one against a sample channel. Done when the import log is validated, each integration has a tested replacement or a documented retirement, and the owners have signed off.
Operate a parallel run period
Run Rocket.Chat alongside Slack for an agreed period, with a notice to staff about which system holds each channel and which is authoritative for each team. Watch for drift in users, channel membership and integrations, and apply the upgrade cadence for your Rocket.Chat line during this period, since unsupported versions lose security fixes and mobile client connectivity. Done when the owners of each channel confirm in writing that the new workspace covers their workflows and the outstanding issue list is closed or accepted.
Sign off the user list and cut over
Obtain sign-off on the final user list from HR or identity owners, then move users to Rocket.Chat, set Slack channels to read-only where your plan allows, and publish the new access instructions. Record the cutover time and any users who did not move so they can be followed up. Done when the signed user list matches active accounts and the cutover notice has been acknowledged by channel owners.
Decommission Slack and retain exported records
After the parallel run closes, export and store any Slack data that retention rules require, confirm the copy is readable, and then remove Slack access, apps and webhooks. Update your records to show where each retained dataset now lives and who controls it. Done when the retention archive is verified, Slack access is removed, and the decommission record is filed with your compliance owner.
How to split a large Slack export before importing
Splitting the export matters because Rocket.Chat's importer works best on files under 15 MB, and the documentation recommends splitting any larger export before upload. A single oversized archive is harder to retry when one import fails, and it gives you no way to isolate the channels or date ranges that caused a problem. Split the export by channel and by day range, so each file still holds complete conversations and the channel and timestamp structure the importer reads stays intact. Keep the original Slack export untouched and work from a copy, because you will likely need to re-split after your first validation pass.
Validate each file on a staging instance before anything touches production. Run the import through Manage, Workspace, Import on a staging server and check the results by sampling channels from different years, threads, and file attachments. Pay particular attention to the user mapping: confirm that every Slack account in users.json matches an existing or newly created Rocket.Chat user, and decide in advance how deactivated Slack accounts and bot users should be handled. Check duplicate handling as well, by re-importing one file and confirming that messages are not doubled and that users are not created twice under a second username. Record the results per file so the production run is a repeat of a known process, not a first attempt.
Ask your implementation partner or internal team to confirm two things with the current Rocket.Chat release before you commit to a split plan: how the importer treats duplicate messages on a second run, and whether your Slack export plan includes the private channels and direct messages you need. The second question is a Slack question, so verify it in your Slack plan's export settings first. Because Rocket.Chat releases are supported for a limited window, schedule the production import on a version that will still receive fixes when you go live, and document the staging results so the change record shows what was tested.
What drives migration cost and duration
This table lists the factors that raise or lower the effort of moving a Slack workspace to Rocket.Chat, with the reason each one matters and how to keep it down. Use it to shape the scope you send for a quote, since no fixed price or duration applies to every workspace.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Slack plan and export scope | The plan decides whether private channels and direct messages can be exported at all. Public channels are available on every plan, while private channels and DMs need Business+ or Enterprise, and custom exports are Enterprise-only. | Confirm the export scope with Slack before the project starts, and ask for a plan review if private history matters. |
| Number of channels, users and DMs | Each channel, member mapping and direct message conversation adds records to validate, and mismatched users create manual cleanup after import. | Archive dead channels, deactivate stale accounts and agree which channels move before export. |
| File volume and export splitting | Rocket.Chat recommends splitting large exports into files under 15 MB, so a large history means more files to split, run and check. | Remove obsolete attachments where policy allows, and group export files by date range to keep each one under the limit. |
| Integrations, bots and slash commands | Slack exports do not carry integrations, so each webhook, bot and custom command must be inventoried and rebuilt on Rocket.Chat. | List every app and webhook in Slack admin, retire unused ones, and rebuild only those tied to active workflows. |
| Identity integration (LDAP, Active Directory, SSO) | Mapping imported users to a directory or SSO provider changes login, provisioning and offboarding work. Starter includes LDAP, Active Directory and SSO, while SAML group mapping sits in paid plans. | Decide the identity source before import, and confirm which features your plan includes in writing. |
| MongoDB replica set and hosting design | Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and a three-member set is recommended for high availability. Hosting, backups and monitoring of these members recur every month. | Size the design to your user count using the reference architectures, and ask the quote to state who runs backups and failover tests. |
| Upgrade cadence and support window | Standard releases are supported for 6 months and LTS releases for 12 months. Unsupported versions lose security fixes and may stop connecting to official mobile and desktop clients, so upgrades recur as ongoing work. | Choose an LTS line where possible, and budget a recurring upgrade and test cycle in the support scope. |
| Air-gapped or regulated deployment | Air-gapped deployment requires a paid plan, and offline upgrades and cloud services that stop working without internet access add design and testing work. | Confirm the deployment target and plan tier before design begins, so the quote covers offline packaging and testing. |
| User training and change management | Users must learn new channels, threads, notifications and mobile clients, and administrators must learn Rocket.Chat operations. This effort is often underestimated. | Plan short training sessions, a pilot group and written guidance on where history lives after cutover. |
What usually goes wrong in a Slack to Rocket.Chat move
Most Slack to Rocket.Chat problems start before the import runs: the export plan, the file sizes, the server build and the people who must switch. Each card below names one of these failure points and the check that prevents it, so the import is the easy part.
Expecting integrations to arrive
A Slack export carries messages, users, channels and files, but not the apps, bots, webhooks or slash commands that post into those channels. Teams that assume the import restores them find out on the first day when alerts and approvals stop. Inventory every Slack app and webhook before cutover, record which channel and which owner each one serves, and plan a rebuild in Rocket.Chat's integration settings for each entry.
Missing private history from the export
The export plan decides what Slack hands over. Every plan can export public channels, but private channels and direct messages need an approved Business+ or Enterprise export, and Free workspaces are limited to 90 days of history. Confirm the plan and the export scope with the Slack workspace owner before the team plans a cutover, because a Free or Pro export can silently leave out the conversations people care about most.
Oversized files failing the import
Rocket.Chat's importer works best when the Slack export is split into files under 15 MB. A single large export archive with years of channel history can fail or stall part way through, leaving partial data that is hard to reconcile. Split the export by channel or date range, run a test import against a staging server, and compare message counts per channel against the source before loading the production copy.
Running an unsupported version
Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. After end of life a version receives no security fixes, and unsupported versions may also lose connection to the official mobile and desktop clients, so staff can read the new workspace in a browser but not from their phones. Pick an LTS line that will still be supported through your rollout, and schedule upgrades as an ongoing task with a named owner.
Skipping the MongoDB replica set
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Teams that install a standalone database to get the server running often discover the gap during import or after the first failover test, when rebuilding the database means re-importing data. Build the replica set before the first import, document its members and backup procedure, and test a failover in staging.
Users not adopting the workspace
A complete import does not mean people will move. If Slack stays open with the same channels active, staff split conversations across two tools and the Rocket.Chat workspace goes quiet. Set a cutover date for each group, announce the Slack read-only period in writing, pin a short guide to common tasks in each channel, and assign channel owners who answer setup questions in the first two weeks.
How the migration changes by starting point
Teams on Slack Free have the narrowest export. Slack keeps 90 days of message and file history on Free workspaces, and content older than one year is permanently deleted, so the window to capture history is short and time-sensitive. Public channel content is the realistic baseline for this group, since private channels and direct messages require a Business+ or Enterprise export. Rocket.Chat's free Starter plan allows up to 50 users and includes LDAP, SSO, MFA and end-to-end encryption, so the plan choice is usually straightforward at this size.
- Export early: Request the workspace export before the history window closes, because older Free content is deleted.
- Expect public-only data: Plan for public channels and file links, and tell members that private conversations are not in scope unless the plan changes.
- Confirm user count: Starter caps users at 50, so count active accounts before choosing it over a paid plan.
- Keep the import small: A small export may fit in one file, but split it if it exceeds the 15 MB guidance.
- Rebuild bots by hand: Inventory any Slack apps and webhooks before cutover, since exports do not carry them.
Confirm the exact export contents for your Slack plan in Slack's current help articles before you start.
A mid-size organization on Slack Business+ can export private channels and direct messages after an approved request, which makes the migration more complete but also more sensitive. Those conversations often contain confidential material, so the export file becomes a controlled asset that needs an owner, storage rules and a deletion date once the import is verified. The Rocket.Chat plan decision depends on user count, SSO and group mapping needs, and whether high availability is required, not on the import itself.
- Request the right scope: Ask Slack for private channel and DM content in writing, and confirm what your plan returns.
- Protect the export: Restrict access to the archive and record who can open it during the import window.
- Size the import: Large workspaces need the export split into files under 15 MB, so script the split and test one file first.
- Plan the plan: Compare the free Community or Starter limits with paid Commercial plans for SSO, LDAP and SAML group mapping and redundancy.
- Map identities: Match Slack users to directory accounts so imported messages attach to the right people.
Confirm with Rocket.Chat which features your user count requires before you commit to a plan.
Regulated and disconnected organizations usually need Rocket.Chat's Government, Defense or Commercial plan, because air-gapped deployment is a paid-plan capability and is not available on Starter. The migration scope is set by the compliance owner, who decides which Slack history must be kept as evidence and how it is retained. Rocket.Chat's paid plans list tamper-evident audit trails of messages, files and sessions, which matter when the import must be defensible. Upgrades also change shape, because offline environments need planned, repeatable update procedures.
- Get the plan first: Confirm in writing that the chosen plan supports on-premises or air-gapped deployment before any import work begins.
- Define retention: Agree with compliance which Slack data is imported, which is archived and how long each copy is kept.
- Plan the database: Rocket.Chat 8.x requires MongoDB 8.0 or later in a replica set, which must be built and tested inside the enclosed network.
- Test offline upgrades: Services such as the push notification gateway stop working after end of life, so schedule upgrades against the support windows.
- Document the evidence: Keep import logs and reconciliation reports so auditors can trace what was migrated.
Confirm the import method and audit features with Rocket.Chat before the scope is signed off.
Questions buyers ask before moving from Slack to Rocket.Chat
What drives the cost of moving from Slack to Rocket.Chat?
The cost depends on the work you pay for and the work your team does. The main components are the server infrastructure you run, the MongoDB replica set that Rocket.Chat 8.x requires, the export and import effort, rebuilding integrations, user and access setup, and ongoing upgrades. Software licensing is a separate line: Rocket.Chat code outside its enterprise directories is MIT licensed, but the Starter, Commercial, Government and Defense plans are a different decision that affects features such as LDAP and SAML group mapping, SSO and air-gapped deployment. Ask any implementation partner for a quote that lists each component separately, with one-time and recurring items marked, so you can compare it with your current Slack spend.
How long does a Slack to Rocket.Chat migration take?
No duration is fixed by the product, so the timeline depends on your export size, the number of channels and users, how many integrations you rely on, and how much validation your compliance team requires. Large exports must be split into files under 15 MB before import, which adds preparation work. Ask for a timeline in the written scope that names the test import, the production import, the cutover window and the user communication steps, and confirm which of these are included in the fixed scope.
What do we need from our own team during the migration?
You will need an owner with Slack workspace admin rights to produce the export, a Rocket.Chat administrator with access to Manage, Workspace and Import, and someone who can approve user mapping and channel decisions. Your identity team will need to confirm how users sign in, especially if you plan to use LDAP, Active Directory or SSO. Your infrastructure team needs to provide hosting, DNS, certificates and backup capacity. Agree these responsibilities in writing so that delays do not fall unexpectedly on either side.
Can our own engineers run the migration without an outside partner?
Yes, a team with Linux, Docker or Kubernetes, MongoDB and Slack admin experience can follow Rocket.Chat's documented import path. The harder parts are sizing and operating the MongoDB replica set, planning upgrades within the support windows, and rebuilding bots and webhooks. Rocket.Chat's standard releases are supported for 6 months and LTS releases for 12 months, so someone must own upgrades for the life of the server. If your team lacks that capacity, a fixed-scope engagement or a retainer for upgrades and support can cover the gap. Confirm your internal skills honestly before deciding.
What happens to our Slack integrations and bots after the import?
Integrations do not move automatically. The Slack import brings users, channels and messages, but apps, bots and their configurations must be inventoried and rebuilt in Rocket.Chat. Start by listing every Slack app, incoming webhook, slash command and scheduled message, with its owner and the channels it posts to. Then decide for each one whether to rebuild it, replace it with a Rocket.Chat app or integration, or retire it. Test each rebuilt integration in a staging workspace before cutover, because the work usually takes more time than the data import itself.
Which Rocket.Chat plan do we need for SSO and directory sync?
Starter is free for self-managed evaluation and small teams, and it allows up to 50 users. Rocket.Chat's plans documentation lists LDAP and Active Directory authentication, single sign-on, multi-factor authentication and end-to-end encryption on Starter, while the paid Commercial, Government and Defense plans add items such as LDAP and SAML user group mapping, tamper-evident audit trails and built-in redundancy with automated failover. Air-gapped deployment is only available on paid plans. Because plan features change, confirm the current feature list on Rocket.Chat's pricing page and ask the vendor to confirm the plan that matches your identity and compliance requirements.
What upgrade obligations come with self-hosting Rocket.Chat?
You are responsible for keeping the server on a supported release. Rocket.Chat's version durability documentation says that after end of life a version gets no security or bug fixes, cloud services such as the push notification gateway stop working, and unsupported versions may lose the ability to connect with the official mobile and desktop clients. Rocket.Chat 8.9.0 was published on October 5, 2026, and patch releases followed for older supported lines. Budget for a recurring upgrade cycle, test each upgrade in staging, and keep MongoDB on a version that Rocket.Chat 8.x supports.
How DeployOpen scopes and runs a Slack to Rocket.Chat migration
DeployOpen plans and runs the Slack to Rocket.Chat move inside your own infrastructure, from the export request through to a documented handover. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Confirm which Slack plan produced the export, since private channels and DMs depend on Business+ or Enterprise access.
- Inventory channels, users, file attachments and the Slack integrations that will need rebuilding in Rocket.Chat.
- Agree in writing which workspaces, channels and date ranges are in the migration and what is excluded.
How we build
- Set up the Rocket.Chat server, its MongoDB replica set and the Slack import path inside your environment.
- Split large Slack exports into files under 15 MB and run test imports before any production load.
- Check imported users, channels, messages and attachments against the export and record the results.
How we hand over
- Deliver a runbook covering the import steps, rollback points, admin settings and the post-import checklist.
- Document the bot, webhook and slash command rebuild so your team can maintain them after handover.
- Walk your administrators through the upgrade cadence, since Rocket.Chat support windows require regular updates.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and upgrade windows are agreed in writing, so confirm them in the quote.
- Ask for a written quote built from the agreed scope, since DeployOpen does not publish a price list.
