Open-source alternative to Google Chat

Open-source alternative to Google Chat for teams leaving Workspace

If a Workspace renewal, a data residency rule or a lock-in concern has put Google Chat in scope, the main self-hosted options are Mattermost, Matrix with Element and Nextcloud Talk. Chat can move alongside Gmail, Drive and Meet as part of a wider platform change, or it can be replaced on its own while the rest of Workspace stays in place. The choice between these paths decides how much of the Chat history you need to carry across and who will own the new service after go-live.

Chat history is the hardest module to move, because Chat has no import path into a new messaging platform in the way that mail has into a mailbox. The Workspace Data Export tool, run by a super administrator, can export organization data including Chat as zip files into a Cloud Storage bucket. Treat that export as a source of data to read and convert, not as a ready-made import. The admin account must be at least 30 days old, exports typically take about 72 hours but can take up to 14 days, and the default bucket is deleted after 60 days, so start the export early and copy the files out before the bucket is removed.

The supplied facts do not say that Chat is a separate export target or describe its file format, so confirm this in your own export before you plan the conversion. Ask which spaces, direct messages and attachments are included, how messages and threads are structured in the files, and whether edits, deletions and reactions are preserved. Then decide how much history the new platform must hold, which users and spaces need access on day one, and whether a read-only archive is enough for records retention. Those answers set the scope of any importer work.

Which open-source option covers each Google Chat capability

This table maps the main Google Chat capabilities to Mattermost, Matrix with Element and Nextcloud Talk, and flags where each platform depends on plan, edition or configuration. Treat every cell as a hypothesis to confirm in your own test environment with real spaces, guests and retention settings before you commit to a platform.

Capability	Mattermost	Matrix with Element	Nextcloud Talk
Spaces and channels	Team channels, public and private; confirm limits for your team count	Rooms grouped into Spaces; confirm moderation and permissions in your clients	Group conversations and channels; confirm how they map to Chat spaces
Direct messages	Direct and group messages; confirm group size limits in your version	Direct chats as rooms; plan device verification for encrypted rooms	One-to-one and group conversations between Nextcloud accounts
Threads	Threaded replies in channels; confirm behavior in your client version	Threads depend on client support; test with each client your users run	Confirm threaded replies in your Talk version before relying on them
File sharing	Uploads stored on S3, S3-compatible storage or NAS; plan capacity	Media stored on your homeserver; size storage and media retention early	Shares files from Nextcloud Files with existing sharing permissions
Search	Built-in message search; search replicas can offload query load	Server-side search needs confirming with your encryption choices	Message and file search depend on installed apps; confirm in test
Admin controls	System console for teams, channels and users; confirm role granularity	Admin tooling is split across Synapse and clients; confirm your workflow	Managed through Nextcloud admin settings and app configuration
SSO and directory sync	SAML, OIDC and OAuth; AD/LDAP sync from the Professional plan	Synapse supports OIDC, SAML2 and CAS; directory sync needs a separate design	LDAP app plus OIDC or SAML backends for directory logins
Retention and audit	Confirm retention and audit log options for your plan	Retention set per deployment; confirm settings and log output for your version	Retention follows Nextcloud Files and logging; confirm audit coverage
Federation, HA and recording	High availability only on Enterprise and Enterprise Advanced plans	Federation off with an empty whitelist; firewall port 8448 if enabled	Recording included in All-in-One; confirm recording capacity for your load

Mattermost, Matrix with Element or Nextcloud Talk: which fits which team

Each option replaces Google Chat spaces and direct messages, but they differ in how they store data, how they federate and what they need to run at scale. The cards below describe where each one fits and the trade-off a buyer should test before committing.

Mattermost for channel-based teams

Mattermost runs as a single Linux binary backed by PostgreSQL, which keeps the initial footprint small for a team moving off Google Chat spaces. Its server binaries are MIT-licensed, while custom builds fall under AGPL v3.0. The high availability cluster is available only on the Enterprise and Enterprise Advanced plans, and a cluster needs shared file storage such as S3, an S3-compatible service or NAS on every node. Confirm those plan and storage requirements with Mattermost before sizing the design.

Matrix with Element for federation

Matrix with Element suits organizations that need to talk across companies, partners or public bodies without each side hosting the same server. Synapse, the most documented homeserver, is licensed under AGPL-3.0 and recommends PostgreSQL for production. Scaling beyond a single process uses workers connected through Redis. Federation exposes the server to other domains, so plan the federation whitelist and firewall rules, and confirm bridge availability for any Google Chat contacts you must keep reaching.

Nextcloud Talk beside Nextcloud files

Nextcloud Talk fits teams that already store documents in Nextcloud and want chat, calls and file references in one place. It needs no separate chat platform if Nextcloud is already the file store, which keeps the number of systems to patch and back up low. The trade-off is that Talk's messaging depth is tied to the Nextcloud release cycle, so check that Talk covers your required features against the current release before retiring Google Chat. Operating it alongside a larger Nextcloud deployment also means planning Nextcloud major upgrades one version at a time.

Choosing by existing platform

The strongest signal is what the organization already runs. Teams with Nextcloud for files often favor Talk to limit new systems, while teams needing structured channels, integrations and deeper administration controls tend to evaluate Mattermost. Teams whose main requirement is external federation or interoperability with other Matrix users lean toward Matrix. Score each option against your retention, admin control and export needs, then test with a pilot group before migrating history.

How the chat platform sits beside the rest of your suite

Many organizations move chat first and leave Gmail, Drive and Meet in place for a while. This path is simple to describe but has a real identity cost: Google Workspace and the chat platform will each hold their own login session, and nothing in the supplied facts says that Google Workspace can act as a SAML or OIDC identity provider for a self-hosted chat server. Confirm that with Google and with the chat vendor before you plan on it.

Sign-in path: Decide whether chat users log in through a separate directory or through a shared identity provider. Separate local accounts are the quickest to stand up but create a second set of credentials to deprovision.
Links to Drive: Files shared into chat stay in Drive, so sharing permissions in Google remain the control point. Plan who can post Drive links into channels that include external guests.
Meet calls: Chat and Meet are separate products. Test whether links, calendar invitations and notifications work the way your teams expect.
Data export: Chat history must be exported from the Workspace Data Export tool, which runs as a super administrator task, before the Chat tenant is closed.

Confirm the exact export scope and format for Chat with the Google admin documentation before you schedule the cutover.

Single sign-on is the most common requirement in regulated environments. Mattermost documents SAML single sign-on, and its pricing page places SSO (SAML, OIDC, OAuth) in the Professional plan and above. Matrix Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS. These are different models, so compare them against your identity provider rather than assuming they behave alike.

Mattermost: SAML and OIDC are supported in paid plans. Confirm which claims and group attributes your identity provider must send for role mapping.
Synapse: Configure OIDC in oidc_providers and SAML2 in saml2_config. The SAML path uses pysaml2, so test your metadata and signing settings in staging.
Nextcloud: Documents OpenID Connect and SAML user authentication backends, which apply to Nextcloud accounts used alongside chat.
Session behavior: Test how logout, token expiry and password resets propagate. Chat clients on mobile and desktop may keep sessions longer than web browsers.

Confirm with the identity provider and each product's documentation that the required claims, groups and logout behavior work for your tenant.

Some environments must run chat without reaching outside identity or update services, or must keep the service available during node failures. The supplied facts describe these options at product level, so the reader should confirm the exact topology with each vendor. Mattermost lists air-gapped deployment in Enterprise Advanced and high availability in Enterprise and Enterprise Advanced. Mattermost high availability needs shared file storage on S3, an S3-compatible service or NAS on each node.

Mattermost HA: Requires redundant application servers, database servers and load balancers, available on Enterprise and Enterprise Advanced plans.
Shared storage: Local file system storage will not work correctly for a cluster and risks corrupting files, so the storage choice is a design decision in its own right.
Matrix workers: Synapse scales with worker processes that connect to Redis for replication, and the Redis dependency adds an operational component.
Federation controls: Synapse's federation_domain_whitelist setting can restrict federation, and an empty list disables it. Decide this before go-live.
Identity dependency: If the directory or SSO provider is unreachable, confirm whether users can still sign in through any fallback.

Confirm the air-gapped update process, the supported HA topology and the failover behavior with the vendor before you design the environment.

Moving Chat history out of Google Workspace

This sequence takes Google Chat history out of Workspace as structured files, maps the old spaces and people onto channels or rooms in the target platform, and records what was imported and what was archived. The result is a verified export you can load into Mattermost or Matrix, or keep as a read-only archive.

Confirm the super administrator account age
A super administrator runs the admin Data Export, and the account must be at least 30 days old before the tool is available. Check the account creation date in the Admin console and confirm that the account has the super administrator role. You are done when the account is eligible and the export can be started from the Data Export page.
Run the Data Export with Chat selected
In the Admin console, start an export and select Chat along with any other products you need, such as Drive for files referenced in conversations. Choose a Cloud Storage bucket as the destination and record the export identifier and start time. You are done when the export status shows as in progress in the Data Export list.
Plan for a long-running export
Exports typically take about 72 hours but can take up to 14 days, so schedule the work around that window and tell the people who own the target platform when to expect files. Monitor the export status and avoid starting migration tests that depend on a finished file set. You are done when the status changes to complete and the team has a confirmed download date.
Download before bucket deletion
The default bucket is deleted after 60 days, so copy the zip archives to storage you control within that period. Use an approved transfer method such as gsutil or the Cloud Console, and verify checksums against the sizes listed in the export. You are done when every archive is stored in your own location and a hash record is kept with the migration project.
Parse the zip contents
Extract the archives into a staging area and review the Chat folder structure, which typically separates spaces and direct messages into their own files. Write a short inventory listing each space, direct message group, message count and attachment reference. You are done when the inventory reconciles with the export summary and any unreadable files are logged for follow-up.
Map Workspace users and spaces to channels or rooms
Build a mapping table that links each Workspace user to a target account, each Chat space to a Mattermost channel or Matrix room, and each direct message group to a private channel or room. Confirm identity mapping through your identity provider, and decide who will own each channel after the move. You are done when the mapping is reviewed by the business owners and each source space has one agreed destination.
Import what the target supports
Load the converted messages into a test instance of the target platform first, using an import tool or a script written for the target's import format. Confirm that timestamps, authors, threads and attachments survive, and note any loss in the migration log. You are done when a sample of spaces has been checked by their owners and the test results are signed off.
Archive what the target does not support
Store the original export and any content that cannot be imported, such as reactions, edits history or unsupported attachment types, as a read-only archive with an index. Restrict access to the archive to the roles that need it for records or legal requests. You are done when the archive is indexed, access is limited, and the migration record lists what was archived and where. Note that user Takeout is a per-user alternative to the admin export, and Workspace administrators control whether users can run it. Confirm that policy before relying on individual downloads for a complete record.

What changes for users after the cutover

Users will feel the cutover most in three places: the client they open, the way they sign in, and the features that Google Chat quietly provided. Mattermost, Element and Nextcloud Talk each have their own desktop and mobile apps, notification settings and channel model, so a Chat space does not map one to one onto a Mattermost channel or a Matrix room. Before the move, list the Google-specific behaviors your teams rely on, such as starting a Meet call from a space, bot-driven notifications from Google services, and file previews that open inside Chat. Each one needs a replacement, an alternative workflow, or an explicit decision to drop it. Confirm the exact feature set of the target platform with its vendor or documentation in your own environment rather than assuming parity.

Sign-in is the change that generates the most support tickets. If you connect the new platform to your directory or identity provider, users will authenticate through that provider instead of their Google session, and mobile apps may need a fresh login and new notification permissions. Decide in advance whether the new platform will use single sign-on, directory sync or local accounts, and test that flow with a pilot group that includes users on managed mobile devices. Plan for a parallel period in which Google Chat stays readable and users can post in both places. Agree the length of that period and the message that tells people where new conversations happen, and use Workspace admin controls to turn off Chat for users only once the new platform is confirmed as the working channel. Keep the Data Export from Chat available until the migration owner signs off on the history.

What does replacing Google Chat cost and take?

What are the main cost components when replacing Google Chat with a self-hosted platform?

The cost splits into software, infrastructure, storage, database, backups, migration and support, and only some of these are licence fees. Mattermost sells Professional, Enterprise and Enterprise Advanced plans as prepaid annual subscriptions priced by seat licence, and its pricing page lists no public prices, so you must request a quote. Matrix with Synapse is AGPL-3.0 licensed with commercial licences from Element, and Nextcloud Talk ships inside the free Nextcloud Hub. Servers, PostgreSQL, object or NAS storage, backup targets, and the staff hours for setup and upkeep are paid for separately, whatever the platform. Ask each vendor to state which of these items its quote includes and which you must provide.

Which costs recur and which are one-time when self-hosting team chat?

Migration, initial installation, identity integration and configuration are one-time costs. Subscriptions, support contracts, compute, storage growth, backup retention and administrator time recur every year. Mattermost high availability, for example, needs redundant application servers, database servers and load balancers and is limited to its Enterprise and Enterprise Advanced plans, so clustering adds both licence and infrastructure cost that a single-node deployment avoids. Budget the recurring items over several years, not only the first one.

Can our own team run a Google Chat replacement without outside help?

A team with Linux, container or server administration experience and a clear owner for chat can usually run a single-node Mattermost or Synapse deployment, but high availability, federation and directory sync need more depth. Mattermost's single Linux binary with PostgreSQL keeps the initial footprint small, while a Synapse deployment adds Redis and worker processes once concurrent load grows. Check whether your staff have time for monthly upgrades: Mattermost publishes a server release on the 16th of each month, and Synapse upgrades require careful database planning. External help can be scoped as a fixed-scope engagement with written deliverables, or as a retainer for upgrades and support.

What does the work require from identity, DNS, storage and admin time?

Four dependencies drive most of the effort:

Identity: SSO through SAML, OIDC or OAuth, and AD or LDAP user sync. Mattermost includes SSO and AD/LDAP sync from the Professional plan, and Synapse supports OIDC, SAML2 and CAS.
DNS and certificates: Synapse federates on port 8448 by default, and delegation lets user IDs on one domain be served from another host on port 443.
Storage: a Mattermost high availability cluster needs shared file storage on S3, an S3-compatible service or NAS on each node, because local storage risks file corruption.
Admin time: someone must own upgrades, backups and user lifecycle. Confirm these dependencies with the vendor and in your own environment before you commit.

How does Google's Data Export timing affect a chat migration plan?

Google Workspace's Data Export tool includes Chat, and it is run by a super administrator. The admin account must be at least 30 days old, exports typically take about 72 hours but can take up to 14 days, and the default Cloud Storage bucket is deleted after 60 days. Start the export early, copy the archive out of the bucket within the retention window, and schedule the cutover around the expected completion date. Per-user Google Takeout is an alternative, but your administrators control whether users can use it. Confirm with Google which Chat formats the export delivers before you plan the import.

What should we ask for in a written quote for this migration?

Ask for a scope that lists each deliverable and its acceptance test, including the platform version, the number of users and channels or rooms in scope, and the identity integration. Request an itemised breakdown of licences or subscriptions, infrastructure you must supply, storage and database sizing, backup design, the migration of chat history, user and channel mapping, and cutover support. Confirm the support tier, response expectations, upgrade approach and what happens to history that cannot be imported. DeployOpen does not publish a price list, and a quote follows from the written scope.

How to plan the Data Export window around Chat

Start the Data Export early, because the run time is not under your control. Google's admin Data Export tool, which can include Chat alongside Gmail, Drive and Calendar, only runs for a super administrator whose account is at least 30 days old, so confirm that account's age before you plan a cutover date. Google states that exports typically take about 72 hours but can take up to 14 days. Build that range into the calendar, and do not schedule the Chat cutover to Mattermost, Matrix with Element or Nextcloud Talk for the day the export is requested. Keep existing Chat spaces running until the export has finished and been checked.

Plan storage in the destination bucket before you request the run. The export lands as zip files in a Cloud Storage bucket, and the default bucket is deleted after 60 days. Download the archives to your own storage within that window, and confirm that the target system has enough free capacity for the unpacked Chat history plus its attachments, since the archive size is not something you can set in advance. Assign one person to own the bucket, the download and the checksum or file count comparison, and record where each archive was stored.

Run a test export of a small set of Chat spaces before the full run. Use the test to confirm how Chat content arrives in the archive: the file structure, whether messages, threads, reactions, edits and attachments are present, how timestamps and user identities are represented, and how large the output is per space. Then check the sample against your target platform's import path, whether that is a Mattermost migration tool, a Matrix import script or a custom loader. Treat the Data Export as a one-time source step. Once the history is in the new platform, Google Chat remains the system of record only until users stop writing to it, so set that date deliberately.

Risks to decide before you commit to a chat platform

Each card below is a decision you need to settle before moving Google Chat spaces and direct messages to a self-hosted platform. Together they cover what history survives the move, what resilience and storage you must fund, how exposed federation makes you, what plan features cost, how fast versions age out, and who will run the platform.

History fidelity after import

The Workspace Data Export delivers Chat data as zip files into a Cloud Storage bucket, and that bucket is deleted after 60 days by default. Decide early which spaces, direct messages and attachments you need, who owns the mapping of users and channels, and whether a one-time import is enough or you need a read-only archive. Test the import on a copy of a few spaces and confirm with the target vendor how attachments, threads and edit history are represented.

High availability and shared storage

Mattermost high availability needs redundant application servers, database servers and load balancers, and it is available only on the Enterprise and Enterprise Advanced plans. Each node must mount shared file storage such as S3, an S3-compatible service or NAS, because local storage risks corrupting files. Decide whether you need clustering from day one, and budget for the storage and database redundancy that comes with it.

Federation exposure in Matrix

Synapse federates on port 8448 by default, so a public-facing homeserver can exchange messages with any server that accepts it. Decide whether you need federation at all. If not, set federation_domain_whitelist to an empty list and firewall the federation listener. If you do federate, decide which domains are allowed and who reviews them, because the server_name value fixes how users and rooms are identified and is hard to change later.

Mattermost licensing and plan gating

Mattermost binaries are MIT licensed and custom builds fall under AGPL v3.0, but features that matter for enterprises sit behind paid plans. SSO and AD/LDAP sync start at Professional, high availability and FIPS 140-3 compliance start at Enterprise, and air-gapped deployment is in Enterprise Advanced. Pricing is by seat through sales contact, so ask for a written quote that maps each required feature to a plan before you design around it.

Upgrade cadence and lifecycle

Mattermost publishes a new server version each month on the 16th, and only some releases are Extended Support Releases. Matrix Synapse and Nextcloud also move quickly, and Nextcloud forbids skipping major releases. Decide which release track you will follow, how often you will test upgrades, and whether you will pay for a vendor maintenance lifecycle. Confirm the support end date for the version you pick before go-live.

Staff skills and ongoing operations

Running Mattermost, Synapse with workers and Redis, or a Matrix bridge set requires skills in PostgreSQL, reverse proxies, certificates, backups and directory integration. Synapse upgrades can be hard to roll back because of database schema changes, so the team needs tested backup and restore steps. Decide whether this work stays in house, moves to a managed support contract, or goes to an implementation partner under a fixed-scope agreement.

How DeployOpen scopes and delivers a chat replacement

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Google Chat replacement, the work starts with a written scope that fixes what moves, what stays and how history is carried across.

How we scope

Inventory which Google Chat spaces and direct messages must move, and which can be archived read-only
Confirm whether the target is Mattermost, Matrix with Element or Nextcloud Talk, based on your identity and federation needs
Agree the written scope, deliverables and timeline before any work begins, with no price shown until the scope is set

How we build

Deploy the chosen chat platform in your environment and connect it to your identity provider for single sign-on
Plan database, file storage and high availability requirements for the chosen platform, and test them before go-live
Run security testing on the deployed platform and prepare configuration and access evidence for your compliance team

How we hand over

Load exported history into the new platform and verify message counts and attachment handling against the export
Document administration, backup, upgrade and user onboarding procedures in a form your own staff can run
Walk administrators through runbooks and confirm ownership of accounts, keys and infrastructure before closing the engagement

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build
Plan upgrades around each platform's own release and support windows, confirmed with you before changes are applied
Keep backups and restore tests current so chat history can be recovered if a deployment or upgrade fails

Open-source alternative to Google Chat