Which team chat fits: Slack or self-hosted Matrix with Element
Slack fits when your team wants a managed service, your integrations already run on it, and you have no appetite for operating a chat server. Self-hosted Matrix with Element fits when message content, user metadata and retention must stay inside your own infrastructure, when you need federation limited to a short list of domains or switched off entirely, or when a renewal or lock-in concern gives you time for a long, phased cutover. Slack's own export documentation matters here: on Free, history is limited, and private channels and direct messages need a Business+ or Enterprise application before they can be exported at all. Check which plan you are on before you decide anything else.
Running Matrix is a different job from running Slack. Synapse is the homeserver most organizations evaluate first, and it is distributed under AGPL-3.0 with commercial licenses available from Element, so confirm with Element which license terms apply to your use before you deploy. Expect to operate PostgreSQL (Synapse 1.143.0 and later require PostgreSQL 14 or newer), and plan for Redis and worker processes once usage grows. Element Server Suite offers a free AGPL Community edition, a Pro edition and a Sovereign edition for air-gapped deployments, so ask which of these covers the support, certification and upgrade assurances your auditors expect. Federation is configured through federation_domain_whitelist, where an empty list disables it, and the Synapse documentation advises firewalling the federation listener as well.
The decision turns on three questions. First, operating capacity: who will patch the homeserver, run database backups, handle upgrades and carry the on-call load, and is that cost lower than the Slack subscription you would stop paying. Second, retention and export needs: confirm what legal hold, export and eDiscovery requirements you must meet, because Matrix retention and export depend on your deployment choices and on any paid tooling you add. Third, whether bridges can cover the transition. Matrix bridges can keep Slack channels connected while teams move in stages, but a bridge adds its own service to run and secure, so test it with a pilot group before you commit a full cutover date.
Which option fits each team scenario
This table matches common Slack situations to the option that fits best, with the condition that drives each choice. Read each row against your own retention rules, staffing and integration count, since the reason is what should decide the answer.
| Scenario | Better fit | Why |
|---|---|---|
| Small team on Slack Free that hits the 90-day history limit | Mattermost Team Edition or Rocket.Chat Starter | Matrix with Element needs operator time for a homeserver, database and reverse proxy, which a small team may not have. Both alternatives install as a single application for small groups, with user caps to confirm for your size. |
| Regulated bank that must keep messages in its own data center | Matrix with Element, or Mattermost Enterprise | Both run entirely on your hardware. Matrix offers federation switched off with an empty allow-list, so messages never leave your network. Confirm which compliance features each paid tier needs for your retention rules. |
| Company with many Slack integrations and bots | Mattermost | Mattermost has documented Slack-style incoming webhook support. Matrix has no equivalent drop-in, so each bot must be rebuilt as a Matrix client or bridge. Inventory integrations before choosing. |
| Partner-heavy organization needing shared channels with outside firms | Matrix with Element | Federation lets separate homeservers exchange rooms, and you can restrict it to a list of partner domains. Confirm each partner runs a compatible homeserver and agree on an allow-list with security review. |
| EU team with strict residency rules and no US-hosted control plane | Matrix with Element or Mattermost, hosted in an EU data center | Both can run where you choose. Matrix keeps identity and rooms on your homeserver. Confirm that your hosting provider and backups stay in region. |
| Team with no in-house Kubernetes or database operators | Mattermost Team Edition or Rocket.Chat Starter, or stay on Slack | Synapse at scale needs PostgreSQL, Redis and worker processes that need ongoing care. A single-binary deployment with fewer moving parts suits teams without platform staff. Ask a partner for a written support scope before committing. |
| Organization planning a phased cutover with channels still in Slack | Matrix with Element, using bridges during transition | Matrix bridges can keep Slack channels linked to Matrix rooms while teams move. Confirm the bridge supports your Slack workspace and test message history and threads before relying on it. |
| Team expecting heavy growth in users and message volume | Mattermost Enterprise or Matrix with Synapse workers | Synapse scales through worker processes connected by Redis and PostgreSQL 14 or newer. This is only worthwhile with staff who can run that stack. Ask for load testing against your own usage pattern. |
Where messages live and who controls the servers
Slack keeps your messages in the vendor's cloud, and what you can export depends on your plan. A self-hosted Matrix homeserver with Element clients puts the data, the identity integration and the operating decisions inside your own perimeter, with the work and the evidence moving to your team or your implementation partner.
Data location and retention
Slack stores messages and files in its hosted service, and retention is governed by the plan you buy. On Free, history older than 90 days is hidden, and content older than one year is permanently deleted. With Synapse, every room history lives in your PostgreSQL database and your file store, so retention is a setting you own. Check where your PostgreSQL and media storage sit, and who holds backups of them.
Export rights depend on Slack plan
Your ability to get your own data out of Slack depends on the plan. Every plan can export messages and file links from public channels, but private channels and direct messages need a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. Before you rely on Slack as a source of record, confirm which of these your workspace can actually produce.
Hosting model choice
A Synapse deployment can run in your own data center, in your cloud account, or with an EU or sovereign hosting provider you contract directly. Each choice changes who operates the servers, who can access the hosts, and which jurisdiction governs the provider. Element Server Suite also offers a Sovereign edition for air-gapped deployments, so ask Element and your hosting provider to confirm which components each option covers.
Identity integration with Synapse
Synapse can delegate sign-in to an external identity provider through OpenID Connect using oidc_providers, through SAML2 using saml2_config, or through CAS. Map your directory groups to account status before cutover so that leavers lose access in one place. Confirm which provider your identity team runs and whether it supports the protocol you choose, because Matrix Authentication Service is the component that handles upstream identity providers in newer deployments.
Federation and external reach
Synapse federates on port 8448 by default, so your users and rooms can be reached by other servers. The federation_domain_whitelist setting limits federation to listed domains, an empty list turns it off, and the documentation recommends firewalling the federation listener as well. Decide which of these postures applies to each environment before you connect any bridge, because a bridge to Slack is itself an external path your security team must review.
Compliance evidence and assessor decisions
Regulators and customers will ask how the chat system is configured, who can access it, and how retention and logging work. DeployOpen can prepare those controls, configuration baselines and evidence for an assessment. DeployOpen does not issue audit reports or attestations, and independent auditors and certification bodies decide whether your environment conforms. Ask your assessor early which evidence they will accept from a self-hosted system.
How Slack and Matrix with Element compare on capabilities
This table sets Slack's hosted plans against a self-hosted Matrix homeserver (Synapse) with Element clients, row by row. Read the cells as a starting point for your own requirements, and treat any row marked for confirmation as an open question to close with the vendor or in a test deployment. The main takeaway is that Matrix gives you control of data location and federation, but you take on the server, database and client decisions that Slack handles for you.
| Capability | Slack | Self-hosted Matrix with Element |
|---|---|---|
| Message history on the lowest tier | Free plan keeps 90 days of messages and files; content older than one year is permanently deleted | Retention is set by your server configuration and storage, so confirm the retention settings you need before cutover |
| Export of history | Public channels export on every plan; private channels and DMs need Business+ or Enterprise; custom exports by member or conversation are Enterprise-only | Exports depend on your database and tooling; confirm with your Element deployment team how private rooms and encrypted content are handled |
| Federation with other organizations | Slack Connect shares channels with other Slack workspaces | Federation can be restricted to a list of domains or switched off entirely; the Synapse docs also recommend firewalling the federation listener |
| Single sign-on | Available on paid plans; confirm the tier and identity provider support for your organization | Synapse supports OpenID Connect, SAML2 and CAS; confirm which provider and tier your organization needs |
| Editions and licensing | Subscription per plan, with features gated by tier | Synapse is AGPL-3.0 with commercial licenses from Element; Element Server Suite offers Community, Pro and Sovereign editions |
| Server requirements | None on your side; Slack operates the service | PostgreSQL is recommended for production; Synapse 1.143.0 and later require PostgreSQL 14 or newer, and workers rely on Redis |
| Bridges to other chat systems | Integrations are Slack-hosted apps; confirm which bridges your cutover needs | Matrix bridges can keep Slack channels connected during a phased cutover; confirm bridge maturity and support for your Slack features |
| Voice and video huddles | Built-in huddles; confirm the feature set available on your plan | Element Call is included in the Community edition; confirm TURN, bandwidth and recording needs in your environment |
| App and integration depth | Large app directory; confirm that your required apps exist and are supported | Depends on bots and bridges you build or deploy; confirm each integration against the Matrix ecosystem before migration |
How federation limits and bridges keep Slack channels connected
Federation is the setting that decides who your Matrix server can talk to, so decide it before users arrive. Synapse federates on port 8448 by default, and the server_name setting fixes how user IDs such as @user:example.com and room identifiers are written. Delegation lets that identity be served from another host on port 443, which matters if your public hostname differs from the machine running Synapse. Because server_name cannot be changed casually once accounts exist, confirm the domain with your security and identity owners first. For an internal rollout, the federation_domain_whitelist key in homeserver.yaml is the control to set: list only the domains you have approved, or set an empty list to switch federation off completely. The Synapse documentation also recommends firewalling the federation listener, so the network layer enforces the same decision if the application configuration is ever changed by mistake.
Bridges are the usual way to keep Slack channels connected while teams move over in stages. A bridge relays messages between a Slack channel and a Matrix room, so people on each side can keep working during the cutover. Treat this as a bridge between two systems you must operate, not a feature of Matrix itself. Each bridge is a separate project with its own maintenance, its own Slack permissions and its own failure modes, and the list of bridges on Matrix.org shows status and features that change over time. Before you rely on one, confirm with its maintainers which Slack features it supports, such as threads, file transfers, edits and deletions, and whether it is actively maintained against the Synapse version you run. Plan for a defined end date for the bridge, and check which messages it mirrors into Matrix history, because relayed messages may not match the original Slack export.
What Synapse needs as usage grows
A small Synapse server can run on defaults, but the components that matter at scale are the database, the worker topology and the upgrade path. Each card below is a decision or check to settle before you add users, not a feature comparison.
PostgreSQL as the production database
Synapse supports SQLite, but the upstream documentation recommends PostgreSQL for production. Synapse 1.143.0 and later require PostgreSQL 14 or newer, so check your database version before you plan an upgrade. Confirm who owns backups, failover and version patching for the database, because Slack's hosted equivalent hides all of that from your team. Treat PostgreSQL as the system of record for every message you keep.
Redis for worker replication
When you split Synapse into workers, the main process and every worker connect to Redis, which relays replication traffic between them. Without Redis, workers cannot stay in step with the main process. Size Redis as a required dependency, not an optional cache, and include it in your monitoring, failover and restore plans from the start.
The generic worker
The generic worker handles client, federation and event traffic, so it is the first worker most deployments add when the main process becomes the bottleneck. Decide early whether federation runs on the main process or a dedicated worker, because that choice determines which listeners and reverse proxy routes you configure. Load test the split with your own user pattern before cutover, since Slack migration traffic looks different from steady-state chat.
Python 3.10 or newer
Synapse 1.142.0 and later require Python 3.10 or newer. Pin the interpreter in your build or container image so that a system update does not change the runtime under a running homeserver. Also check the upstream end-of-life dates for the Python and PostgreSQL versions you run, because Synapse drops support for a version once its upstream support ends, which forces an upgrade on Synapse's schedule.
Rollback after schema changes
Synapse upgrade notes warn that rolling back can be difficult because database schema changes occur between releases. A binary rollback alone does not restore the older state. Plan each upgrade as a change with a database backup taken immediately before it, a staging run against a copy of production data, and a documented decision point for rolling forward instead. Ask your Element or DeployOpen contact to define that procedure in writing.
A tested restore path before scaling
Before you add workers or move the database, prove that you can restore the homeserver from backup into a clean environment. Test the restore of PostgreSQL, the media store and the signing keys together, then time the restore and record which steps need manual work. Scaling changes the components, so a restore that worked on the single-process setup may not work on the new topology. Repeat the test after every major upgrade.
What a self-hosted Matrix deployment costs to run
On the Slack side, the recurring cost is a per-seat subscription, and the plan you hold decides what you can get out of the workspace. Slack Free keeps 90 days of message and file history and permanently deletes content older than one year, while exporting private channels and direct messages requires Business+ or Enterprise, and custom exports by member or conversation are Enterprise-only. On the Matrix side, the recurring cost is the infrastructure and people that run the homeserver: compute and storage for Synapse, PostgreSQL 14 or newer, Redis for workers, TURN relays if you host calls, bridges, backups, and monitoring. Ask your cloud or data center team to price each of these as a separate line, because PostgreSQL storage and backup retention usually grow with message volume and are the easiest to underestimate.
The one-time costs are the migration, the bridge setup, and hardening. A phased cutover using Matrix bridges for Slack means building, testing and monitoring the bridges before anyone depends on them, and deciding how existing history is handled, since Slack exports do not map cleanly into Matrix rooms. Staff time recurs: someone must apply Synapse upgrades, which the upgrade notes say can be hard to roll back because of schema changes, and follow the Python and PostgreSQL end-of-life schedules. Plan for on-call coverage for a service that users notice immediately when it stops. If you choose Element Server Suite, confirm the edition terms on the Element pricing page: the free AGPL Community edition differs from the Pro and Sovereign editions, and the Pro edition includes Synapse Pro. Ask whether the commercial license is needed for your use of Synapse under AGPL-3.0 and whether support is included.
Request quotes from each implementation partner, including DeployOpen, built on a written scope that lists the number of users, the expected message volume, the federation model (closed, allow-listed or open), whether you need SSO, calls and retention controls, and whether the environment is air-gapped. Ask each bidder to separate one-time work from annual support and upgrade retainers, and to state who carries the on-call duty and the backup and restore testing. Compare those quotes against your current Slack spend, including the plan tier needed to export your data, so the decision reflects the full cost of both options rather than the subscription line alone.
What a move from Slack to Matrix and Element involves
This sequence takes a Slack workspace to a self-hosted Synapse homeserver with Element clients, with each step ending in a check you can verify before the next one starts. Message history and integrations are planned as separate workstreams, not assumed to come across with the users.
Confirm the Slack plan and export scope
The workspace owner or Slack admin checks which plan the workspace is on and what that plan can export. Every plan can export messages and file links from public channels. Private channels and direct messages need a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. The owner should ask for a written decision on whether private channels and DMs are in scope, because that decision shapes the whole migration. The step is done when the export scope is recorded and approved by the business owners of each channel group.
Export and inventory channels, members and integrations
Run the Slack export at the scope agreed in the previous step and build an inventory from it. List channels with their purpose and membership, active members with their identity provider records, Slack Connect channels, installed apps and webhooks, and any retention rules the business needs to keep. Mark each integration as rebuild, retire or keep outside chat. Slack exports do not carry integrations across, so each one needs an owner and a replacement plan. The step is done when the inventory is signed off and every integration has a named owner.
Stand up Synapse with PostgreSQL and Redis
The platform team deploys the Synapse homeserver inside the organization's own infrastructure, backed by PostgreSQL for production. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so the team should confirm these versions against the release they select. If usage is expected to grow, plan for worker processes with Redis relaying replication between them. Record the schema change behavior from the upgrade notes, since rolling back after a release can be difficult. The step is done when a test homeserver accepts logins and the database and Redis backups have been restored once in a test.
Configure identity and federation settings
Set the server_name, which fixes how user IDs and room IDs are identified, and decide how users sign in. Synapse supports OpenID Connect providers, SAML2 and CAS, so the identity team connects the existing directory and checks how accounts are provisioned and removed. Then set federation: use federation_domain_whitelist to allow only listed domains, or set an empty list to disable federation entirely, and firewall the federation listener as the documentation recommends. The security team should review these settings in writing. The step is done when a test user from the directory can sign in and federation behaves as the approved policy requires.
Pilot Element clients with bridged channels
Install Element clients for a small pilot group and connect the Slack channels in scope through a Matrix bridge, so people on both platforms can talk during the transition. Bridge choice, supported features and reliability need confirmation against the bridge's own documentation before the pilot starts, because bridges differ in what they carry. The pilot team should test message delivery in both directions, file handling, edits, threads and notifications, and record gaps. The step is done when the pilot group signs off on the gaps list and the owners accept any known limits.
Plan and load existing message history separately
Existing Slack history does not arrive through the chat rollout. Decide with the records and legal teams which history must be kept, where it will be stored and who can read it, then choose a separate import or archive approach and test it on a copy of the export. Confirm with the vendor or your own integrator whether a Slack-to-Matrix import tool fits your scope, and do not assume one exists. The step is done when the retained history has a documented location, a restore test and an access rule approved by the records owner.
Onboard teams, rebuild integrations and retire Slack
Move teams in waves, starting with the pilot group, and give each team a dated cutover and a support contact. Rebuild each integration on the new platform according to the inventory, retiring those no longer needed. Keep the bridged channels running until the last dependent team has moved. Retire Slack only after the export is archived, integrations are rebuilt or closed, and the owners confirm that no active process depends on the old workspace. The step is done when Slack is read-only or removed under a written decommission record that lists what was kept and where.
Questions buyers ask before switching from Slack to Matrix
What does a Slack to Matrix migration cost, and what drives the price?
The cost depends on the scope written into the engagement, not on a single figure. Most of it is labor: planning the homeserver architecture, installing and hardening Synapse with PostgreSQL and Redis, configuring single sign-on, migrating or archiving history, setting up bridges during cutover, and training administrators. Software licensing is a separate line: Synapse is AGPL-3.0 and free to run, while Element Server Suite is sold in Community, Pro and Sovereign editions, so ask the vendor which edition and support tier applies. Ongoing costs include hosting, backups, upgrades and monitoring. Ask any provider for a quote that separates one-time implementation from recurring support, and for each Slack data source (public channels, private channels, DMs, files) to be listed as in or out of scope.
How long does a Slack to Matrix migration take?
The timeline depends on scope, and no single duration applies to every organization. The main variables are the number of users and channels, how much history must be moved, whether Slack Connect channels or integrations need rebuilding, how many identity providers must be connected, and whether the cutover runs in phases with bridges. Your Slack export plan also matters: exports of private channels and direct messages require a Business+ or Enterprise application. Ask for a written plan with phases, owners and acceptance criteria, and confirm whether the timeline covers only the platform build or also user onboarding and parallel running.
How much work does our own team have to do?
Your staff remain responsible for decisions that only your organization can make, even when an implementation partner does the build. Expect your team to own identity integration with your existing directory, approval of retention and data classification rules, DNS and certificate management, firewall and network changes, sign-off on user communications, and the on-call process after go-live. Someone must also be able to run database backups and apply Synapse upgrades. Ask the provider to name these responsibilities in the written scope so that gaps are visible before work starts.
Can our team run Synapse ourselves after the migration?
Yes, many teams operate Synapse in-house, but the work is continuous. Synapse depends on PostgreSQL for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer. The upgrade notes warn that rolling back can be difficult because of database schema changes between releases, and that support for Python and PostgreSQL versions ends at upstream end of life. Growth often means adding worker processes that connect through Redis. Before deciding, check whether your team has staff who can handle database administration, scheduled upgrades and performance tuning, and whether a retainer for upgrades and support is part of the plan.
How should we restrict federation for an internal Matrix server?
For an internal deployment, the safest starting point is to disable federation entirely. In Synapse, an empty federation_domain_whitelist list turns federation off, and a list of named domains restricts it to those partners only. The Synapse documentation also recommends firewalling the federation listener, which uses port 8448 by default, so that only approved networks can reach it. If you later need to talk to a partner's Matrix server, add that domain to the list, confirm the server_name and delegation settings, and review the trust decision with your security team. Document each change, since federation scope affects who can join your rooms.
Does Synapse's AGPL license affect internal use, and when do we need Element's commercial license?
Synapse is licensed under AGPL-3.0, and Element relicensed its future contributions to AGPLv3 in December 2023, moving the repositories to the element-hq organization on GitHub. Running an unmodified copy for internal staff generally carries different obligations from distributing or offering a modified version to outside users over a network, which is what the AGPL addresses. Whether your use triggers any obligation depends on how you deploy and change the software, so have counsel review your specific case. Element sells commercial licenses that provide an exception to the AGPL terms. Ask Element for its written terms before you commit to a design that modifies Synapse or offers it to third parties.
When is Element Server Suite Pro worth evaluating?
Element Server Suite Pro is worth evaluating when your organization wants vendor-backed Synapse Pro and needs features or support that the free AGPL Community edition does not supply. Element lists three editions: a free AGPL Community edition that includes Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. If you operate in a disconnected network or need a contractual support path, compare the editions on Element's pricing page against your written requirements. Ask the vendor to confirm which features are in each edition, what support levels are included, and what the license permits for your deployment model.
How DeployOpen helps evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Slack vs Matrix and Element, the work starts with a written scope covering your federation policy, bridge plan and Synapse sizing before any server is built.
How we scope
- Inventory which Slack channels, private groups and DMs must move, and which export plan your workspace has
- Decide whether federation is off, limited to listed domains, or open, and document the reasoning
- Agree in writing whether Element Server Suite Community, Pro or Sovereign fits your licensing and air-gap needs
How we build
- Deploy Synapse with PostgreSQL, Redis and worker processes sized to the user count agreed in scope
- Configure SSO through your identity provider, and firewall the federation listener when federation is restricted
- Test bridge connections to Slack channels during the phased cutover and record which features do not carry over
How we hand over
- Deliver runbooks for backups, Synapse upgrades, schema migrations and rollback limits between releases
- Document federation settings, retention choices and the evidence your compliance team needs to review
- Train administrators on user onboarding, room management and bridge monitoring in your own environment
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after go-live
- Plan Synapse and PostgreSQL version changes around the upstream support dates your team confirms
- Run security testing of the homeserver, clients and bridges, with findings tracked against the written scope
