Migrate from Microsoft Teams to Rocket.Chat

Teams has no direct importer for Rocket.Chat, so chat history is extracted through the Graph Teams Export APIs, converted to CSV, and loaded alongside rebuilt channels, SSO and meetings. This page maps what moves, what needs rework and how to plan the cutover.

On this page

Migrate from Microsoft Teams to Rocket.Chat: what the move involves

Moving chat from Microsoft Teams to Rocket.Chat is a custom export, convert and import project, not a button click. Rocket.Chat has no Teams importer, so the history has to be pulled out of Teams with the Microsoft Graph Teams Export APIs, reshaped into the CSV format Rocket.Chat's importer accepts, and loaded into a workspace you have built and tested. Most organizations run this as a joint effort: an internal platform or IT team owns the target environment, identity and cutover decisions, and an implementation partner writes the conversion scripts and runs the test imports.

Effort and risk depend less on the chat volume than on how many people and conversations the export must cover. The Teams Export APIs require admin-approved application permissions and an active Teams license on every user whose content is exported, so confirm early which accounts are in scope, which are former employees, and whether any licenses will lapse before the export runs. Deleted content has its own recovery windows, which the export guide on this site covers. Ask the partner to show how they will handle channel and meeting content that the APIs return in different shapes, since a mismatch there is the most common source of broken imports.

Rocket.Chat is not a like-for-like replacement for Teams, so the rebuild matters as much as the data move. Plan channels, private groups and direct messages as separate import sets, decide how team membership maps to Rocket.Chat roles, and wire single sign-on through your identity provider before users arrive. Rocket.Chat's own documentation recommends splitting large exports into files under 15 MB, and its Slack importer is the closest reference for the expected layout, so budget time for test imports against a staging workspace. Meetings are rebuilt separately through a marketplace app such as Jitsi or BigBlueButton, not migrated, and recordings and transcripts should be retained in their own store. Ask any partner for a written scope that names each of these items.

Which Teams capabilities map to Rocket.Chat, and what needs rework

This table compares the main Teams chat and meeting capabilities with their Rocket.Chat equivalents and marks each as clean, needs rework or gap. Read the status column as a planning signal: clean means a direct equivalent exists, needs rework means the data or configuration must be reshaped during migration, and gap means you need a different tool or a paid plan. Meetings are the largest gap, since Rocket.Chat relies on marketplace apps for video.

CapabilityRocket.Chat equivalentStatus and what to plan
Channels and teamsPublic and private channels, with teams mapped to channel groups by conventionNeeds rework: Teams team membership must be recreated as channels and their members re-added in the target workspace
1:1 and group chatsDirect messages and multi-user private groupsNeeds rework: Graph export returns these conversations, but they must be converted to the CSV importer format and matched to imported users
Threads and repliesThreaded messages within channelsNeeds rework: confirm how reply chains render after conversion, since the importer flattens structure unless the source data carries thread references
File attachmentsUploaded files stored in the Rocket.Chat file storeNeeds rework: Teams files sit in SharePoint or OneDrive, so attachment links and any file copies must be planned separately
Meetings and recordingsNo built-in meeting service; video through marketplace apps such as Jitsi, BigBlueButton, Pexip or Google MeetGap: calls, scheduling and meeting recordings do not carry over, and recording links from Graph export become archive references only
SSO through Entra IDSAML and OIDC single sign-on on the Starter and paid plans, with LDAP and Active Directory optionsClean: confirm the Entra ID app registration, claim mapping and user matching before cutover; SAML user group mapping requires a paid plan
Retention and admin controlsRetention policies on Starter; tamper-evident audit trails and automated failover on paid plansNeeds rework: rebuild retention rules and admin roles from the Teams policies you rely on, and confirm which controls your plan includes
Mobile and desktop clientsOfficial Rocket.Chat mobile and desktop clients, which require a supported server versionNeeds rework: users must install the official clients and the server must stay on a supported release line to keep them connected

Which data moves through the Graph export and which integrations must be rebuilt

The Graph export carries chat history, not the whole Teams estate, and Rocket.Chat has no Teams importer. Each card below marks one piece of the move: what the export returns, what it requires, how identity and integrations are carried over, and what has to be rebuilt by hand.

Chat history the export returns

The Teams Export APIs in Microsoft Graph return 1:1, group, meeting and channel messages, along with links to meeting recordings and transcripts. Recordings and transcripts come back as links, not as media moved into Rocket.Chat, so plan where those files will live. Check which message types your tenant uses, since reactions, edits and attachment references may need separate handling in your converted files.

Admin-approved permissions and Teams licenses

The export uses application permissions that a tenant administrator must approve before any data is read. Every user whose messages you export must also hold an active Teams license, so former employees and departed guests may fall outside the export unless their licenses are still active. Ask your Microsoft 365 administrator to confirm the permission grant and license state for each user group before the export window opens.

CSV conversion for the Rocket.Chat importer

Rocket.Chat has no Teams importer, so the exported JSON must be converted into the CSV format its importer accepts. This conversion step is the core engineering work: mapping users, rooms, timestamps and thread replies correctly. Rocket.Chat's Slack importer is not a Teams path, and a Slack export file will not load Teams data. Test the converter on a small channel and check message order and thread structure before running a full import.

User identity through LDAP or SSO

Users must exist in Rocket.Chat under the same identities they had in Teams, or message authorship will not line up. Connect the workspace to your directory through LDAP or Active Directory, or through single sign-on, before the import so accounts match by email or username. Confirm with your identity team how deactivated accounts and shared mailboxes will be represented.

Bots, connectors and Power Automate flows

Teams bots, incoming and outgoing connectors, and Power Automate flows do not move with the message history. Each one must be inventoried and rebuilt as a Rocket.Chat integration, webhook or external service that posts into the same rooms. List every automation that posts alerts, approvals or ticket updates, and assign an owner who will test it after cutover.

Channel structure and access rules

Teams channels, private channels and team membership do not map one to one onto Rocket.Chat rooms, and access rules must be recreated. Decide which teams become public or private channels, who may create rooms, and how retention settings apply. Review membership lists against the directory after the import, because the converted rooms will not carry Teams permissions automatically.

The migration sequence from inventory to decommission

This sequence moves chat history out of Microsoft Teams and into a self-hosted Rocket.Chat workspace in controlled stages, so each step produces a record that the next one depends on. It ends with Teams exports and access removed only after users have confirmed the new workspace.

  1. Inventory teams, channels and retention needs

    The Teams administrator and the chat owners list every team, standard and private channel, shared channel, and 1:1 or group chat in scope, with its owner, active member count and any legal hold or records requirement. Compliance leads state how long history must be kept and where. The output is a channel map that assigns each Teams conversation a target Rocket.Chat channel, a private or public setting, and a retention decision. Done when every owner has signed off on their rows.

  2. Confirm Graph permissions and Teams licenses

    A Microsoft 365 administrator reviews which application permissions the Teams Export APIs in Microsoft Graph need and obtains admin approval for them. The exported users must hold an active Teams license, so the team confirms that for every mailbox in scope before extraction starts. The output is a written permission approval record that names the app registration, the scopes granted, the approver and the date, along with a list of users whose licenses are confirmed. Done when the approval record is filed with the migration plan.

  3. Stand up the Rocket.Chat pilot environment

    DeployOpen or the internal platform team deploys a non-production Rocket.Chat instance in the client's infrastructure with MongoDB 8.0 or later running as a replica set, and configures authentication, backups and the version the team intends to run in production. The team confirms the chosen release line is still supported, since standard releases get six months of support and LTS releases get twelve. The output is a tested environment and a record of the version and settings, checked against the official system requirements. Done when a test user can sign in and post.

  4. Pilot with a few channels and users

    A small group of channels and their members moves first. Their history is extracted through the Graph Teams Export APIs, converted to the Rocket.Chat CSV format, and imported through Manage, Workspace, Import. Pilot users check that messages, threads, attachments and channel membership look right and report gaps. The output is a pilot defect list with a fix or accepted-loss decision for each item, and sign-off from the pilot channel owners. Done when every pilot owner confirms the imported content matches their expectations.

  5. Export and convert the full history

    The migration engineer runs the Graph exports for the remaining channels and chats and converts the output into the Rocket.Chat CSV format, following the channel map and the pilot fixes. Large exports are split into files under 15 MB, as Rocket.Chat recommends for its Slack import path, and each file keeps a checksum and a source reference. The import runs file by file, and the import log records the file name, the record counts and any rejected rows. Done when every file has a completed import entry and every rejected row has a disposition.

  6. Run Teams and Rocket.Chat in parallel

    Users keep Teams for their normal work while the team tests Rocket.Chat with live channels, and the owners agree on a set of channel pairs to watch during this period. Staff check that SSO, notifications and mobile or desktop client connections work against the production instance, and the platform team tracks issues in a shared log. The output is a parallel run log and a go or no-go decision from each channel owner. Done when the owners of all in-scope channels have recorded a go decision.

  7. Cut over users and clients

    Users are moved to Rocket.Chat in the order agreed during the parallel run, and new posts go to the new workspace only. The team sends users the sign-in details and the client download instructions, and the Teams channels are set to read-only with a pointer to the new channels. The output is a cutover checklist per group with the date each group moved and any users who need help. Done when every group is confirmed on Rocket.Chat and no new working messages are going to Teams.

  8. Decommission Teams exports and access

    Once the retention period in the inventory is met and the archived Teams copies are verified, the team revokes the Graph application permissions, removes the app registration or its secrets, and deletes the working export files under the agreed retention rules. The export and import logs, the permission record and the final sign-off from compliance are kept as evidence. The output is a decommission record that shows access was removed and what was kept. Done when the record is signed by the Teams owner and compliance lead.

How the Teams export becomes a Rocket.Chat import

The conversion path is the part of this migration that has no ready-made tool, so plan it before anyone touches production. The Microsoft Graph Teams Export APIs return messages per conversation: channel messages, 1:1 and group chats, and meeting chats, each with sender, timestamp and reply structure. Nothing in that output is in Rocket.Chat's format, so your team must write or script a converter that turns each conversation into the CSV layout Rocket.Chat's importer expects, with one row per message, a consistent channel name and a resolved user for every sender. Confirm the exact column layout against the current import documentation for your Rocket.Chat version, because the importer rejects files it cannot parse.

Mattermost's Slack tooling does not apply here. The mmetl converter reads Slack exports, so it cannot read Graph output, and Rocket.Chat's Slack import path is aimed at Slack exports as well. Treat the converter as custom work with its own test cases. Split large outputs into files under 15 MB, as Rocket.Chat recommends in its import documentation, and keep attachments in a separate, traceable set of files so that a failed chunk can be re-run without duplicating messages.

Two checks decide whether the import is trustworthy. First, user mapping: every Teams identity must map to exactly one Rocket.Chat account, ideally keyed on a stable identifier such as the directory object ID rather than display name, and unmapped senders must be listed for a human decision. Second, timestamps: confirm that messages keep their original times and time zones, and that imported history does not appear as if it was posted today. Load the first chunks into a test instance, sample threads and attachments against the source, and only then schedule the production run. Ask the team who will sign off on those samples, because nobody else can judge whether the history is complete.

What drives the cost and duration of the move

This table lists each cost component of moving Teams chat to self-hosted Rocket.Chat, who is paid for it, whether it is one-time or recurring, and what changes its size. Use it to build a request for quote, since no Rocket.Chat or DeployOpen price is stated here and the main takeaway is that channel count, history depth and identity scope drive most of the effort.

Cost componentWho is paid or who spends timeOne-time or recurringWhat raises or lowers it, and what to request in a quote
Discovery and channel mappingImplementation partner and Teams ownersOne-timeChannel count, private channels, guest access and shared channels raise effort. Request a channel inventory and a written decision for each team to become a Rocket.Chat channel, private group or retired item.
Export engineeringImplementation engineer with Graph accessOne-timeHistory depth, number of 1:1 and group chats, and meeting transcripts raise effort. Ask for the admin-approved application permissions needed, confirmation of active Teams licenses on exported users, and how deleted content is handled.
CSV conversionImplementation engineerOne-time, plus rework on each test runMessage volume, threads, reactions, attachments and mentions raise effort. Ask how the conversion maps users, channels and direct messages to Rocket.Chat's CSV importer and how large files are split under the recommended 15 MB limit.
Rocket.Chat hostingYour cloud account, data center or air-gapped network, and the platform teamRecurringUser count and concurrency set the architecture: a single instance with a MongoDB replica set suits up to 500 concurrent users, and multi-instance or microservice designs need a paid plan. Ask for the reference architecture they recommend and the plan that covers it.
MongoDB replica setYour database team or the managed service provider you chooseOne-time setup, recurring operationRocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and three members are strongly recommended for high availability. Ask for backup, restore and failover tests, and who patches the database.
SSO and identity workIdentity team and implementation partnerOne-time build, recurring group maintenanceLDAP, Active Directory, SSO and MFA are available on the free Starter plan for up to 50 users, while SAML group mapping sits in paid plans. Ask which identity provider is in scope and how Teams group membership maps to Rocket.Chat roles.
Meeting integrationImplementation partner and your meeting platform ownerOne-time, plus recurring licensing for the chosen video serviceRocket.Chat does not include a built-in meeting service, so calls depend on a marketplace app such as Jitsi, BigBlueButton, Pexip or Google Meet. Ask which app is supported, its hosting model and whether recordings and calendar invites are in scope.
User training and communicationsInternal change and communications staff, plus the implementation partner for materialsOne-time, with a short support tailNumber of users, mobile and desktop client rollout, and differences in threads and notifications raise effort. Ask for training materials, a cutover checklist and the support window after go-live.
Internal staff time and upgradesPlatform owners, security and service desk staffRecurringRocket.Chat supports standard releases for 6 months and LTS releases for 12 months, and unsupported versions can lose mobile client connectivity. Ask for an upgrade plan, who approves it, and whether a retainer covers upgrades and testing.

What usually goes wrong in a Teams to Rocket.Chat move

Most failed Teams to Rocket.Chat moves break at predictable points: the export, the identity mapping, the platform version and database sizing, and the cutover itself. Each card below names one failure and the check that prevents it before users are moved.

Missing history from permissions and deleted content

The Teams Export APIs only return content when an administrator has approved the application permissions and every exported user holds an active Teams license. Accounts without a license, or content deleted beyond the retention window, will silently drop out of the extract. Before the export starts, confirm the permission grant with your Microsoft 365 administrator and reconcile message counts per channel against a sample taken in the Teams client. Record any gaps in the migration log so they are not discovered after users have left Teams.

Entra ID and Rocket.Chat identity mismatches

Rocket.Chat matches imported users to accounts by username and email, so a Teams display name, a changed UPN or a guest account can create duplicate or orphaned identities. Map each Entra ID user to a single Rocket.Chat account before import, and decide how external and guest users are handled. Configure single sign-on and LDAP or SAML group mapping in a test workspace first, then confirm that a migrated user signs in to the existing account and sees the expected history.

Unsupported Rocket.Chat versions

Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. After end of life, a version receives no security fixes, cloud services such as the push notification gateway stop working, and the official mobile and desktop clients may no longer connect. Choose an LTS line deliberately, record its end-of-life date, and schedule upgrades as recurring operational work rather than a one-time project.

Under-sized MongoDB replica sets

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 single node or an undersized primary will fail during bulk import and then struggle under daily load. Size the database tier against the reference architecture for your user count before importing, and run the import in a staging copy so that index build time and storage growth are measured rather than guessed.

Users continuing in Teams during parallel run

If a parallel run has no end date, people keep posting in Teams, and the Rocket.Chat workspace becomes a partial copy of the conversation. Set a freeze date for Teams channel creation and posting, announce it in both systems, and run a final incremental export after the freeze. Agree in advance who owns the decision to reopen Teams for a specific group if a critical workflow depends on it.

Meeting links breaking at cutover

Teams meeting URLs, recording links and calendar invitations point to Microsoft services and will not resolve once users move. Rocket.Chat does not provide a built-in meeting service, so video runs through a marketplace app such as Jitsi, BigBlueButton, Pexip or Google Meet. Inventory recurring meetings and external links, replace them with the new meeting endpoint, and confirm that the chosen app works with your single sign-on before the cutover date.

How the migration changes by team size and starting point

Small teams that stay under about 50 users can start on the free self-managed Starter plan, which includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. The migration is mostly a planning exercise: you extract Teams history, convert it, and import it into a single Rocket.Chat instance backed by a MongoDB replica set.

  • User count: Confirm that your active user count stays within the Starter limit before you commit, since the plan limit is the point where a paid plan becomes necessary.
  • Single node setup: A single instance with a MongoDB replica set is the design the reference architecture suggests for smaller loads, and you still operate MongoDB, backups and upgrades yourselves.
  • Import scope: Start with a pilot set of channels to test the CSV conversion before you move the full history.
  • Upgrade cadence: Standard releases are supported for 6 months, so plan a recurring upgrade window rather than a one-time install.
  • Mobile and desktop clients: Check that your version still connects with the official clients after each upgrade.

Confirm the current Starter limits and feature list on the Rocket.Chat plans page before you size the rollout.

Questions buyers ask before they start the Teams to Rocket.Chat move

What does a Teams to Rocket.Chat migration cost?

The cost comes from people and time, not from a Rocket.Chat license fee for a small deployment. Rocket.Chat's free Starter plan allows up to 50 users, and the free Community workspace allows up to 100 concurrent users with core messaging (Rocket.Chat plans docs). Paid Commercial, Government and Defense plans are priced by quote (Rocket.Chat pricing page). Recurring costs include the servers, MongoDB replica set, storage, backups, and staff time for upgrades, because Rocket.Chat versions go end of life and stop receiving fixes. Ask any provider for a one-time quote split into export, conversion, import, SSO, meetings and cutover, plus a separate recurring estimate for hosting and upgrades.

How long does the migration take?

The duration depends on the volume of history, the number of teams and channels, how many users need SSO, and whether meetings move too. Extraction runs through the Microsoft Graph Teams Export APIs, which need admin-approved application permissions and an active Teams license on each exported user (Microsoft Learn). Any deleted content is only recoverable within the windows described in Microsoft's documentation, so confirm those dates early. Ask for a timeline in the written scope, with separate milestones for a pilot import, a full import and user cutover.

What do our Microsoft 365 and Entra ID admins need to provide?

Your Microsoft 365 and Entra ID administrators must approve the application permissions that the Teams Export APIs require, and they must confirm that the users whose content is exported hold active Teams licenses (Microsoft Learn). Your Rocket.Chat administrators need an environment for the server, a MongoDB 8.0 or later replica set, and an identity provider configuration for single sign-on. Agree in advance who signs off on data access, where exported files are stored during conversion, and how long they are retained.

Can an internal team run the migration without outside help?

Yes, if the team has Microsoft Graph, MongoDB, Linux container and identity administration skills and enough time for testing. Rocket.Chat's import documentation covers Slack exports and a CSV importer for other sources, so the work is converting Teams data into the CSV format, not a built-in Teams importer (Rocket.Chat data import). The risk is in the details: mapping teams and channels, preserving thread context, handling attachments and rebuilding SSO and meetings. Many organizations keep the decision and the operation in house while bringing in specialists for the conversion and cutover, and an outside partner works from a written, fixed scope.

Does the full chat history move to Rocket.Chat?

Not automatically. Rocket.Chat has no Teams importer, so the history moves only if someone extracts it from the Graph Teams Export APIs and converts it into a format the CSV importer accepts. The Export APIs cover 1:1, group, meeting and channel messages, plus meeting recording and transcript links (Microsoft Learn), but meeting recordings and transcripts are links and need a separate storage decision. Rocket.Chat recommends splitting large import files into pieces under 15 MB (Rocket.Chat documentation). Test a sample channel end to end and confirm with your team which fields, reactions and attachments you need to keep.

Which Rocket.Chat plan do we need for SSO and air-gapped use?

The free Starter plan includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts, for up to 50 users (Rocket.Chat plans docs). Air-gapped deployment is a paid-plan capability and is not available on Starter (Rocket.Chat plans docs and pricing page). Paid plans also add LDAP and SAML user group mapping and tamper-evident audit trails. If you have more than 50 users, or you need the multi-instance or microservice designs for larger scale, which require a paid plan (Rocket.Chat reference architectures), request a written comparison of Commercial, Government and Defense plans before committing.

How do we keep Rocket.Chat supported after the move?

Plan for regular upgrades from day one. Standard releases are supported for 6 months and LTS releases for 12 months, and after end of life a version gets no security or bug fixes (Rocket.Chat version durability docs). Unsupported versions can also lose the ability to connect with the official mobile and desktop clients (Rocket.Chat version durability docs). Ask the provider who runs upgrades, how backups are tested and who monitors release notes after handover.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, documents and supports self-hosted Rocket.Chat inside your own cloud accounts, data centers or air-gapped networks. The work for this migration covers the Teams export, the conversion to Rocket.Chat's CSV import format, and the rebuild of channels, single sign-on and meeting integrations.

How we scope

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
  • The written scope lists which Teams teams, channels, direct messages and meeting recordings are in or out of the export.
  • Scoping confirms the Graph admin-approved permissions and Teams licenses needed on each exported account.

How we build

  • Export runs through the Microsoft Graph Teams Export APIs, with output converted into Rocket.Chat's CSV importer format.
  • Channels, user accounts, single sign-on and the chosen meeting app are rebuilt and tested in a staging workspace.
  • Large exports are split into files under the 15 MB size Rocket.Chat recommends before each import is verified.

How we hand over

  • Handover documents the import runbook, the mapping of Teams teams and channels to Rocket.Chat rooms, and known gaps.
  • Operators receive configuration, backup and upgrade procedures for the MongoDB replica set and Rocket.Chat instance.
  • A cutover checklist records which content was migrated, which was not, and who confirmed each step.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after the migration closes.
  • Retainers can cover the regular Rocket.Chat version upgrades needed to stay on supported releases.
  • Confirm with DeployOpen in the quote which support hours, response expectations and testing cadence the retainer includes.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.