Migrate from Webex to Matrix and Element Call: what the move involves
Organizations replacing Webex messaging and meetings at the same time usually do so after a renewal, a data residency review or a concern about lock-in, and they need to know early that this is a platform rebuild. Chat, identity, media and data each have their own work streams: a self-hosted Synapse homeserver with Element for messaging, Element Call for voice and video, single sign-on from your existing identity provider, and a plan for the Webex content you keep. Nothing in a Webex tenant maps directly onto a Matrix deployment, so treat the project as a set of parallel builds that must meet at a cutover date rather than as an export followed by an import.
Internal platform or security teams usually lead this work, with an implementation partner covering the parts they have not run before, such as the Matrix server, the media stack and the operations runbooks. Effort and risk depend mainly on how many users, rooms and integrations you move, how much you rely on Webex-specific features and how many people will run the service after go-live. The supplied research gives no duration for this kind of project, so ask any partner for a written scope that lists each work stream, its owner and its acceptance test. Confirm the current Synapse release, the PostgreSQL and Python versions it requires and the upstream end-of-life dates for those runtimes before you fix a plan, because the upgrade notes warn that rolling back a Synapse release can be difficult.
The main decision is whether the identity model, server name and federation policy are settled before any user is created, because changing server_name later changes how users and rooms are identified. Decide early whether the homeserver will federate at all (an empty federation_domain_whitelist disables it), and confirm which single sign-on method your directory supports, since Synapse offers OpenID Connect, SAML2 and CAS. Plan the cutover around a short freeze period, a parallel run for pilot groups and a rollback decision point that is tested in advance, and ask your partner to show how each Webex retention obligation will be met before the Webex tenant is closed.
Which Webex capabilities map to Matrix and Element Call, and which need rework
This table maps each major Webex capability to its closest self-hosted Matrix equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes, which name the services you must operate and the items you must confirm before committing. The main takeaway is that messaging maps well, while meeting media, room devices and Control Hub administration need separate planning.
| Webex capability | Matrix and Element equivalent | Status and notes |
|---|---|---|
| Spaces and team messaging | Synapse rooms and spaces in Element clients | Clean for chat. Map Webex spaces to rooms and plan room naming, membership and retention policies before import. |
| Direct messages | Synapse direct rooms in Element | Clean. Confirm how encryption defaults and key backup will be handled for users who switch devices. |
| File sharing | Media uploads stored by Synapse in the media store | Needs rework. Size the media store and confirm file types, size limits and retention with your data owners. |
| Meetings with video and audio | Element Call, which relies on a separate LiveKit SFU and authorization service | Needs rework. You operate the LiveKit SFU and authorization service alongside Synapse, and must confirm their deployment model with the vendor. |
| Control Hub administration | Synapse admin API and server configuration files, with no direct equivalent to Control Hub | Gap. Confirm which admin tasks you need and how they will be scripted or handled by your own tooling. |
| Single sign-on | Synapse OpenID Connect, SAML2 and CAS support | Clean in principle. Confirm the identity provider you use supports one of these protocols and test group mapping. |
| Room devices and SIP or hardware systems | No direct Matrix equivalent for Webex room device support | Gap. Confirm with your vendor which room systems, if any, can join Element Call, and plan for separate hardware if needed. |
| Video Mesh on-premises media nodes | No Matrix counterpart | Gap. Video Mesh has no Matrix equivalent, so on-premises media design must be planned from scratch. |
| Meeting recordings and transcripts | No built-in equivalent in Element Call for recordings in the Webex format | Needs rework. Export recordings from Webex first and confirm storage, retention and access for archived files. |
What data can leave Webex, and which integrations to rebuild
A Webex move has two halves: the content you can export and the identity and automation you must rebuild on the Matrix side. Message history and recordings follow different paths, and most integrations need a deliberate replacement rather than a copy.
Meeting recordings from Webex
Recordings can be retrieved through the Webex recordings API or downloaded from the site. Plan a batch export with a clear inventory of which recordings are needed, because the export path and file formats depend on how each recording was stored. Confirm with Webex which recording types, file formats and retention settings apply to your site before you schedule the work, and check whether any recordings sit under a user who has left the organization.
Messaging history and what it can carry
Message history cannot be imported into Matrix rooms as-is. Decide early whether you archive the Webex export as read-only files, keep a searchable read-only copy, or start new rooms with no backfill. Each choice has a different cost and retention profile, and the decision belongs in the cutover plan, not in the final week.
Confirm the Webex export scope
Ask Webex in writing which messaging data the site lets you export, in what form, and for which time range. Export scope varies by plan and site configuration, so the answer should be recorded as a contract or migration assumption. Confirm also whether file attachments, reactions, and space membership lists are included.
Identity mapping to Synapse sign-in
Map each Webex identity to a Matrix user ID under your server_name, then decide the sign-in path. Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config, and CAS. Confirm which of these your identity provider supports, and plan how existing display names and email addresses will map to new accounts.
Bots, calendar links and integrations
Webex bots, calendar invitations, scheduling links, and connectors to ticketing or monitoring tools do not transfer automatically. List each one with its owner and function, then rebuild it against Matrix APIs or bridges where a suitable bridge exists. Confirm bridge support for each system before assuming a replacement, since coverage varies.
Meeting links and room device integrations
Existing meeting links in calendars, email templates, and intranet pages point at Webex and will stop working after the cutover. Build a list of every place a Webex link lives, plan redirects or replacement messages, and confirm with Webex how long links remain active after you stop paying for the service. Room systems that dial Webex need their own replacement plan.
Migration sequence from inventory to Webex decommissioning
This sequence moves a Webex messaging and meetings estate to a self-hosted Matrix server with Element and Element Call in controlled stages, so each phase produces evidence before the next one starts. Webex is switched off only after the archive has been verified.
Inventory rooms, spaces, users and integrations
Export a list of Webex spaces, memberships, meeting schedules, licensed users, guest accounts, bots and integrations that post into spaces or start meetings. Mark each item as keep, migrate, archive or retire, and record who owns it. Confirm with Webex administrators which export options your tenant and plan actually allow, because message history and recordings may need different tools. The output is an inventory register, reviewed by the business owners of each space, that becomes the single source for later phases.
Pilot on a non-production Synapse
Deploy a non-production Synapse homeserver with PostgreSQL, Element Web and Element Call, and set server_name once because it fixes how user and room identifiers are written. Enroll a small pilot group, connect identity through your chosen single sign-on provider, and run test calls across the browsers and devices your users have. Rehearse a backup and restore of the database and media store. The output is a tested backup and restore record and a pilot report listing defects and their fixes.
Decide federation and access controls before parallel run
Set the federation policy with the security team before any real users join. Use federation_domain_whitelist to list only approved partner domains, or leave it empty to disable federation, and firewall the federation listener as the configuration manual recommends. Document which accounts can create rooms and which networks can reach the homeserver. The output is an approved access and federation standard, signed by the CISO or delegate, that the cutover checklist references.
Run a parallel period with coached users
Keep Webex and Matrix open at the same time. Move migrated spaces into Matrix in a defined order, publish short guides on creating rooms, joining Element Call and finding recordings, and hold coaching sessions for each group. Track which teams still post in Webex and why, and close the gaps with the owners. The output is a usage log and a list of unresolved blockers with named owners, reviewed weekly until the blockers are cleared.
Verify the archive before cutover
Export the Webex content you must keep, including recordings and messages, in the formats the vendor provides, and store them in a retention location you control. Check that a sample of each type opens and that counts match the inventory register. Confirm that anything you cannot export, such as content the platform does not release, is recorded as an accepted loss. The output is a verified archive report signed by the data owner and the compliance lead.
Cut over identities and rooms on a dated switch
Choose a cutover date, freeze new Webex space creation, migrate remaining rooms and set Webex meeting links to point to the new Element Call entry points. Switch user sign-in to the production identity provider and confirm that the production backup job has completed a successful run before the switch. Use a written checklist covering DNS, certificates, TURN and network paths, and rollback steps with the criteria that trigger them. The output is a signed-off cutover checklist with timestamps for each action.
Decommission Webex after the archive is confirmed
After a stable period in production, remove Webex user licenses and integrations, revoke API tokens and service accounts, and disable the Webex site. Keep the verified archive and its access logs under the retention policy that applies to your records. Record the decommissioning decision and remove the Webex items from the access review. The output is a decommissioning record confirming that licenses, integrations and credentials were removed and that the archive is retained.
What drives cost and duration in a Webex to Matrix move
This table breaks down the cost components of replacing Webex messaging and meetings with a self-hosted Matrix stack, and the drivers that push each one up or down. Read it as a checklist for comparing written quotes, since the components are paid to different parties and recur at different rates.
| Cost component | Who is paid or who carries it | What drives it up or down |
|---|---|---|
| Internal staff time | Your platform, identity and security staff, plus messaging administrators | Number of Webex spaces to map, admin familiarity with Matrix and Element, and how much change control your organization requires |
| Synapse and worker infrastructure | Your cloud or data center budget, and the implementer for sizing and deployment | Concurrent users, message volume, and whether you add worker processes and Redis for scale |
| PostgreSQL | Your database operations team or managed database service provider | Database size after message history migration, backup retention, and high availability requirements |
| TURN and Element Call media | Network and infrastructure teams for bandwidth and TURN hosting | Number of simultaneous calls, participant counts per call, and media bandwidth available on your network |
| LiveKit and authorization services | Your operations team, plus any implementer work to integrate them | Number of call components to run and monitor, and whether they sit in the same environment as Synapse |
| Identity integration (SSO) | Identity team and implementer for OpenID Connect, SAML2 or CAS configuration | Number of identity providers, attribute mapping rules, and whether group-based access must be replicated |
| Testing, migration and training | Implementer for test plans and cutover work, and internal users for acceptance and training | Number of integrations, recording volume to move, and number of user groups needing separate guidance |
| Ongoing operations and upgrades | Your operations staff, or a retainer with an implementer for upgrades and support | Upgrade frequency, Python and PostgreSQL version support windows, and how much testing each release needs |
What usually goes wrong and how to prevent it
Most failed Webex to Matrix migrations fail on operations, not features: a server that cannot be rolled back, a federation listener nobody meant to open, or a parallel run that never ends. The cards below name the risk, why it matters for this move, and the check that prevents it.
Rollback after schema changes
Synapse releases change the database schema, and the upgrade notes warn that rolling back can be difficult. Treat each Synapse upgrade as a one-way step unless you have tested a restore. Before every upgrade, take a consistent PostgreSQL backup, rehearse a restore on a separate host, and record the exact version you are moving from. Confirm the rollback path with your Element contact or in the upgrade notes before the change window opens.
Unsupported PostgreSQL and Python
Synapse drops support for Python and PostgreSQL versions once upstream reaches end of life, so a server that runs unchanged for a year can fall out of support without any visible fault. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Put database and runtime versions on your patch calendar, and check them against the release notes before you plan each Synapse upgrade.
Federation exposed by accident
Synapse federates on port 8448 by default, so a server built with a public listener can talk to any homeserver unless you restrict it. For a company that only needs internal chat, set federation_domain_whitelist to the domains you intend to allow, use an empty list if federation is not needed, and firewall the federation listener at the network edge. Test from an outside host that port 8448 is closed when it should be.
HTTPS and TURN misconfiguration
Element Call depends on correct HTTPS on every public hostname, and calls fail in ways that look like client bugs when certificates, delegation or media relay are wrong. Check the certificate chain for the homeserver, the Element web host and the call components, confirm that delegation resolves user IDs such as @user:example.com to the right host on port 443, and test calls from networks outside the office. Confirm with your network team which media ports and relay paths your firewalls allow before users are moved.
Parallel chat in Webex
During a parallel run, teams that keep messaging in Webex split their conversations across two systems, and the Matrix room history stays incomplete. Set a dated freeze for each team, announce it with the new room links, and make Webex spaces read-only once the move is complete. Ask the business owners to confirm which spaces must move before the freeze, not after it.
Losing archive access
Webex retention settings and export rights control what you can take out, and a contract ending can cut access faster than the migration plan expects. Export message and file archives while the Webex contract is still active, store them in a location your compliance team controls, and check the result by opening samples. Ask Webex and your compliance lead what can be exported, in which format and for how long access remains after the end date.
How the migration differs by organization size and starting point
A single-site organization with a modest user base usually has the smallest migration. One Matrix homeserver, one identity source and one set of rooms can cover the whole company, and the main work is moving people and their history across in a short, planned window. The design can stay simple: a single Synapse instance with PostgreSQL, Element for clients and Element Call for meetings, with federation switched off unless there is a reason to talk to other servers. Because there are few moving parts, the cutover can usually be run as one event with a clear rollback point.
- Scope: Map the Webex spaces that matter and archive the rest, rather than recreating every historical space.
- Identity: Decide whether accounts are created locally or come from the existing directory through an OpenID Connect or SAML2 provider configured in Synapse.
- Federation: Keep the federation setting restrictive (an empty list disables federation) unless partners need to reach you.
- Cutover: Run one dated switchover, with a freeze on new Webex spaces and a short period of parallel access.
- Operations: Confirm who will apply Synapse upgrades, since upgrade notes warn that rollback can be difficult after schema changes.
Before committing, confirm with your team how many users and concurrent meetings you expect, and whether the single site has a stable connection for Element Call media.
A multi-site or regulated organization has more to decide before any server is built. Federation becomes a policy question, data residency determines where the homeserver and its database sit, and identity must reflect the way staff are onboarded and removed across sites. Requirements from internal policy or external frameworks should be written down first, because they drive the architecture. Plan for separate environments for test and production, and for a documented change process for each Synapse release.
- Scope: Define which sites, business units and data categories move in each wave, and which Webex content must stay in its original platform until retention rules are met.
- Federation controls: Use the federation domain allowlist to name exactly which domains may federate, and firewall the federation listener as the Synapse documentation recommends.
- Residency: Confirm the physical location of the homeserver, PostgreSQL database, media store and any Element Call components, since all of them hold user content.
- Identity: Connect Synapse to the corporate identity provider and agree how deprovisioning reaches chat accounts.
- Cutover: Stage the rollout site by site, so each region has a tested sign-in path and a named support contact.
Ask your compliance lead which evidence the assessor will expect for access control and change management, and confirm those requirements in writing before design begins.
An organization already running Element or Synapse for other purposes starts from a different position. The homeserver exists, users may already be signed in through single sign-on, and some teams have rooms and habits in place. The migration question becomes whether Webex content and users join the current deployment or need a separate one, and whether Element Call is already enabled. Mixing Webex users into a live production server raises capacity, naming and governance questions that should be answered before any import.
- Scope: Decide whether the existing homeserver will host Webex migrants or whether a new instance will keep the two populations separate.
- Capacity: Review database size, worker processes and Redis usage against the expected added load, since Synapse scales through workers.
- Identity: Reuse the current OpenID Connect, SAML2 or CAS configuration where possible, and check that new users land in the right account domain.
- Versions: Check the installed Synapse release against the upgrade notes for required PostgreSQL and Python versions before any change.
- Cutover: Announce the change to existing users, because new Webex rooms may appear in their room lists.
Confirm the current Synapse version, its server_name and its federation settings before deciding, because changing those later affects every identifier already in use.
Some organizations do not move everything at once. They keep Webex for one group, move another group to Matrix, and leave certain meetings on the old platform while the new one proves itself. This phased approach reduces the chance of a single large failure, but it adds coexistence work that a single-site or single-cutover plan avoids. Users need a clear rule for which tool to use, and support teams need to know which system holds each record.
- Scope: Write down which teams, rooms and meeting types belong to each platform in each phase.
- Coexistence: Agree how people in both groups will find each other, and whether external invitations stay on Webex during the transition.
- Identity: Avoid two sources of truth for the same person by linking accounts to one directory.
- Records: Track where recordings and chat exports sit, using the Webex export guidance and your own retention policy.
- Cutover: Set a date for each phase and a date for retiring the old platform, and record any exceptions.
Before starting a phase, confirm with the business owners which conversations must not be interrupted and which can be paused.
Questions buyers ask before moving from Webex to Matrix
How much effort and cost does a move from Webex to Matrix involve?
The cost is mostly people time and infrastructure, not software licences, because Synapse and Element are open source. Plan for one-time work: server design, deployment, identity integration, client rollout, migration of users and rooms, and training. Recurring costs are the servers and bandwidth you run, the staff who patch and upgrade Synapse and its database, and backups. Costs rise with user count, the number of rooms and history to move, the number of integrations (single sign-on, bridges, Element Call infrastructure), and how many sites need media close to users. Costs fall when you reuse existing identity and database operations skills. Ask any quote to itemize each of these components separately, and to state which items are one-time and which recur.
How long does a Webex to Matrix migration take?
Duration depends on scope, and no fixed timeline applies to every organization. The largest variables are the number of users and rooms, the volume of history you need to keep, how many identity and access integrations must be wired up, and whether you run a parallel period where both Webex and Matrix are live. Synapse upgrade planning also adds time, since the upgrade notes warn that rolling back can be difficult because of database schema changes between releases. A pilot group followed by staged waves usually takes longer than a single cutover, but it lowers risk. Ask for a written schedule with milestones and an explicit parallel-run period before work starts.
What does our team need to provide for the project?
Your team needs to supply decisions and access more than hands. Expect to define the server_name for your users and rooms, since it fixes how identities are written and cannot be casually changed later. You will need a DNS and TLS plan, a database host that meets the PostgreSQL version Synapse requires, network rules for media and federation ports, and an identity provider for single sign-on through OpenID Connect, SAML2 or CAS. Someone must own the Webex side too: usage inventory, a list of spaces and their members, retention rules and the sign-off on what history is migrated. Confirm these responsibilities in the scope document so gaps are visible before the project starts.
Can our IT team run this migration alone, or do we need outside help?
A capable platform team can deploy Synapse, Element and Element Call from the published documentation, and many do so for pilots. Outside help is most useful where the risk concentrates: architecture for scale, the workers and Redis layout, federation controls, identity integration, upgrade and rollback planning, and the migration of messages and users from Webex. Fixed-scope engagements with DeployOpen cover planning, implementation, customization, integration, hardening, backup and documentation inside your infrastructure, and ongoing support or upgrades can run as a retainer. DeployOpen does not issue audit reports or certifications, so compliance evidence still comes from independent auditors.
Does chat history from Webex move to Matrix?
Not automatically, and you should not assume it does. Matrix has no built-in importer for Webex spaces, so historical messages need a documented export and a conversion or import path that your team or implementation partner must build and test. Message attachments, reactions, edits, thread structure and membership history may map imperfectly. Some Webex data may not be exportable in a usable form at all. Before committing, ask the Webex administrator what export formats your tenant provides, request a sample conversion in a test room, and decide which history must be kept, which can be archived read-only, and which can be left behind.
Does Element Call fully replace Webex meetings?
Element Call covers voice and video calls on Matrix, but check it against your meeting requirements before assuming full replacement. Confirm the features you rely on today, such as large meetings, recording, webinar-style broadcasts, dial-in from phones, room systems and calendar integration, and test each in a pilot. Element Call uses a LiveKit SFU and related authorization services that you must operate, so the media path, capacity and failure handling need their own design. Where a feature is missing, a parallel meeting tool such as Jitsi Meet or BigBlueButton may be a better fit for that use case, and this should be decided in the scope rather than discovered after cutover.
How does licensing differ between Element Server Suite Community and Pro?
The Element Server Suite Community includes Element Call alongside Synapse, and it is distributed under the AGPL, so you can deploy it without a licence fee. Element's commercial terms are separate: Synapse is developed by Element and distributed under AGPL-3.0, with commercial licenses also available from Element, and since December 13, 2023, contributions to Synapse have been licensed under AGPLv3 with contributors signing a CLA. If your organization wants to avoid AGPL obligations for modified code, a commercial exception is one option. Confirm the exact features of the Pro edition on Element's pricing page and ask for licence terms in writing before choosing either path.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Webex messaging and meetings to Matrix with Element and Element Call, we start with the written scope, then build and test the platform in your environment before any user is moved.
How we scope
- Inventory which Webex spaces, meeting types and integrations need replacing, and which stay until a later phase.
- Agree in writing the Synapse homeserver, database, Element Call and TURN components, and the identity provider used for sign-in.
- Confirm federation posture, retention rules and where chat and media data must physically reside before design starts.
How we build
- Deploy Synapse with PostgreSQL in your infrastructure, with server_name and delegation planned before any users are created.
- Configure Element Call with its supporting services, then test audio, video and screen sharing across your network paths.
- Run security testing on the homeserver, APIs and the federation listener, and document the firewall rules that restrict federation.
How we hand over
- Provide runbooks for upgrades, database backups, worker scaling and Synapse version changes, including the rollback limits in the upgrade notes.
- Document the configuration keys, access model and compliance evidence your auditors will request, without issuing any audit report.
- Run a cutover rehearsal with a pilot group, then agree the go-live and Webex decommissioning steps in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan recurring work for Synapse releases, PostgreSQL and Python version support, and certificate renewals.
- Confirm with us during scoping which parts of the migration are fixed-scope and which should move to a retainer.
