What the move involves and how much effort to expect
The short answer on effort is that it depends on four things: workspace size, how much message history you keep, how many integrations you run, and how identity is designed. Scope it in writing before any work starts. Rocket.Chat's documented route for Mattermost data is to convert the Mattermost export into the CSV format used by its CSV importer. Its native Slack importers do not apply to Mattermost, so migration guides written for Slack will not transfer directly. Confirm the expected CSV layout and the importer steps against the import documentation for the Rocket.Chat version you plan to run, since the file structure is the detail most likely to differ between releases and it sets the conversion work.
Several factors push effort up. Large message histories and file attachments increase conversion and import time and need more test runs. The number of users, and whether their accounts are created by the import or by first login through SSO or LDAP or Active Directory, determines how much identity mapping must be checked. Public, private and archived channels, direct messages and group conversations each need a rule for how they convert. Bots, webhooks and slash commands from Mattermost do not move as working configuration, so each one must be inventoried and rebuilt on the Rocket.Chat side. Plan a sample export with a realistic slice of channels early, because it exposes most of these issues before the full run.
Cost has several parts. Your staff pay in time for the export, the conversion, validation, user communication and cutover. A partner's fixed-scope work covers the components you agree in the written scope. Infrastructure for the new platform recurs, and so do Rocket.Chat plan fees, which are quoted and not public for the paid tiers. Mattermost subscriptions are prepaid annually and based on seat licenses, so the cost of running both platforms during overlap depends on when your current term ends. Ask any provider for a quote that lists the conversion scripts, the number of test imports, the validation checks, the cutover window, the rollback steps, the assumptions, and what you must supply, such as export access and a named owner for user mapping decisions.
Running both platforms during cutover is a scoping decision as much as a technical one. Decide how long the two systems overlap, whether Mattermost moves to read-only after the final import, and how users will find messages that stayed behind. Set a clear owner for each open question, including which channels are archived instead of imported. DeployOpen works fixed-scope: deliverables, timelines and responsibilities are agreed in writing before work starts, and the company does not publish a price list. A quote follows from that written scope, so the scoping questions above are the ones to settle first.
What maps cleanly and what needs a decision
This table compares Mattermost capabilities in your workspace with their Rocket.Chat equivalents and notes how each one moves through the CSV importer. Treat the importer notes as assumptions to test, since importer behavior must be confirmed against the Rocket.Chat import documentation for your target version. Items marked as needing a decision affect plan, architecture or identity choices, so settle them before the first test import.
| Capability | Mattermost | Rocket.Chat equivalent | Migration note |
|---|---|---|---|
| Teams | Teams group users and channels within one workspace | Teams group channels and members with their own rooms | Map each Mattermost team to a Rocket.Chat team. Confirm how the importer handles team membership. |
| Channels | Public, private and archived channels with headers and purposes | Public and private channels, with read-only and archived states | Expected to import from the converted CSV. Confirm archive status, headers and purposes after a test import. |
| Direct messages | One-to-one and group direct messages | Direct messages and group direct messages | Expected to import as conversations between mapped users. Verify group membership after a test import. |
| Users and accounts | Accounts with usernames, emails and profile fields | Users with usernames, emails and profile fields | Map users first. Plan for users to sign in through the identity method you configure. Confirm what the importer sets for passwords. |
| Roles and permissions | System admin, team admin and member roles, plus channel roles | System roles and permissions, with team and room roles | Needs a decision: map each Mattermost role to a Rocket.Chat role, then review permissions manually after import. |
| File attachments | Files stored on local or shared storage and referenced by posts | Uploaded files kept in the configured file storage | Confirm how the importer handles attachments. Plan to move files to target storage and test links after import. |
| SSO and AD/LDAP sync | SAML, OIDC, OAuth and AD/LDAP sync, from the Professional plan | LDAP, AD and SSO on Starter, with group mapping on paid plans | Needs manual setup. Identity is configured in the target, not carried by the importer. Test before cutover. |
| High availability | Clustered application servers with shared file storage, on Enterprise plans | MongoDB 8.0 or later replica set, with multi-instance designs on paid plans | New decision. Not migrated. Design the target architecture and confirm plan requirements before import. |
| Integrations and bots | Webhooks, slash commands and bot accounts with access tokens | Webhooks, apps and Marketplace integrations | Needs manual setup. Recreate integrations, bot accounts and tokens in Rocket.Chat, then update endpoints. |
Converting the export and mapping users, channels and messages
The conversion step decides whether the import succeeds, and most of the mapping work sits here. Someone on your team or a partner extracts the Mattermost export from the source server, then transforms it into the CSV format that Rocket.Chat's importer accepts. Rocket.Chat's import documentation describes the CSV importer for sources other than Slack and states that Mattermost data is migrated by converting its export into that format. Before writing any converter, confirm the current export layout and the CSV specification against the Mattermost and Rocket.Chat documentation. Take field names and record types from those documents at the version you are running. Keep the original export untouched and run every conversion from a copy so the transformation can be repeated.
Users, channels and message history each need an explicit mapping decided before conversion. For users, decide how each Mattermost account maps to a Rocket.Chat identity, especially if the target will use LDAP or Active Directory, single sign-on or multi-factor authentication. Duplicate accounts, such as one person with two usernames or email addresses, need a survivor rule. Inactive accounts need a rule as well: whether deactivated users are imported, and how their past posts are attributed. For channels, record the owner or administrator of each public and private channel and decide which archived channels move. For messages, check that timestamps keep their original time zone and ordering, that thread replies stay attached to their parent posts, and that attachments are included in the export and reachable by the target.
Run a test import before any production load. Load a representative subset into a non-production Rocket.Chat instance that uses the same configuration as the planned target. Compare counts of users, channels, memberships and messages against the source. Sample several threads and reply chains, check timestamps for messages posted across different time zones, open a set of attachments, and confirm that imported users can sign in through the identity method you chose. Record every rejected row and its cause. Fix the converter and rerun the test, rather than editing records in the target by hand, so the full run stays repeatable. Keep the test logs as evidence for the cutover decision, and agree in writing on which checks count as acceptance.
The inputs you provide set the scope of this work. You need a current user list with account status, a record of channel ownership, and retention decisions: how much history to import, whether older messages stay visible, and who approves those choices. Retention settings on the target also affect what users can see after import, so align them with the decisions before the test run. Ask any partner for a written list of assumptions about these inputs, the expected rejected rows, and the acceptance checks. The main effort drivers are the volume of message history, the number of attachments, the quality of the user directory and the number of exceptions that need manual review. Ask for each of these drivers to be stated in the quote, and treat the converter as a one-time build that may need rework after each test.
Documented import paths and what each one covers
Rocket.Chat's import tools accept several source formats, but Mattermost data reaches Rocket.Chat only after its export is converted into the CSV format the importer expects. The cards below set out what each documented path needs from the admin, which limits to confirm with the vendor, and why every path starts with a test import.
Mattermost export as the starting point
The Mattermost export is the source for every user, team, channel, message and attachment you plan to move, so its contents set the migration scope. Confirm which Mattermost version produced the export, who on your side can run it, and whether it includes the attachments and history you intend to keep. Record anything the export leaves out so those gaps are decided before the converter is written.
Rocket.Chat CSV importer for converted data
Rocket.Chat's CSV importer handles sources outside Slack, and Mattermost data enters it only after conversion. The admin needs an account with permission to run imports, a target workspace reachable during the run, and the CSV layout the importer currently expects. Confirm supported file sizes, attachment handling and any per-import limits with Rocket.Chat before planning import batches.
Converter ownership and output validation
The conversion step maps Mattermost users, channels and posts to the CSV layout and is often the largest piece of custom work on this path. Decide whether your team or a partner writes and maintains the converter, and name who signs off its output. Check a sample of converted channels against the source for message order, timestamps and user references before running the full conversion.
Slack CSV user import (background)
Rocket.Chat also documents a CSV import for Slack users. It applies to Slack sources, so it does not move Mattermost users, but it shows the user file structure and identity fields Rocket.Chat expects. Teams comparing Slack and Mattermost as sources should use it to understand those fields, then confirm with Rocket.Chat whether the user import can run without message history.
Full Slack workspace export (background)
Rocket.Chat's Slack import reads a full Slack workspace export, which covers channels, messages and files. It is documented for Slack workspaces only, so it is relevant to this topic as a comparison point. Teams weighing sources should note what a Slack export requires from a Slack owner and what Rocket.Chat expects in return, then confirm current export limits with Slack and Rocket.Chat.
Test import on a target copy
Run the first import against a copy of the target Rocket.Chat environment built with the same version, MongoDB replica set layout and identity configuration planned for production. A test import exposes conversion errors, duplicate users, broken room references and slow batches before they reach members. Reset the copy between runs so each result can be compared and repeated.
What does not carry over and how to plan for it
Treat the gap between a Mattermost workspace and a Rocket.Chat workspace as a list you build before cutover, not a surprise you discover afterward. A CSV import moves users, channels and messages in the form the importer accepts. Everything that lives beside that data, in integrations, configuration and client connections, has to be inventoried and assigned an owner. Confirm the exact scope of the Mattermost export and the Rocket.Chat CSV importer in the current import documentation before you promise anyone a result, because that documentation is the authority on what converts and what is skipped. Start with integrations and bots. List every Mattermost bot account, incoming and outgoing webhook, slash command, and OAuth or personal access token in use, and note which team or service owns each one. Webhooks and tokens are tied to the server that issued them, so each one will need a new endpoint or a new credential on the Rocket.Chat side. Custom slash commands and plugins deserve the same treatment: a Mattermost plugin written for the Go server does not run inside Rocket.Chat, so the equivalent behavior must be rebuilt with Rocket.Chat's own apps or integrations, or retired. Ask each owner whether the integration still serves a purpose before anyone spends time rebuilding it. Next, record server-side settings and identity configuration. Mattermost settings such as retention policies, file size limits, notification defaults, team and channel permission schemes, and SSO or AD/LDAP sync configuration do not transfer as a block. Export your current configuration, map each setting to its Rocket.Chat equivalent, and decide which ones you will set manually. Identity needs particular care: confirm how your identity provider's group mappings and user lifecycle rules will be configured in Rocket.Chat, and test that a departing employee loses access as expected before you go live. Finally, plan for clients and communication. Users connected through the Mattermost mobile and desktop apps will need to sign in to Rocket.Chat through the official clients, and existing sessions and device registrations should be assumed to be lost. Any data the importer does not convert, such as custom profile fields, reactions or attachments outside the export, must be verified against your test import and either accepted as loss or handled separately. Write a short user notice that lists what changes, what must be re-created by the user, and who to contact, and publish it before the cutover window opens.
Migration sequence from inventory to decommission
This sequence moves users, channels and message history from a Mattermost workspace to Rocket.Chat in controlled stages, with a rehearsal and a check before each stage advances. It ends with Mattermost retired only after validation and an agreed retention period. Each step names the output that lets the team move on.
Inventory the Mattermost workspace and integrations
DeployOpen works with your Mattermost administrators and the owners of each team. List teams, public, private and archived channels, direct and group messages, user accounts with their roles, deactivated accounts, bots, slash commands, webhooks, outgoing integrations and plugins. Record where file attachments are stored, the PostgreSQL version and the approximate data size. Note which people and systems depend on each integration. The step is done when each owner has signed off the inventory and every item carries a keep, rebuild or retire decision.
Choose the Rocket.Chat deployment and plan
Use the user count, peak concurrency and availability target from the inventory to select an architecture. The Rocket.Chat reference architectures suggest a single instance with a MongoDB replica set up to 500 concurrent users, and multi-instance designs require a paid plan. The free Starter plan allows up to 50 users, while air-gapped deployment needs a paid plan. Choose a supported Rocket.Chat line for go-live, checking the Rocket.Chat version durability docs for support dates, and confirm the MongoDB version required by that line. The step is done when the architecture and plan are documented and match a written scope and quote.
Configure identity on the target instance
Map how users sign in today, whether through Mattermost SSO or AD/LDAP sync, to the Rocket.Chat options your chosen plan includes, such as LDAP or Active Directory, single sign-on and multi-factor authentication. Decide how usernames and email addresses are matched so that no duplicate accounts are created. Define how deactivated accounts are handled and how administrator and moderator roles are reproduced. Test sign-in with a group of accounts from each identity source. The step is done when each test account signs in with the expected role and no duplicate accounts exist.
Convert the export and rehearse the import
Export the Mattermost data and convert it into the CSV format that the Rocket.Chat importer accepts, mapping users, channels and messages to their target fields. Run the import on a non-production Rocket.Chat instance, then compare user, channel and message counts with the inventory. Document what does not carry over, including integrations, bots and plugins, and agree how each gap is handled. Repeat the conversion and import until the errors are resolved. The step is done when a reconciliation report shows matching counts and the owners accept the list of gaps.
Run a pilot with a small user group
Select a pilot group that spans several teams and includes at least one administrator and one integration owner. Pilot users work in Rocket.Chat for an agreed period while replacement integrations are tested. Track issues with sign-in, notifications, file access, search and the official mobile and desktop clients. Fix configuration and converter problems, then rerun the staging import so the fixes are verified on fresh data. The step is done when the pilot leads sign off and no blocking issues remain open.
Run both platforms in parallel
Keep Mattermost available while the migrated teams move to Rocket.Chat. Write a rule that states where new messages go for each team and from which date, and publish it to every user. Once a team moves, its members stop posting in Mattermost. Re-point integrations to Rocket.Chat during this phase and test each one with its owner. The step is done when every team confirms the routing rule in writing and each integration owner confirms that the replacement works.
Cut over with a final incremental export
Agree a cutover window with the business owners and communicate it in advance. Stop new posts in Mattermost, export everything created since the last full import, convert it and import it into the production Rocket.Chat instance. Reconcile the counts against the frozen export, switch DNS and client settings, then set Mattermost to read-only. Validate sign-in for all users, sample messages by team, file access and client connections. The step is done when the validation checklist is complete and users have received the post-cutover notice.
Decommission Mattermost after retention
Keep Mattermost in read-only mode and retain the final export and database backups for the retention period agreed by legal, compliance and the business owner. When that period ends, remove the Mattermost application servers, data, file storage and DNS records, revoke service credentials and update the asset inventory. Confirm before deletion that a retained archive can be restored. The step is done when a signed decommission record exists and the retained archives are stored under controls you choose.
Running both platforms during cutover
A parallel run works only when each stage has one system of record, written down before the first test import. Until the final import, Mattermost remains the place where official conversation happens, and Rocket.Chat is populated from converted exports in a staging instance that users do not post to. During the window, the cutover lead should set a freeze point after which Mattermost stops accepting new posts, and a second point after which Rocket.Chat becomes the system of record for new messages. Between those two points, the team must be clear which platform answers questions about a conversation, which one holds files that users edit, and who can grant exceptions. Record these answers in the cutover plan so that support staff, administrators and channel owners give the same answer.
Users need one set of instructions, delivered in the same order on every channel they read. Send the announcement from the cutover owner before the freeze. It should state the Rocket.Chat address, the date the old workspace stops accepting posts, and where to get help. Each Mattermost channel that will move should carry a final message pointing to its Rocket.Chat counterpart, and that message should be pinned or otherwise visible on arrival. Check that channel names, membership and private channel access match the mapping file, because users who open an empty channel will assume the migration failed. Name a single owner for user questions and keep a decision log for exceptions, such as a team that needs more time on the old platform. Keep the announcement factual and avoid promising features the target does not yet provide in your configuration.
New history created after the final export is the part teams most often underplan. Messages posted to Mattermost between the export and the freeze will not appear in Rocket.Chat unless you run another conversion, so decide before cutover how that gap will be closed. Confirm in the Rocket.Chat import documentation whether a second CSV import can be applied to an existing workspace without creating duplicate users, channels or messages, and test that behavior on the staging instance first. If a second import is not workable, the plan needs a manual step, such as a short list of threads that owners copy by hand, or an agreed statement that the gap stays in the archive. Attachments need the same treatment. Confirm where file content will live after cutover and whether links inside old messages still resolve, since broken links in archived conversations generate many support requests.
Define the validation gate and the rollback path before the window opens. Validation should cover sign-in through your identity provider, mapping of roles and channel membership, sampled message counts and spot checks in each converted channel, file access, and whether the official desktop and mobile clients connect. The cutover owner should hold written go and no-go criteria, and the team should agree in advance which failures trigger rollback. If the target fails, Mattermost stays the system of record, the freeze is lifted, users receive a second announcement, and the Rocket.Chat workspace is kept for analysis and wiped only after review. Also decide the point after which rollback would lose messages posted only in Rocket.Chat, and have the business owner sign that decision before the freeze.
How long the Mattermost source can stay in service depends on its release cadence and support dates, so confirm the source version and its support window early. Mattermost publishes a new server version in binary form on the 16th of each month. Its published dates include v11.11, released 2026-09-16 with support ending 2026-12-15, and v12.0, released 2026-10-16 with support ending 2027-01-15. The v11.7 Extended Support Release is supported until 2027-05-15. If your window could run past the end of support for your current version, plan an upgrade of the source before the export, or extend the window with a dated decision. Finally, document the cutover checklist as one controlled document listing each step, owner, timestamp, go and no-go gate, rollback trigger and sign-off, so the window can be audited afterward.
What drives cost and duration
This table lists the factors that change how much work the Mattermost to Rocket.Chat migration takes and what a quote should cover. Read each row as a question to answer before scoping, since data volume, integrations, identity design and target architecture affect different phases. The main takeaway is that parallel-run scope and the paid plan are often settled late, so ask for both to be priced in the written scope.
| Driver | Effect on effort | What to ask for in a quote |
|---|---|---|
| Workspace size and message history | Larger exports lengthen conversion, test imports, validation and fix cycles | Export sizing, number of test imports on a copy, and the validation method |
| Channels and direct messages to map | Each channel needs a target, membership rule and archive decision; direct messages need a policy | Mapping workshop scope, and whether archived, private and direct messages are in scope |
| Integrations and bots to rebuild | Mattermost webhooks, slash commands and bot accounts must be rebuilt or retired for Rocket.Chat | A written inventory with counts, and which items are rebuilt, replaced or retired |
| Identity design (SSO, AD/LDAP, group mapping) | Directory sync and group mapping add configuration, testing and user-matching work | Identity source, sync scope, and whether group mapping is needed at go-live |
| Concurrent users and target architecture | Rocket.Chat's reference guidance covers one instance up to 500 concurrent users; multi-instance designs start above that | Peak concurrent user count from current metrics, and whether multi-instance is in scope |
| Paid plan features chosen | Starter caps users at 50; higher user counts and features such as audit trails and failover need a paid plan | The plan tier matched to required features, with the license terms stated |
| Air-gapped or compliance constraints | Air-gapped deployment is a paid-plan capability and adds offline update and evidence work | Whether air-gapped operation, offline upgrades and evidence collection are in scope |
| Parallel-run days | Running both platforms adds dual communication, sync decisions and rollback planning | Parallel-run length, cutover criteria, and who approves the switch |
| User training | Users need orientation to Rocket.Chat clients, notifications and retention changes | Number of user groups, training materials, and delivery format |
What usually goes wrong and how to prevent it
The failures below tend to share a cause: the plan was tested on a sample instead of full data, or operating decisions were left until cutover week. Each card names the prevention step and the team that should own it before the migration starts.
Incomplete exports found too late
Conversion errors often surface during the final import, when there is the least time to fix them. Run the full Mattermost export through the CSV conversion on a copy of production data, then reconcile user, channel and message counts against the source. Also verify timestamps, time zones and attachment references, since missing files are easy to miss in a count-only check. Owner: migration lead, with sign-off from the owner of each channel group.
Identities that do not match
Mattermost users must be matched to Rocket.Chat accounts through a shared identifier such as email or username. Mismatched identifiers create duplicate people, orphaned history or messages attributed to the wrong account. Decide the matching rule, the mapping file format and the treatment of inactive accounts before conversion, and confirm the import behavior in the import documentation. Owner: identity engineer, with the directory owner approving joiner and leaver rules.
Integrations that fail quietly at cutover
Bots, incoming webhooks, slash commands and scripts that call the Mattermost API keep pointing at the old workspace after cutover. Their failures can go unnoticed in Rocket.Chat and appear only in the source system's logs or in a missed alert. Inventory every integration before cutover, record its owner and target, then repoint each one in a test workspace and confirm delivery with a test message. Owner: integration owner for each system, coordinated by the platform team.
Database prerequisites not met
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. A target built on an older database or a standalone instance can be blocked at install or upgrade time, after the schedule is set. Confirm the database version, replica set layout and deployment method against the system requirements before the build starts. Owner: platform or database engineer.
Parallel-run rules that split conversations
During a parallel run, people keep posting in whichever platform they open first, so one conversation can end up divided across two workspaces. Record which platform is authoritative for each channel group and the date each group moves, then publish that rule before the parallel run starts. Set each Mattermost channel to read-only once its group has moved, and name a contact for exceptions. Owner: migration lead, with a champion in each business unit.
Target version nearing end of life
Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. An unsupported version receives no security or bug fixes and may lose the ability to connect with the official mobile and desktop clients. Choose the release line by its support window and the upgrade cadence your team can sustain, then schedule the first upgrade before go-live. Owner: platform owner, with the change board approving the upgrade calendar.
Questions buyers ask before hiring outside help
How much does a Mattermost to Rocket.Chat migration cost?
The cost follows from the written scope, and DeployOpen does not publish a price list. The main components are discovery and export analysis, conversion of the Mattermost export into Rocket.Chat's CSV format, user and channel mapping, test import runs, integration rework, cutover support and handover documentation. Most of these are one-time costs. Recurring costs sit mostly with you: hosting, MongoDB 8.0 running as a replica set, and any paid Rocket.Chat plan, which Rocket.Chat prices by quote. Ask for a quote that lists each component separately, states who performs each task, names the number of import rounds included, and says which integrations are in scope. Ask the vendor for current plan pricing before you compare totals.
How long does moving a workspace from Mattermost to Rocket.Chat take?
No fixed duration applies to every workspace, because the timeline depends on drivers you can measure. The main drivers are the number of users, channels, direct messages and attachments in the export, how many integrations and bots must be rebuilt or replaced, how many identity sources feed the new platform, whether a non-production environment exists for test imports, and how long your approval and cutover windows are. Teams with clean exports and few integrations finish faster than teams with years of history and custom bots. Ask for a written plan that ties each phase to these drivers, with the dependencies and client decisions that could move the dates.
What do we need to provide before a Mattermost migration starts?
Before work starts, you need to provide the Mattermost export and confirm that it contains the data you expect to move. You also need a current user list with identity details, a list of channels and their owners, and named owners for each integration, webhook and bot. Decision makers should agree on which history to keep, how to treat deactivated users and direct messages, and the cutover date. A non-production environment is strongly useful, because test imports should run before anything reaches production. Ask the partner to confirm this list in the written scope, including who on your side signs off each phase.
Can our internal team migrate from Mattermost to Rocket.Chat alone?
Yes, a small workspace run by a team with strong administration skills can often migrate without outside help. The team needs Linux administration, container or Kubernetes skills for the Rocket.Chat deployment, MongoDB replica set administration, scripting ability to convert and validate the CSV data, identity administration for SSO and user provisioning, and enough Mattermost knowledge to read the export. Testing skills matter as much as build skills, because the team must compare user counts, channel membership and sample messages before cutover. Larger workspaces, many integrations or tight cutover windows usually justify a partner for part of the work.
Do Rocket.Chat's free plan user limits affect the migration decision?
They can, depending on how many people use the workspace and which features you need. Rocket.Chat's 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. Count your active users and peak concurrent sessions before you choose a plan, and compare them with the Rocket.Chat plans documentation. Air-gapped deployment is a paid-plan capability and is not available on Starter, so confirm that requirement early if your network is isolated.
What do Rocket.Chat's paid plans add for SSO group mapping and audit trails?
Rocket.Chat's paid plans list LDAP and SAML user group mapping, which lets your identity provider assign users to groups that drive access in Rocket.Chat. They also list tamper-evident audit trails covering messages, files and sessions, and built-in redundancy with automated failover. Starter already includes single sign-on and LDAP or Active Directory authentication, so group mapping and audit trails are the main reasons to move to a paid tier for many organizations. Confirm current feature availability on the Rocket.Chat pricing page and in the plans documentation, because paid plans are priced by quote and feature lists change between releases.
Who handles Rocket.Chat upgrades after the migration goes live?
Upgrades are an ongoing operating task, and the owner must be named before go-live. Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Rocket.Chat also says unsupported versions may lose the ability to connect with its official mobile and desktop clients. Your team can perform upgrades on a planned schedule, or you can arrange a support retainer that covers upgrades and maintenance. Ask any partner to write the upgrade responsibilities into the scope.
How DeployOpen scopes, delivers and supports the migration
DeployOpen plans and runs Mattermost to Rocket.Chat migrations inside infrastructure you control. Each engagement starts with a written scope that records which users, channels, messages, files and integrations move, what is rebuilt by hand, and how both platforms run during cutover. Ongoing support is available as a retainer.
How we scope
- The written scope lists the Mattermost workspace, teams, channels and history that will be converted and imported.
- It records how users map to Rocket.Chat accounts, including identity source and which accounts are deactivated or recreated.
- It names the items that will not carry over, such as integrations, bots and settings, and who rebuilds them.
How we build
- We convert a Mattermost export into the CSV format Rocket.Chat's importer expects, then test the conversion on a copy of the data.
- We confirm the Rocket.Chat version and MongoDB replica set topology in your environment before importing anything.
- We run timed test imports and check user, channel, message and file counts against the source before cutover.
How we hand over
- Handover includes the conversion scripts, mapping tables, import logs and a record of every item that did not migrate.
- Runbooks cover the cutover sequence, rollback steps and how both platforms run side by side during the transition.
- Your team receives documentation for operating the Rocket.Chat instance and a list of the decisions that were agreed in writing.
How we support
- Support after cutover covers issues that appear once users work in Rocket.Chat, agreed in the written scope.
- Ongoing support, upgrades and testing are available as a retainer, which suits teams that must keep pace with Rocket.Chat releases.
- We help you plan the upgrade path so the instance stays on a supported version, since unsupported versions lose security fixes and client connectivity.
