How to migrate from Rocket.Chat to Mattermost without losing the history that matters
If your team runs a self-hosted Rocket.Chat and wants to move to Mattermost, Mattermost documents a migration path built on a MongoDB dump, the mmetl transformation tool and the mmctl command-line client. That path is best effort, and manual adjustments are often required, so plan the move as a staged project with checkpoints and a fallback, and give verification as much attention as the import itself. Rocket.Chat offers no hosted export feature, so the work starts with you taking the database out of your own environment. Keep the source instance frozen or read-only during the dump, and record the exact Rocket.Chat version you exported from, because you will need that record when you troubleshoot the transform. Decide early who runs the commands, where the dump is stored and how access to that copy is controlled, since the dump contains every message and file reference your organization has written.
Mattermost's documented path brings users, channels, messages, threads, direct messages, reactions and file attachments into the new server. Those are the items most teams mean when they say history, so build your acceptance list around them. For each category, pick a sample channel, a long thread, a direct message between two people who have since left, and a message with an attachment. Confirm that each one appears in Mattermost with the correct author, timestamp, channel membership and attachment. Write down every gap you find, because those gaps become your list of manual adjustments and your input for deciding what can be retired.
Start with mmetl transform rocketchat --dry-run against a copy of the dump to see what the transform would produce before any bulk import file reaches the target. Mattermost advises larger deployments to plan multiple trial runs in staging, and each run should use the same dump, the same mmetl and mmctl versions and the same target settings so that differences between runs can be explained. Keep a log for every run that records the users and channels mapped, the errors reported and the corrections you applied by hand. A run that produces the same result twice is stronger evidence for cutover than one run that looks clean.
The effort depends on four factors. Data volume drives how long the dump, transform and import take and how many runs fit in your change window. Custom integrations, including bots, webhooks and apps built on Rocket.Chat, need their own migration plan on Mattermost. Identity setup decides how users are mapped and how they sign in, and it must be settled before people log in to the new server. The number of trial runs your staging environment needs completes the picture. If you want SSO or AD/LDAP user sync on Mattermost, confirm the plan level first, because the Mattermost pricing page lists those features from the Professional plan. This page does not state a price or duration. Ask any partner, including DeployOpen, to tie each of these four factors to a written scope before agreeing on timing.
Which Rocket.Chat data and features map to Mattermost and which need rework
This table compares Rocket.Chat data and features with their Mattermost counterparts. The middle column shows what the documented path brings across, and the last column shows what a team should plan, test or confirm in a staging run. The main takeaway is that core conversation data follows the documented path, while identity, apps, Omnichannel, clients and paid-plan features need confirmation or rebuild.
| Rocket.Chat item | Mattermost after migration | Treatment |
|---|---|---|
| Users and channels | Brought in through the documented MongoDB dump, mmetl transform and mmctl import path | Documented. Verify membership, names and visibility in the trial run |
| Messages and threads | Brought in through the documented path, including thread structure | Documented, but manual adjustments are often required. Spot-check long threads |
| Direct messages and reactions | Brought in through the documented path | Documented. Confirm reactions and group direct messages display correctly after import |
| File attachments | Transformed with attachments for upload and processing with mmctl | Documented. Confirm file storage location and access, especially for high availability |
| Identity and user groups | SSO (SAML, OIDC, OAuth) and AD/LDAP sync included from the Professional plan, per Mattermost pricing | Rebuild. Recreate Rocket.Chat LDAP and SAML group mapping and test sign-in |
| Apps, Marketplace and bots | Not covered by the documented data path | Rebuild or replace. Inventory each app and confirm a Mattermost integration exists |
| Omnichannel | No documented equivalent in the supplied migration path | Confirm with Mattermost before planning. Expect a rebuild of routing and agent workflows |
| Mobile and desktop clients | Users need Mattermost clients connected to the new server | Confirm client support and plan user communication and login steps |
| Audit trails and automated failover | No direct import of Rocket.Chat audit records. High availability requires the Enterprise plan or higher | No direct import. Confirm retention, legal hold and failover needs against your Mattermost plan |
Documented tools for moving Rocket.Chat data into Mattermost
Rocket.Chat does not offer a hosted export, so the documented path starts by reading the database directly. The four tools below run in order, and each one produces an artifact that the next step depends on, so a gap at any stage shows up later as a failed or partial import.
Dump the Rocket.Chat MongoDB database
The first step is a mongodump of the database behind your Rocket.Chat instance, which is the source of users, rooms, messages, threads and file references. Take the dump from a consistent copy, not from a live server under heavy write load, and record the Rocket.Chat and MongoDB versions alongside it. Confirm that the dump includes every database your instance uses, because a partial dump will import without an error and leave history missing.
Validate with mmetl dry run
The mmetl tool reads the dump with the transform rocketchat command, and the --dry-run flag checks the source without writing the output file. Use it to find data that mmetl cannot map, such as unexpected user records or channel types, before you commit to a full transform. Keep the dry-run output with your migration record, since it is the first evidence of what the migration will and will not carry over.
Review the bulk import file
A full mmetl transform produces a bulk import file in the JSONL format that Mattermost reads, along with any attachments it references. Review the file before upload: check user email addresses, team and channel names, and whether message timestamps and thread structure look correct. Mattermost describes the Rocket.Chat migration as best effort and says manual adjustments are often required, so plan time to correct records in this file rather than fixing them after import.
Upload and process with mmctl
The mmctl command-line client uploads the bulk import file to your Mattermost server and starts processing. Run it against a staging server first, and confirm that the target server runs the Mattermost version your plan specifies. Record the processing output, including skipped or failed records, because those lines identify the data that needs manual work. Users, channels and messages are then checked against your source to decide whether to repeat the run.
Rocket.Chat import tools are not this path
Rocket.Chat's import tools accept Slack exports, Slack users from CSV and a generic CSV importer, which move data into Rocket.Chat. They do not read a Rocket.Chat database and do not produce a Mattermost import file, so they cannot serve as an export route for this migration. Keep them out of the plan, and confirm with your team that no one expects a Rocket.Chat-side export button, because Rocket.Chat does not provide a hosted export feature.
What the Rocket.Chat export needs before transformation
Confirm the source database version and topology before anything else. The documented path starts with a mongodump of the Rocket.Chat database, and Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set. If your source runs that version, you need access to the replica set so the dump can be taken from it. If your source runs an earlier release, plan the upgrade on the Rocket.Chat side first. Confirm the exact MongoDB minimum and any tool compatibility points against the current Mattermost migration documentation, because that guidance can change between Mattermost releases.
Decide how consistent the snapshot must be. A dump can represent a quiesced instance or a point in time. Quiescing means stopping writes, usually by putting Rocket.Chat into maintenance mode or stopping its application servers, so messages, reactions, threads and channel memberships line up with each other. Accepting a point-in-time copy keeps the service running, but messages sent during the dump may be missing from the import. The business owner should accept that gap in writing. Record the exact time of the dump and confirm with the migration documentation which records must be consistent with one another.
Plan disk space for three separate outputs. The dump, the bulk import file that mmetl writes, and the working area that mmctl uses during processing all need room on the transform host. Attachment files add to this total. No sizing figures are given here, so ask the Mattermost team or confirm against current migration guidance how much headroom the transform needs relative to database size. Measure the database and attachment store first, add margin, and use a staging volume separate from production storage so a failed run cannot fill production disks.
Make sure the transform can reach attachments. Attachments depend on where your instance stores uploads. If uploads are held inside the database, the dump carries them. If they sit on a file system or in an object store, the transform host needs read access to that location, either at the same paths or through a mapping you define. Confirm the storage backend, list every path or bucket, verify credentials on the transform host, and copy a sample file to confirm it resolves. Attachments that cannot be reached tend to surface only after import, so test this before the first run.
How the migration runs from inventory to decommission
The sequence moves Rocket.Chat history into a staged Mattermost, proves the result with the people who use it, and retires the old platform only after cutover and a recorded retention decision. Each stage closes with a written output that the next stage depends on.
Inventory users, channels, integrations and retention needs
Your team lists every active user, public and private channel, direct message scope, integration and file store in the Rocket.Chat workspace, then records which data must be kept, for how long, and under whose policy. The documented path covers users, channels, messages, threads, direct messages, reactions and file attachments, so integrations need a separate keep, replace or retire decision. Security, legal and channel owners approve the list. The output is a written inventory and retention brief that defines what the import must preserve. The step is done when those owners have signed it.
Export the Rocket.Chat MongoDB database
Because Rocket.Chat has no hosted export feature, a platform engineer takes a dump of the MongoDB database with mongodump from a consistent copy, not from live writes. Agree the timing with business owners and store the dump under the same access controls as the source. Record the date, source Rocket.Chat version and a checksum so the dump can be matched to the inventory. Confirm the exact command options in Mattermost's Rocket.Chat migration guide for your version. The output is a dated, verified dump that the conversion step can read.
Run a dry-run check on a copy
The engineer runs the mmetl Rocket.Chat conversion in dry-run mode against a copy of the dump, so the original stays unchanged, and reviews every warning it reports. Mattermost describes this migration as best effort and says manual adjustments are often required, so each warning is matched to an inventory item and an owner. Fixes go into the source data or the conversion inputs, and the dry run repeats until the output is understood. The output is an issue log with owners and resolutions. The step is done when the team agrees which remaining warnings are acceptable.
Import into staging and repeat trial runs
Run the full conversion into a bulk import file, then import it into a staging Mattermost with mmctl on a server configured like the planned production environment. Mattermost advises larger deployments to plan multiple trial runs in staging, so repeat the conversion and import after each set of fixes and log every error. Keep the import logs and the record of which dump each run used. The output is a trial run log that identifies the final run to rehearse for cutover. The step is done when the team can run the whole sequence from a dump without manual edits.
Check messages, threads, DMs, reactions and files
Named testers from each department sign in to staging and compare messages, threads, direct messages, reactions and file attachments with the source workspace. They also check user accounts and channel membership against the inventory. Channel owners choose the sample conversations, including long threads and files of several types, and the team uses a fixed checklist so results are comparable across trial runs. Each defect is logged, fixed and retested. The output is a signed acceptance record of passed checks, open defects and approved exceptions. The step is done when business owners accept the results.
Plan and run the parallel period
Running both platforms for a period is a planning choice that the documented tools do not automate. The team decides how long both stay available, which platform is the record for each group, and what fallback applies if a problem appears. Communicate dates, login steps and where to post to users in advance, and repeat the message through the period. Support staff track questions and issues in one queue. The output is a parallel-run plan with owners, a communication schedule and an exit criterion. The step is done when the criterion is met and leaders approve cutover.
Cut over and handle the final delta
Agree a write freeze in Rocket.Chat for the cutover window, export the database again, and convert and import it to capture messages, files and membership changes made since the earlier dump. Handling this final delta is a planning choice that the documented tools do not automate, so the team designs how changed records are identified and loaded before the window opens. Compare counts and sample conversations against the source, then point users to Mattermost. The output is a cutover record with import logs and sign-off. The step is done when delta checks pass.
Decommission Rocket.Chat after the retention decision
Once the retention decision is recorded, archive the Rocket.Chat database and file store under the policy the owners approved, then make the instance read-only or shut it down. Remove its DNS entries, integrations and admin access. Test that the archive can be restored before deleting anything. Until shutdown, keep the instance on a supported Rocket.Chat version, because unsupported versions receive no security fixes. The output is a decommission record listing the archive location, the retention basis, access removal and the shutdown date.
What makes a Rocket.Chat to Mattermost migration larger or smaller
This table lists the factors that make a Rocket.Chat to Mattermost migration larger or smaller, with the effect of each and what to ask for in a written quote. Read the one-time work (dumps, transforms, trial runs, rebuilds and training) separately from recurring costs such as the annual seat-based subscription, hosting and upgrades. The main takeaway is that identity, high availability and trial-run count often shape scope as much as raw data volume.
| Driver | Why it changes effort or cost | What to ask for in a quote |
|---|---|---|
| Message, file and attachment volume | Larger MongoDB dumps and attachment sets lengthen the dump, transform and import steps, and every trial run repeats them. | Dump size, attachment storage size and the timing of each staging run |
| Channels and direct messages | More channels, direct messages and threads mean more mapping and more post-import checks of membership and access. | Channel and direct message counts, and the post-import check plan |
| Identity and SSO design | Mattermost lists SSO (SAML, OIDC, OAuth) and AD/LDAP sync from the Professional plan on its pricing page, and user matching affects login and duplicate accounts. | Plan level that includes SSO and AD/LDAP sync, and the user matching approach |
| High availability design | HA requires the Enterprise plan and shared file storage on S3, an S3-compatible service or NAS, so migrated attachments must land on that storage. | Plan level for HA, shared storage sizing and the attachment path configuration |
| Number of trial runs | Mattermost calls the Rocket.Chat migration best effort, often needs manual adjustment, and advises larger deployments to plan multiple staging runs. | Number of staging runs included and the acceptance checks for each run |
| Custom integrations and bots | Each integration, webhook or bot that the import does not carry over must be rebuilt and retested against Mattermost. | Inventory of integrations and bots, and which ones the import carries |
| Retention and legal hold | Retention and legal hold rules decide what must be imported, how the source database is preserved and which archive copies are kept. | Which retention and legal hold features the chosen plan includes |
| User training | Users moving from Rocket.Chat need guidance on the Mattermost client, commands and admin tools, and new hires need the same onboarding later. | Training materials, sessions and who delivers them |
| Recurring run costs | The subscription is prepaid annually by seat count, and hosting and monthly server upgrades continue after cutover. | Annual subscription by seat count, hosting assumptions and upgrade support terms |
What changes for users and administrators after cutover
Users will notice the change first in the apps they open every day. Mattermost runs at its own server address, so each person must sign in to the new URL through the web app, desktop app or mobile client your deployment supports, and any saved Rocket.Chat connections should be removed. Confirm which client versions your users run before cutover so that sign-in and notifications work on the first day. Expect differences in how some threads and reactions display after import. Mattermost describes the Rocket.Chat path as best effort and says manual adjustments are often required, so review a sample of busy channels and long threads in the trial run and decide what users should be told before go-live.
Some Rocket.Chat behavior will not carry over unchanged, either because Mattermost provides it differently or because it depends on a plan level or extra service. Before cutover, list every Rocket.Chat capability your teams rely on, such as LDAP or SAML group mapping, audit trails, retention settings or read receipts, and check each one against the Mattermost plan and feature documentation. Integrations are a separate task. Bots, webhooks, slash commands and other connected apps still point at the old server, so each one must be recreated, reconfigured or re-authorized against Mattermost. Assign an owner for each integration and confirm it works in staging before the old instance is retired.
Administrators take on a different maintenance rhythm. Mattermost publishes new server binaries on the 16th of each month, so the upgrade calendar should be built around that date, with a named approver for each release and a staging run before production. For a steadier production footing, plan around the Extended Support Releases. Mattermost v11.7 is an ESR released on 2026-05-15 with support ending 2027-05-15, and v10.11 reached end of life on 2026-08-15. Record the support end date of the line you run and schedule the move to the next ESR well before the current one expires.
The database also changes. Mattermost runs on PostgreSQL, so the data imported from the Rocket.Chat MongoDB dump will live in PostgreSQL, and its backup, restore and major version upgrades become your responsibility from the first day. If you choose high availability, which Mattermost offers only on the Enterprise and Enterprise Advanced plans, every application node must mount shared file storage, such as Amazon S3, an S3-compatible service or NAS. Mattermost warns that local file system storage will not work correctly in a cluster and risks corrupting files. Confirm the storage design, the backup approach for both the database and the files, and the plan tier before cutover.
What usually goes wrong in chat migrations and how to prevent it
Rocket.Chat to Mattermost migrations rarely fail in one dramatic step. The problems tend to surface quietly: incomplete output, files that no longer resolve, identities that do not line up, and drift between the source and target over the life of the project. Each card below names one of these risks and the check that prevents it.
Treating best-effort output as complete
Mattermost describes the Rocket.Chat migration as best effort and says manual adjustments are often required. The transformed import file reflects what the tool could map, not a guarantee that every message, thread and setting arrived intact. Before go-live, sample channels, direct messages, threads and reactions against the source, and ask the team that owns each channel to sign off on their own history.
Skipping dry runs and staging trials
The documented path validates the MongoDB export with mmetl transform rocketchat --dry-run before any data is written. Mattermost advises larger deployments to plan multiple trial runs in staging. Run the full sequence of mongodump, transform, import and verification on a copy of production at least once, record every warning, and treat a clean run as the precondition for scheduling cutover.
Missing attachments and broken file references
File attachments are part of the migrated content, and the transform step must map each stored file to a path the Mattermost import can read. Missing or unreadable files show up as broken links that users only find weeks later. Compare file counts and total size between the Rocket.Chat file store and the Mattermost file storage, and open a sample of old attachments in each channel type after import.
Mismatched identities and duplicate accounts
If Mattermost creates accounts that differ from the users in Rocket.Chat, by email address, username or authentication method, the same person can appear twice and authorship of old messages can point to the wrong account. Decide the identity key before the trial, align it with your SSO or AD/LDAP source where Mattermost supports user sync on your plan, and check for duplicate emails and usernames in the transformed user list.
Integrations and bots not carried over
Rocket.Chat apps, webhooks, bots and outgoing integrations do not move with the message history. Their endpoints, tokens and any scheduled posts must be rebuilt in Mattermost and tested on their own. Inventory every integration in the source, record who depends on it, and assign an owner to each replacement before cutover so that alerts and automated posts do not silently stop.
Rocket.Chat version drift during the project
Rocket.Chat releases new versions on a regular cadence, and standard releases get six months of support while LTS releases get twelve. A source system that is upgraded mid-project can change the MongoDB schema and the exported data the transform expects. Pin the Rocket.Chat version used for the export, record it in each trial run, and confirm the support end date for that line before the migration plan is approved.
Cutover without a delta plan
Messages sent in Rocket.Chat after the last full export will not appear in Mattermost unless the team plans for them. Define a freeze window, a final export, a delta import for messages created after the snapshot, and a rule for users who keep writing in the old system during the switch. Rehearse this delta step in staging so the downtime window is based on measured timings rather than estimates.
What to confirm with Mattermost and in your own environment
Several parts of this migration change over time or depend on your own environment, so verify them before you choose a target version or set a cutover date. Start with the Mattermost server release line. Mattermost ships server releases in binary form on the 16th of each month, and its server releases page lists current versions, Extended Support Releases and end-of-support dates. At the time this page was prepared, that page showed v12.0 with support ending 2027-01-15 and v11.7 as an Extended Support Release with support ending 2027-05-15. Check the page again on the day you decide. A target version close to end of support will need another upgrade soon after cutover.
Next, confirm plan entitlements in writing. Mattermost sells Professional, Enterprise and Enterprise Advanced as prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices. Verify which plan includes the features your migrated users will depend on, such as SSO and AD/LDAP user sync, high availability and FIPS 140-3 compliance. Ask the sales team whether a staging license is available for trial runs, how seats are counted, and what renewal terms apply. The answers determine whether the sign-in model you plan on day one is actually licensed.
Then confirm the source side. The transform step depends on the Rocket.Chat version and the MongoDB version in your dump. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set. Use the Mattermost Rocket.Chat migration docs to confirm which mmetl release supports your exact Rocket.Chat and MongoDB versions, and record that version pair in your runbook. Also check your source version on the Rocket.Chat version durability page. A source instance that is past end of life may hold data or configuration your team cannot fix with a vendor patch, which makes validation harder and should be treated as a scope risk.
Attachment handling and import limits need hands-on checks. Confirm how the transform treats file attachments in your export, where those files must be copied, and which storage path your Mattermost server reads. If you run a high availability cluster, the shared file storage requirement applies to migrated files too, so local file system storage will not work across nodes. Confirm the exact import size and file limits in the current Mattermost docs and in mmctl behavior. No limit is set out in this guide, so measure the largest channel and file set in your staging copy and compare the results with the documented limits before you commit to a window.
Finally, verify your own environment and record the results. Confirm that the transform host can reach the MongoDB replica set, that it has enough disk space for the dump, the bulk import file and any copied attachments, and that the target PostgreSQL instance is sized for the imported history. Assign an owner to each item, date each verification, and keep the evidence with the change record. Expect manual adjustments after the import, as Mattermost notes, and plan the trial runs in staging to surface them. Items you cannot confirm from the docs should be written down as open questions for Mattermost or your partner before the production run.
Questions buyers ask before migrating from Rocket.Chat
How much does migrating from Rocket.Chat to Mattermost cost?
Cost depends on the written scope, so the total cannot be stated in advance. Mattermost sells its server as prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices, directing buyers to contact sales. Recurring costs include that subscription and the servers, storage and backups you run in your own infrastructure. One-time costs include the export and conversion work, trial runs in staging, cutover, user communication and rework of any integrations you rebuild. DeployOpen quotes its work as a fixed scope agreed in writing, and ongoing support or upgrades can be added as a retainer. Ask for quote lines split into one-time and recurring items, the number of trial runs assumed, and the data types included.
How long does a Rocket.Chat to Mattermost migration take?
The duration depends mainly on data volume, the number of trial runs and how many manual corrections the converted data needs. Mattermost advises larger deployments to plan multiple trial runs in staging, so a larger instance needs more cycles before cutover. Each run covers a full database export, the mmetl dry run and conversion, the mmctl import and a review of users, channels, threads and attachments. Time spent mapping identities and deciding how to handle best-effort gaps also affects the schedule. Ask for a timeline built from a sized copy of your own database, a stated number of staging runs and a named cutover window, and confirm it in the written scope before work starts.
What does a Rocket.Chat migration need from our staff?
The migration needs named people, not only hours. Data owners decide which channels, direct message histories and file attachments move, and which can be archived or dropped. Identity administrators map Rocket.Chat accounts to the identity source Mattermost will use, so users can sign in cleanly after import. Someone with database access must run and protect the MongoDB dump, and someone must own the Mattermost server and PostgreSQL that receive the data. A sign-off owner must also accept the best-effort gaps listed in the dry-run and trial reports before cutover. Agree these roles, review dates and approval steps in writing at the start, so the people who own the data accept each gap before launch.
Can our own team migrate from Rocket.Chat to Mattermost without a partner?
Yes, a capable team can run the migration with the documented tools and planned trial runs. The path is sequential: dump the MongoDB database with mongodump, check it with mmetl transform rocketchat --dry-run, convert it into a bulk import file, then import it with mmctl. The steps are straightforward, but the review of converted data takes the most judgment. A partner helps most when your staff lack experience with both MongoDB and PostgreSQL, when you need a fixed schedule for cutover, or when you want the trial runs and sign-off documented as compliance evidence. DeployOpen plans, implements and documents this work under a written scope, so the decision is between your team's time and a defined set of deliverables.
Does everything in Rocket.Chat move into Mattermost?
No. Mattermost documents the Rocket.Chat path for users, channels, messages, threads, direct messages, reactions and file attachments. Anything outside those data types needs to be confirmed before you commit to a plan. Review your Rocket.Chat instance for other content your teams depend on, such as custom integrations, bots, apps, custom emoji or retention settings. Then ask Mattermost or your implementation partner which of these the documented path carries across and which must be rebuilt. The migration is also best effort, and manual adjustments are often required even for the supported data types. Record every known gap in the scope, decide who accepts each one, and plan how users will reach any content that does not move.
Can Rocket.Chat keep running during a Mattermost migration?
The documented path works from a database export, so your cutover plan decides how much activity can continue during the move. Messages written after the export will not appear in the imported data, so you need a plan for that gap before cutover. Confirm with Mattermost's documentation whether the dump should be taken with Rocket.Chat stopped or running, and how a later import would behave. One common approach is to make Rocket.Chat read-only for the final export, then direct users to Mattermost. If Rocket.Chat keeps running for a period, plan for its support as well. Rocket.Chat versions reach end of life on a published schedule, and after that they receive no security or bug fixes.
What usually breaks when importing Rocket.Chat data into Mattermost?
Failures usually come from data that does not map cleanly between the two systems. Check the mmetl dry run output first, because it reports problems the conversion finds before you import. Common areas to review include user identity mismatches, duplicate or renamed usernames and channel names, threads that lose their context, and file attachments that are missing or point to paths the import cannot reach. Permissions can also differ from what your teams expect after import. Because the path is best effort, some of these issues will need manual correction. Keep the MongoDB dump and each conversion output so every trial run can be repeated and compared, and log each failed record as an open item with an owner.
How DeployOpen scopes, runs and supports a Rocket.Chat to Mattermost migration
DeployOpen scopes the Rocket.Chat to Mattermost move as a written, fixed-scope engagement covering the export, transformation, import and verification steps. Because Mattermost describes this migration as best effort with manual adjustments often needed, we plan trial runs in staging before any cutover. The work runs inside your own infrastructure, and ongoing support is available as a retainer.
How we scope
- Inventory the Rocket.Chat version, MongoDB replica set and the users, channels, and file attachments in scope.
- Agree in writing which data moves, including threads, direct messages and reactions, and which data stays behind.
- Define the target Mattermost server, PostgreSQL database and deployment model before any export starts.
How we build
- Take a MongoDB dump in a controlled window and validate it with mmetl transform rocketchat --dry-run.
- Transform the export into a bulk import file, then import it with mmctl into a staging Mattermost server.
- Review imported users, channels, threads and attachments, and log each manual correction the import requires.
How we hand over
- Provide a runbook covering each dump, transform and import step, with the exact commands used in staging.
- Document the trial run results, open issues and manual adjustments so the production run is repeatable.
- Walk your administrators through the Mattermost server, user onboarding and post-cutover checks they will own.
How we support
- Agree on post-cutover support for the period your team needs, under a retainer if ongoing help is required.
- Plan later Mattermost upgrades against the monthly release cadence and Extended Support Releases before cutover.
- Keep Rocket.Chat retirement dates in view, since unsupported versions stop receiving security fixes.
