Migrate from Slack to Matrix and Element: what the work involves
The move from Slack to Matrix and Element is a staged project, not a switch-over. It needs a self-hosted Synapse homeserver, Element clients, identity integration with your existing directory, and a bridge that keeps Slack channels connected while teams move at different speeds. Platform engineering usually leads it, with security approving the federation and identity design and workspace owners deciding which channels move first and who signs off on each cutover. Renewal dates, data residency rules and lock-in concerns are the common triggers, and the effort is driven more by identity, retention and change management than by the server install itself.
The short answer on effort and risk: the server work is well documented, but the risk sits in the parts Slack handled for you. Synapse depends on PostgreSQL 14 or newer, Python 3.10 or newer for recent releases, and, as usage grows, Redis and worker processes. The upgrade notes warn that rolling back can be difficult because of database schema changes, so plan upgrades as tested, reversible steps in a staging environment. Confirm with your Element representative which Synapse Pro or Element Server Suite edition covers your support and air-gapped needs, because the Community edition under AGPL has different terms from the commercial options. Ask for these terms in writing before the design is fixed.
Slack's export rules set how much history you can carry, and they are decided by your current plan. Every plan can export public channels, but private channels and direct messages require a Business+ or Enterprise export application, and custom exports by member or conversation are Enterprise only. Confirm which export your workspace can produce before you promise anyone their DMs will follow them. Free workspaces also lose content older than one year, so older history may already be gone. Matrix bridges, which are listed on the Matrix.org bridge directory, are the mechanism for keeping Slack channels live during the cutover, but a bridge relays new messages and does not replace a historical import. Test each bridge against your actual Slack workspace, Slack Connect channels and file handling before any user is asked to move.
Which Slack capabilities map cleanly to Matrix and Element
This table maps each main Slack capability to its closest Matrix and Element equivalent and marks it as clean, needs rework or gap. Read the status as a starting point for a pilot, not a final verdict, because bridge coverage and Element Call behavior depend on your homeserver version and configuration. Confirm every row in your own environment before you commit a cutover date.
| Slack capability | Matrix and Element equivalent | Status |
|---|---|---|
| Channels | Public and private rooms in Element, with room directory and space grouping | Clean: rooms map well, but Slack channel names and membership need a mapping plan |
| Direct messages | Direct rooms between two users, with group DMs as multi-member rooms | Clean: history import into Matrix is the main open question, so confirm with your importer |
| Threads | Threaded replies in Element, rendered per room | Needs rework: thread behavior in bridged history may not match Slack, so test it |
| File sharing | Media uploads in rooms, with size limits set on the Synapse server | Needs rework: check upload limits and retention, and confirm how bridged file links are handled |
| Search | Server-side message search in Synapse, with scope depending on database and client | Needs rework: search across imported history is limited, so confirm results before relying on it |
| Single sign-on | OpenID Connect, SAML2 or CAS in Synapse, or upstream identity providers through Matrix Authentication Service | Clean: confirm your identity provider and group mapping with your IdP team |
| Guest access | Guest accounts and invite-only rooms, with federation controls for external users | Needs rework: no direct Slack guest model, so define roles and review each external account |
| Slack Connect style shared channels | Federation between homeservers, limited by federation_domain_whitelist or disabled entirely | Gap for many teams: partner homeservers must also run Matrix, so confirm before planning |
| Apps and integrations | Bots and bridges, not Slack app manifests; each integration is rebuilt | Gap: Slack apps do not port, so inventory and rebuild each one before cutover |
| Huddles and calls | Element Call, which covers group calls but must be confirmed for your TURN, bandwidth and recording needs | Needs rework: check call quality and recording requirements before retiring huddles |
What Slack exports can and cannot carry into Matrix
A Slack export decides what history and identity data you can move, and the Matrix side decides what gets rebuilt by hand. The cards below cover the export paths Slack documents, the directory and channel data to map, and the integrations that will not come across. No supplied source documents a Slack-to-Synapse importer, so treat the data move as a scripted or bridge-based project to scope before committing to a cutover date.
Export scope depends on plan
Every Slack plan can export messages and file links from public channels. Private channels and direct messages need a Business+ or Enterprise plan and an approved export request, and custom exports by member or conversation are Enterprise-only. If your workspace is on Free or Pro, plan for public channels alone unless you upgrade before the export. Confirm the plan and export approval in writing with Slack before you rely on private history for the Matrix side.
File links, not file contents
Slack exports carry file links rather than the files themselves in the form most teams will use. Any attachment you keep must be downloaded while the link still works, and the Free plan limits how long file links remain visible. Decide early whether attachments are archived as a separate store, linked to the original Slack URLs for a read-only period, or dropped. Ask Slack and your Matrix team which option your compliance owner accepts.
Identities to map from the directory
Export user records from your directory, not from Slack alone, so each person maps to one Matrix user ID of the form @user:example.com. Matrix IDs depend on the server_name you set, so decide that value before any import, because changing it later breaks identities. Map former employees, bots and shared guest accounts separately. Confirm which identity provider will sign users in through oidc_providers or saml2_config, since that choice governs who gets an account.
Channels to recreate as rooms
Slack channels do not become Matrix rooms automatically in a way you can assume without testing. Build an inventory with each channel's purpose, members, visibility and topic, then decide which become public rooms, invite-only rooms or Spaces. Archived channels and channels with long threads need a rule for what to import and what to leave read-only in Slack. Check room version and encryption settings for each room before the first user joins.
Integrations and bots to rebuild
Slack integrations, apps, bots and webhooks are not history, so an export will not recreate them. List every app with an owner, the events it reacts to and the systems it writes to. Each one needs a Matrix-side replacement such as a bot account, a bridge or a webhook receiver, and each replacement needs its own security review and credentials. Schedule these rebuilds as separate work items, because they can outlast the message cutover.
Import is a job to scope
No supplied source documents a Slack-to-Synapse importer, so you should not assume a supported one exists. The choices are a scripted import that writes events through the Synapse admin tooling, or a bridge that keeps Slack channels connected to Matrix rooms during a phased cutover. Ask your implementation partner to prove the chosen path on a copy of the export before you commit. Confirm the approach against the current Synapse release notes.
How the Slack to Matrix migration runs in sequence
The sequence moves a Slack workspace onto a self-hosted Matrix homeserver in stages, so each phase produces a checked output before users depend on the next one. Bridges keep Slack and Matrix channels talking while people move, and decommissioning Slack happens only after the Matrix side is proven.
Inventory channels, members, integrations and retention
Start by listing every public and private channel, direct message group, member, installed app and webhook in the Slack workspace, and record which conversations must keep history. Confirm your Slack plan, because exporting private channels and direct messages requires Business+ or Enterprise, and the export decides what you can carry forward. Involve your compliance lead to set retention requirements, and ask the Matrix and bridge vendors to confirm which Slack features their bridge supports. The step is done when you hold a signed-off inventory with each conversation tagged for migrate, archive or retire.
Build a pilot homeserver on PostgreSQL
Deploy a Synapse homeserver in your own infrastructure with PostgreSQL as the database, following the upstream recommendation for production, and add Redis and worker processes only if measured load requires them. Set server_name carefully, since it fixes how user IDs and room identifiers are issued, and decide early whether federation is off, limited with federation_domain_whitelist, or open. Connect a single sign-on provider if your identity team requires it, and confirm the PostgreSQL and Python versions your chosen Synapse release needs. The step is done when a test group of users can log in with Element, send messages and join rooms on the pilot server.
Map Slack channels to Matrix rooms
Create a target room for each Slack channel you plan to keep, with naming, topic, and power levels defined in a written table that the channel owners approve. Decide which rooms are invite-only and which are public, and document who holds administrator rights. Note that Slack-specific elements such as apps, user groups and Slack Connect channels will not map directly, so list them as rebuild items. The step is done when the mapping table is approved and every planned room exists on the pilot server.
Run a parallel phase with a Slack bridge
Connect the mapped Slack channels to their Matrix rooms with a Matrix bridge for Slack, so messages posted on either side appear on the other while teams move at their own pace. Confirm with the bridge project which message types, threads, reactions and files it carries, and test with a dummy channel before touching live traffic. Record any message loss, duplication or formatting faults in a defect log. The step is done when a test script posts messages both ways across the bridge with no unexplained losses and the defect log has an owner for each open item.
Cut over users and rooms in waves
Move users group by group, with each wave onboarded in Element, given a short guide on verification and notifications, and assigned a named contact for questions. Export Slack history for archived conversations using the export method your plan allows, and load what your retention policy requires into a read-only archive, since rolling a Synapse upgrade back can be difficult. Announce a freeze date for new posts in Slack per channel, and keep the bridge running until each room's owners confirm nothing active remains. The step is done when every wave is live, the access list matches the inventory, and channel owners have signed off their rooms.
Decommission Slack after a verified exit
Before removing Slack, verify that the archive you kept can be opened and searched, that retention and legal hold obligations are covered outside Slack, and that the integrations you intended to rebuild are working on the Matrix side. Revoke app tokens, remove the bridge, and disable Slack user access in a planned order, then record the decision and the final export location in your records. Confirm with the vendor what happens to data at contract end, since Slack Free workspaces face permanent deletion of older content. The step is done when the archive is verified, bridge credentials are revoked, and the change record shows Slack retired with an owner.
How the move differs by team size and starting point
A small team on Slack Free is usually concerned with history first. Slack states that Free workspaces keep 90 days of message and file history and permanently delete content older than one year, so the first step is to export what is still visible and decide what must be kept. Matrix can start small, but it does not import Slack exports the way Mattermost or Rocket.Chat do, so most of the history stays in Slack or in an archive you keep yourself. Federation can usually stay off for a team that only talks internally.
- Federation: Set
federation_domain_whitelistto an empty list so the homeserver does not federate, and firewall the federation listener as the Synapse documentation recommends. - Identity: Local accounts are often enough for a handful of users, but plan an identity provider if you expect growth.
- History: Export public channels from Slack while the data is still available, and store the files outside Slack before any deletion window closes.
- Bridges: A Slack bridge is rarely worth the effort for a small team, since the cutover can usually be a single date with a short announcement.
- Hosting: Synapse on SQLite is supported, but PostgreSQL is recommended for production, so confirm the cost of running it before you commit.
Confirm your Slack plan and export options on the vendor's help pages before you schedule the cutover.
A regulated organization usually moves for residency and control. The main work is identity and retention, not chat features. Synapse supports single sign-on through OpenID Connect (oidc_providers), SAML2 (saml2_config) and CAS, so the homeserver can authenticate against the corporate directory rather than local passwords. Federation should be restricted or disabled unless a documented business need exists, and Slack's Business+ or Enterprise export path must be approved before any private channel or direct message data leaves Slack.
- Federation: Use
federation_domain_whitelistto list only approved domains, or set it to an empty list, and firewall port 8448 for the federation listener. - Identity: Connect Synapse to your identity provider through OIDC or SAML2, and test account deprovisioning before go-live.
- History: Confirm with legal and records owners which Slack content must be retained, since Slack Free deletes older content and paid export access needs an approved application.
- Bridges: Run any Slack bridge inside the same controlled network and limit it to the channels in the approved migration scope.
- Support: Ask your Element and Synapse support contacts which edition covers your SSO and retention requirements, and confirm it with your auditors.
Check the export approval path and identity configuration with your security and records teams before the first user account is created.
A company with many Slack Connect partners faces the hardest part of the move. Slack Connect channels do not come across in a Slack export, and each partner organization sits on its own platform. Matrix federation can connect separate homeservers, but it works only where the other side also runs a compatible server and both administrators agree to federate. Bridges can keep a Slack channel mirrored into Matrix during the phased cutover, but they add a component that must be secured, monitored and eventually retired.
- Federation: Build an explicit allow list of partner domains in
federation_domain_whitelistand review each domain before adding it. - Identity: Partner users usually need external accounts. Decide whether they sign in through their own identity provider or through local guest accounts, and document the trust model.
- History: Slack Connect channels are not included in a standard export, so ask each partner what history they need to keep and where it will live.
- Bridges: Use a bridge to keep Slack channels connected while partners move at different speeds, and set a date to shut the bridge down.
- Scope: List every partner channel and its owners before cutover, since missing one usually breaks a customer or supplier conversation.
Confirm with each partner which bridge, federation or migration path they will accept before you announce a cutover date.
How Synapse, PostgreSQL and federation settings shape the build
Synapse is the most widely documented Matrix homeserver, so most of the build decisions for this migration come down to how you configure it before the first user signs in. The most important is server_name, which fixes how user IDs such as @user:example.com and room identifiers are formed. Changing it later is effectively a new identity space, so settle the domain with your security and identity teams first, and confirm how delegation will serve user IDs from a host on port 443 while federation listens on port 8448 by default. Check the current Synapse configuration manual for your release before you write the initial homeserver.yaml.
Synapse recommends PostgreSQL for production, with SQLite also supported. For recent releases, the upgrade notes state that Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Confirm the minimum versions for the release you plan to deploy against the Synapse upgrade notes, and plan for the fact that rollbacks can be difficult because schema changes ship between releases. Treat database backups and a tested upgrade path as part of the build, not as a later task. As usage grows, Synapse scales through worker processes that connect to Redis for replication, so budget for that architecture early if you expect a large channel population or heavy federation traffic.
Federation is the setting that most changes your risk profile. A Synapse server can federate with any other Matrix server by default, but federation_domain_whitelist restricts federation to listed domains, and an empty list disables it entirely. For an internal-only deployment, an empty list is the simplest control, and the documentation also recommends firewalling the federation listener so that only intended peers can reach it. Decide this before go-live, because it determines whether Slack-style shared channels with partners are possible at all. Single sign-on also shapes the build: Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config, and CAS. If you use Matrix Authentication Service, review its upstream identity provider setup to decide where authentication lives. Confirm which of these your identity provider supports.
What usually goes wrong in a Slack to Matrix migration
Most Slack to Matrix problems come from decisions made in the first week: how history is exported, what the homeserver name becomes, and whether federation is open. Each card below names one failure, why it matters for this migration, and the check that prevents it.
Unplanned history loss
Slack Free workspaces show only 90 days of messages and files, and content older than one year is permanently deleted on Free. If a team on Free assumes its history will arrive in Matrix, it may find the export already incomplete. Export before the workspace ages out, and confirm with Slack which plan the workspace is on and what its export settings allow. Private channels and direct messages need a Business+ or Enterprise export, so request that approval early.
Irreversible server_name choice
The server_name setting fixes how users and rooms are identified, such as @user:example.com. Changing it after accounts and rooms exist is effectively a new deployment, so every identifier, bridge mapping and client bookmark breaks. Decide the domain with the security and identity owners, confirm it is a domain the organization controls, and set up delegation so user IDs can sit on the bare domain while the server runs on another host.
Bridge gaps for threads and edits
A Matrix bridge for Slack carries channel messages across a phased cutover, but it is not a full mirror of Slack. Threads, message edits, reactions, file handling and Slack Connect channels may arrive flattened, late or not at all, depending on the bridge. Run a test channel with real thread and edit patterns, compare results in both clients, and write down which behaviors users must accept before the bridge goes live.
Rollback after schema changes
Synapse upgrade notes warn that rolling back can be difficult because database schema changes occur between releases. A failed upgrade may leave the team with no clean path back to the previous version. Take a PostgreSQL backup and a copy of the configuration before each upgrade, read the upgrade notes for the target release, and check the minimum PostgreSQL and Python versions the release requires.
Identity mapping errors
Slack users, Matrix accounts and bridge puppets rarely match by name alone. Duplicate people, mismatched email addresses and orphaned accounts cause messages to appear under the wrong person or split a conversation across two identities. Map each Slack user to one identity provider subject before import, set up SSO through OpenID Connect or SAML2, and review the mapping table with managers before the cutover date.
Federation exposed by default
Synapse federates on port 8448 by default, so a server built without limits can exchange messages with any other homeserver that can reach it. For a company migrating internal chat, that is usually not the intended boundary. Set federation_domain_whitelist to the partner domains that need access, or to an empty list to disable federation, and firewall the federation listener as the Synapse documentation recommends. Test both settings before users log in.
What drives cost and duration in this migration
This table lists the factors that raise or lower the effort of moving from Slack to a self-hosted Matrix server with Element, and the cost components behind each. Read it as a checklist to size the work before you ask for a written scope, since most of the spend follows from these drivers rather than from software licenses.
| Driver or cost component | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Channels and member count | Every room needs a naming, membership and permission decision, and large member lists slow membership mapping and account provisioning. | Archive inactive channels before export and migrate only active rooms in the first wave. |
| Private channels and direct messages | Matrix bridges and importers treat private rooms and DMs differently, and exporting them from Slack requires a Business+ or Enterprise plan. | Confirm your Slack plan early, then decide which private history must move and which can stay in the archive. |
| File volume and attachments | Attachments increase storage sizing, backup time and the work needed to re-host media on the new server. | Set a retention window for old media and move only files that users still link to. |
| Identity provider integration | Synapse supports OIDC, SAML2 and CAS, and wiring one to your directory adds design and testing work before any user logs in. | Pick a single identity provider and test login with a pilot group before cutover. |
| Integrations and bots | Slack apps and webhooks do not move with the export, so each one must be inventoried and rebuilt against Matrix APIs or bridges. | List integrations first, retire unused ones, and rebuild only the business-critical few. |
| Bridge count and bridge operation | Each Matrix bridge to Slack is a service to install, monitor and upgrade, and bridged rooms need mapping and ongoing support during the phased cutover. | Limit bridges to the channels that need continuity, and confirm the bridge setup with the bridge project before committing. |
| Retention and compliance needs | Legal hold, retention rules and audit evidence add design, storage and testing effort, and compliance features may depend on the commercial Element tier. | Write the retention requirement down before build, and confirm with Element which features each Server Suite edition includes. |
| Team Matrix experience | Operating Synapse well needs PostgreSQL, Redis and worker processes, and upgrade notes warn that rolling back can be difficult, so inexperience adds training and risk. | Train at least two operators, and use a staging server to rehearse upgrades before production. |
| Infrastructure, licenses, labor and parallel run | Infrastructure is recurring, Element Server Suite licenses are optional and tier-dependent, labor is one-time for migration and recurring for operations, and running Slack and Matrix side by side extends the total effort. Ask each vendor and partner for the written scope and price basis. | Compare the Community and Pro editions against your required features, keep the parallel run to a defined window, and request a quote that separates one-time and recurring costs. |
What to plan for existing message history and recurring costs
Decide the Slack export plan before you decide anything about history, because the plan sets the ceiling on what you can take out. Every Slack plan can export messages and file links from public channels. Private channels and direct messages need a Business+ or Enterprise workspace, and custom exports by member or conversation are Enterprise-only. On Free, visible history is limited to 90 days and content older than one year is permanently deleted, so a full archive may not exist at all. Check the Slack export guide against your plan before you promise anyone a complete record. Then choose between two paths: keep the export as a read-only archive for search and legal reference, or import history into the new server. Confirm with your implementation partner or the bridge projects whether any tool can load historical messages into Matrix rooms with original authors and timestamps. Live bridging does not guarantee that, and a read-only archive is often the safer default for older content.
Separate the one-time costs from the recurring ones. One-time work includes scoping, mapping Slack channels to Matrix rooms, wiring single sign-on (Synapse supports OpenID Connect, SAML2 and CAS), rolling out Element clients, building the archive and training staff. Recurring work is the larger budget line: hosting, a PostgreSQL database (Synapse 1.143.0 and later require PostgreSQL 14 or newer), Redis and worker processes as usage grows, backups, monitoring and the admin time spent on upgrades. Synapse v1.163.0 was published on October 14, 2026. Its upgrade notes warn that rolling back can be difficult because of database schema changes, and that support for Python and PostgreSQL versions ends when they reach upstream end of life. Budget for a staging rehearsal and a verified database backup before every upgrade, and read the upgrade notes for each release.
Licensing and support decide who you pay for what. Synapse is licensed under AGPL-3.0, and Element sells commercial licenses for organizations that cannot meet AGPL obligations. Legal counsel should confirm how those obligations apply if you modify Synapse and offer it to users over a network. Element Server Suite comes in three editions: a free AGPL Community edition that includes Synapse and Element Call, a Pro edition that includes Synapse Pro, and a Sovereign edition for air-gapped deployments. Ask any vendor for a written quote that states which upgrades, security patches, response times and licensing rights are included, and whether the quote covers the database, backups and client support or only the server software. Compare that with your own staff hours for upgrades and on-call work. The Element pricing page is the starting point for those edition questions.
Questions buyers ask before moving from Slack to Matrix
How much effort does a Slack to Matrix migration take?
The effort depends mostly on how many channels, users and integrations you have, how much history you need to keep, and whether you run Synapse yourself or buy the Element Server Suite. Stand up the homeserver, put PostgreSQL and the clients in place, configure single sign-on, and then decide how much Slack history and how many bots need rebuilding. Each of these is a separate work item with its own cost. Ask any partner for a written scope that lists each item, because a Matrix rollout that includes production-grade PostgreSQL, backups and client rollout is much larger than a single-server trial. Matrix does not import Slack workspaces the way Mattermost or Rocket.Chat do, so most of the work is design and rebuilding, not loading files.
How long does the move take, and what sets the timeline?
The timeline is set by the number of teams that must cut over, the bridge or dual-running period you need, how many integrations must be rebuilt, and how long your change approval process takes. A phased cutover usually runs longer than a single switch because Slack and Matrix must stay connected while teams move. Matrix also needs your identity provider, DNS, TLS certificates and federation policy in place before users log in. Ask for milestones tied to those dependencies rather than a single end date. No duration is given here because none was supplied for this migration; confirm it against your own environment and the scope you agree in writing.
Can message history move from Slack to Matrix?
Slack history can only be exported in the forms your plan allows, and Matrix has no documented Slack importer comparable to the ones Mattermost and Rocket.Chat provide. Every Slack plan can export messages and file links from public channels, while private channels and direct messages need a Business+ or Enterprise export, and custom exports by member or conversation are Enterprise-only. Plan for three options: keep Slack read-only for a defined retention period, archive the exported data in a separate system your legal team controls, or migrate only recent or active conversations by hand. Confirm with your Slack administrator which export you can obtain before you commit to a history strategy.
Can our own staff run the migration without outside help?
Some teams can, if they already run PostgreSQL, Redis and a reverse proxy in production, and have someone comfortable with Synapse configuration, upgrades and federation settings. The harder parts are identity integration, a backup and restore test, a tested upgrade path, and bridge operation during cutover. Synapse upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so an operator who has not run upgrades before carries real risk. Ask whether your team has these skills in writing, then decide whether to hire implementation help for the initial build, ongoing support, or both. DeployOpen plans, implements, hardens and supports self-hosted platforms in your infrastructure, and works from a fixed-scope written agreement.
What does the work need from our staff?
Expect demands on platform engineering, identity administration, security review and the teams that own Slack workflows. Platform engineers run the homeserver, database, Redis and workers as usage grows, and must test restores. Identity administrators connect single sign-on through OpenID Connect, SAML2 or CAS, as Synapse's configuration manual describes. Security staff review federation settings, since federation_domain_whitelist can restrict federation to listed domains or disable it, and the docs recommend firewalling the federation listener. Channel owners must agree on room structure, retention and who gets which permissions. Budget that time as recurring work after launch, not only during the build.
Do Matrix bridges keep Slack channels connected during cutover?
Matrix bridges can relay messages between Matrix rooms and other chat networks, which is how many teams keep a Slack channel and its Matrix room in step during a phased move. Matrix.org maintains a bridges directory, but each bridge is a separate project with its own maintenance status, feature coverage and operating needs, so check each one against your Slack plan, your message types and the Slack apps you use. Bridges also raise questions about who can see relayed content, where bridge credentials are stored, and what happens to edits, reactions, threads and files. Test the bridge with non-sensitive rooms first, and confirm its behavior in writing before you rely on it for regulated conversations.
How does AGPL licensing affect our use of Synapse?
Synapse is licensed under AGPL-3.0, and Element adopted AGPLv3 for future Synapse contributions after announcing the change on December 13, 2023. Running Synapse internally carries different obligations than distributing or offering a modified version to users over a network, and AGPL's network clause means that if you modify Synapse and make it available to others, you must offer them the source. Commercial licenses and the Synapse Pro edition are available from Element, and the Element Server Suite comes as a free AGPL Community edition, a Pro edition and a Sovereign edition for air-gapped use. Have your legal counsel review your actual use case, especially if you customize the server or offer it to partners, and compare the options on Element's pricing page.
How DeployOpen scopes and runs a Slack to Matrix migration
DeployOpen plans and builds a self-hosted Matrix homeserver with Element clients inside your own infrastructure, then migrates your Slack channels and history in a written scope. Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
How we scope
- Inventory which Slack channels, DMs and file types must move, and confirm your Slack plan and export permissions first.
- Agree in writing how much existing history comes across, and what stays in the Slack export archive.
- Define the bridge scope for a phased cutover, including which Slack channels stay connected and for how long.
How we build
- Deploy Synapse with PostgreSQL, federation settings and identity provider integration in your cloud account or data center.
- Configure Element clients, and add Redis and worker processes only when the agreed user load requires them.
- Test restores, federation restrictions and bridge behavior, then document the configuration and firewall rules.
How we hand over
- Deliver runbooks for upgrades, database backups, rollback limits and Synapse version changes.
- Walk your administrators through user provisioning, room administration and retention settings before cutover.
- Provide cutover evidence and configuration records that your internal or external auditors can review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Synapse and PostgreSQL upgrades against upstream support windows, with you confirming each change window.
- Keep the bridge and homeserver versions under review as Matrix releases change, as agreed in the retainer.
