Migrate from Skype for Business Server to Matrix

Migrate from Skype for Business Server to Matrix: what the work involves

If your on-premises Skype for Business estate is due for replacement, treat the move to Matrix as a re-platforming of identity, chat rooms, federation and meetings, not a file copy. Skype for Business keeps users in Active Directory, presence in its own service, persistent chat in group chat objects and partner reach through federation and Edge servers. A Matrix homeserver such as Synapse rebuilds each of those as a different construct: accounts tied to a server_name, rooms made of events, and federation governed by server-to-server rules. Most organizations do this work with an internal platform team supported by an implementation partner for the configuration, hardening and cutover. Expect the effort and risk to sit mostly in identity integration, room design and the federation policy decisions, not in installing the server. Two data points need early attention. Presence and call records in Skype for Business do not map one to one onto Matrix events, so decide which of them you actually need to keep, and for how long, before you plan an export. Synapse's federation settings also need a deliberate decision: federation_domain_whitelist restricts federation to listed domains, an empty list disables it, and the documentation recommends firewalling the federation listener as well. Confirm with Element which Synapse release and PostgreSQL and Python versions your build requires, because the upgrade notes say rolling back can be difficult after schema changes.

Confirm the following in your own environment before you commit to a plan. First, which login method you will use: Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, so check that your identity provider and directory structure fit one of these. Second, whether you need Element Server Suite Pro or Sovereign features, such as support for air-gapped deployments, or whether the Community edition is sufficient. Third, how your Skype for Business federation partners will be reached, and whether they run Matrix at all, since Matrix federation only helps with partners that also federate. Ask Element and your integrator to put each of these points, the support terms and the upgrade path in writing. For the meetings part of the estate, the plan should name Element Call or Jitsi as a separate workstream with its own identity and certificate decisions. Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, so budget time for certificate and DNS work. Decommissioning of front end and Edge servers should follow only after users, rooms and federation have been verified on the new platform. Written scope, a tested rollback plan and a named owner for each workstream are the controls that matter most here.

Which Skype for Business capabilities map to Matrix and Element, and which need rework

This table maps each core Skype for Business capability to its Matrix and Element counterpart and labels the migration effort as clean, needs rework or gap. Read it as a planning checklist: clean rows can usually move with configuration, rework rows need design decisions, and gap rows need a separate tool or a confirmed vendor answer before cutover.

Skype for Business capability	Matrix and Element equivalent	Migration note
One-to-one instant messaging	Direct messages between Matrix users on your homeserver, through Element clients	Clean. Confirm client support for your device fleet and whether message history from SfB must be archived separately.
Persistent group chat	Rooms on Synapse, with membership, history and room permissions	Needs rework. Each persistent SfB chat room must be re-created as a Matrix room, and owners must be assigned because history does not migrate automatically.
Presence and availability	Matrix presence signals from Synapse, shown in Element clients	Needs rework. Confirm how presence states map to your users' expectations and whether presence propagates across federated servers with your vendor.
Directory-based login	Synapse login through OpenID Connect (oidc_providers), SAML2 (saml2_config) or CAS, configured in the homeserver	Needs rework. Map AD groups to identity provider claims and test account lifecycle, including disabling leavers. Confirm the exact AD integration path with Element.
Federation with partner organizations	Matrix federation on port 8448 or delegated on port 443, restricted with federation_domain_whitelist	Needs rework. Partners must run compatible Matrix servers, and an empty whitelist disables federation. Agree trust lists and firewall rules first.
Voice and video meetings	Element Call from Element Server Suite, or Jitsi Meet on your own servers	Needs rework. Choose one service, plan HTTPS certificates and UDP media ports, and confirm integration with Element clients for your meeting types.
Conferencing with dial-in, room systems and PSTN	No direct Matrix equivalent described in the supplied sources; SIP and telephony paths need separate design	Gap. Confirm with the vendor and your telephony team what replaces Enterprise Voice and room system registration.
Edge-based remote access for external users	Synapse federation and client access through your reverse proxy, with the Edge role retired	Needs rework. Confirm which remote access path your users need, publish the homeserver behind a reverse proxy, and test mobile clients from outside your network.

What data and integrations move, and what has to be rebuilt by hand

Skype for Business Server holds several kinds of state: directory identities, persistent chat, archived messages, federation trust and meeting links. Only some of these have a documented path into Matrix and Element, so the cutover plan should treat each one separately and budget manual recreation or archive work for the rest.

User identities from the directory

Matrix does not import Active Directory accounts as a bulk data set. Plan to connect the homeserver to your identity provider through OpenID Connect, SAML2 or CAS, as Synapse's configuration manual describes, so that existing directory accounts sign in and map to Matrix user IDs. Confirm with your identity team how disabled and leaver accounts will be deprovisioned, since Synapse login does not follow Skype for Business account changes automatically. The server_name setting fixes how those IDs are written, so decide it before any user logs in.

Persistent chat rooms and membership

Skype for Business persistent chat rooms and their membership lists have no supplied bulk export path into Matrix. Recreate the rooms you still need as Matrix rooms, set join rules and power levels to match the old owner and member roles, and invite members or grant access through your SSO groups. Inventory which rooms are active before you build anything, because many persistent chat rooms are dormant and do not justify recreation.

Message history

There is no supplied export or import route that carries Skype for Business message history into a Matrix room. Decide whether history must be searchable after cutover. If it must, plan a separate archive built from your Skype for Business compliance or archiving data, held outside the homeserver, and confirm with your records and legal teams how long it must be kept. Do not assume Synapse will hold that history for you.

Federation trust relationships

Skype for Business federation trusts are configured per partner domain, and Synapse replaces them with its own rules. Set federation_domain_whitelist to the partner domains you have agreed with, because an empty list disables federation entirely. Synapse federates on port 8448 by default, so confirm that partners can reach it, and that the federation listener is firewalled to the listed domains. Each partner must make the same change on its side, so schedule those conversations before cutover.

Meeting links, dial-in and room systems

Meeting links and dial-in numbers are not carried over. Jitsi Meet or Element Call will need new meeting URLs, and any Outlook invites or conference rooms that point to Skype for Business must be rewritten by hand. Telephony and room system integrations, such as PSTN dial-in or SIP trunks, have no supplied migration path and need a separate design, since the Jitsi SIP gateway covers only part of that work. List every integration before cutover so that none is discovered after the front end is switched off.

How Synapse logins connect to your directory and partner domains

Decide the identity path and the server_name before any user exists, because both are hard to change later. Synapse does not usually bind straight to Active Directory. Instead, it supports single sign-on through OpenID Connect providers (oidc_providers), SAML2 (saml2_config, using pysaml2) and CAS, so directory-based login is normally built by placing an identity provider in front of Synapse. The Matrix Authentication Service can also broker upstream identity providers, which is a common route when several login methods are needed. Confirm with your identity team which provider already holds your Skype for Business users, how group membership will be passed through, and what happens to accounts when someone leaves. Those answers determine the configuration, not the other way round.

The server_name setting becomes part of every user ID (for example, @user:example.com) and room identifier, so it is effectively permanent for the life of the deployment. Federation uses port 8448 by default, but delegation lets user IDs be served from another host on port 443, which is useful when your Matrix hostname sits behind an existing web platform. Test delegation with your network team before you publish the name to users. Note that delegation changes where federation traffic is sent, not which domain identifies users, so the naming decision still comes first.

Federation is the control that replaces Skype for Business federation with partner organizations. The federation_domain_whitelist setting limits federation to the domains you list, and an empty list disables federation entirely. Build the list from a named, approved set of partner domains owned by your security or governance function, and review it on a fixed schedule. The Synapse documentation also recommends firewalling the federation listener so that only listed peers can reach it, which protects you if the configuration is later changed by mistake. Ask your security team to confirm the firewall rules and the approval process before go-live.

Migration sequence from inventory to Skype for Business decommission

This sequence moves chat, presence and federation to a self-hosted Matrix homeserver in controlled stages, so each stage produces evidence that the next one can rely on before any Skype for Business component is switched off.

Inventory users, rooms, partners and meetings
Your identity team and Skype for Business administrators list enabled users and their directory groups, the persistent chat rooms and their members, every federation partner and its domain, and the meeting dependencies such as conference dial-in, room systems and calendar integrations. Record how Edge servers are exposed, including which external ports and public names reach them. The output is a signed-off inventory workbook that names an owner for each row and flags anything with no known replacement, such as telephony or room systems that Matrix does not provide.
Build a pilot homeserver and test sign-in
Deploy a Synapse homeserver on a single test domain, with PostgreSQL as the production database and the federation listener firewalled until you need it. Connect a test identity provider through OpenID Connect or SAML2 and confirm that directory accounts sign in and map to the expected Matrix user IDs. Install Element clients on test devices. Before you rely on any upgrade, run the upgrade path from one Synapse release to the next on the pilot, since the Synapse upgrade notes warn that rolling back can be difficult because of database schema changes. The output is a documented build, a tested upgrade procedure and a sign-in test report.
Run both systems and recreate key rooms
Keep Skype for Business live while a small pilot group and the owners of priority rooms use Matrix in parallel. Recreate the persistent rooms that matter as Matrix rooms, set their membership and history rules, and agree with users which conversations stay in Skype for Business until cutover. Test meeting calls through Element Call or Jitsi and confirm that audio, video and screen sharing work across the network paths your users have. The output is a room register, a list of known gaps with owners, and a pilot user sign-off.
Cut over by user group and partner
Move users in groups, starting with the pilot group and then broader departments, and update client setup and sign-in guidance for each group. Turn on federation partner by partner using federation_domain_whitelist, so only domains you have approved can exchange messages, and firewall the federation listener as the Synapse documentation recommends. Monitor sign-in failures, delivery problems and partner feedback after each group moves. The output is a cutover log per group and a list of approved federation domains with the date each was enabled.
Decommission client and meeting paths first
Once all users in scope are on Matrix and meetings run on the new service, stop routing client and meeting traffic through Skype for Business. Disable the Skype for Business federation and client access settings, then remove the relevant meeting and dial-in endpoints from user devices and calendar templates. Keep a rollback path documented until the next stage is complete. The output is a signed record that no production users or partners use Skype for Business client or meeting paths.
Retire front end pools, then Edge servers
After the client and meeting paths are quiet, drain and remove Skype for Business front end pools, back-end databases and their dependent services, keeping backups under your retention policy. Retire Edge servers last, because they carry external access and partner traffic, and remove their public DNS records and firewall rules only after confirming no partner still depends on them. Archive configuration and logs as evidence of the change. The output is a decommission record for each server role, a DNS and firewall change log, and a final archive stored in your own infrastructure.

What drives migration cost and duration, and how to hold each one down

This table lists the factors that most change the effort of moving from Skype for Business Server to a self-hosted Matrix and Element stack, why each one moves cost or time, and how to reduce it. Read it before requesting a quote, because each driver is a question the written scope should answer.

Driver	Why it moves cost or time	How to hold it down
Rooms and members to recreate	Skype for Business persistent chat rooms do not carry over as Matrix rooms, so each room, its membership and its access rules must be rebuilt or recreated by script.	Inventory persistent chat rooms before scoping. Retire inactive rooms, consolidate duplicates and script recreation for the rest.
Partner federations and trust terms	Each Skype federation partner needs a matching Synapse federation decision, plus agreed domains, delegation and trust rules on both sides.	List every partner domain and its trust terms in writing. Use federation_domain_whitelist to start with a short, approved list.
Directory and SSO complexity	Login through LDAP or single sign-on depends on how many directories, domains and identity providers exist, and on how cleanly user identifiers map to Matrix IDs.	Document the directories and identity providers in use. Confirm which Synapse SSO option (OpenID Connect, SAML2 or CAS) your identity provider supports before scoping.
Meeting platform choice (Element Call or Jitsi)	Element Call and Jitsi have different deployment footprints, authentication options and certificate needs, so the choice changes the server build and testing.	Decide the meeting platform early. Ask the implementer to size each option against your peak concurrent meetings and remote users.
PostgreSQL and Python version alignment	Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Older base systems may need upgrades first.	Check current database and Python versions against the Synapse upgrade notes. Include any base OS or database upgrade as a separate line in the quote.
Edge-dependent remote users	Remote Skype users depend on Edge servers for federation and media traversal. Each remote population needs a replacement path before Edge can be retired.	Count remote users and the networks they use. Confirm the replacement remote access route and test it with a pilot group before removing Edge.
In-house skills available	Running Synapse, federation, workers and a meeting service needs staff who can operate Linux, PostgreSQL, Redis and TLS certificates, and who can manage upgrades.	Assess skills honestly. Ask for a written handover plan and runbooks, and decide who does upgrades and on-call support after go-live.

What usually goes wrong in a Skype for Business to Matrix migration

Most failed Matrix migrations are not caused by the software itself. They come from decisions made early, such as domain naming and federation scope, and from assumptions about what carries over from Skype for Business. The cards below cover the risks that are hardest to reverse and the checks to run before cutover.

Federation opened too widely

Synapse federates by default once a homeserver is reachable, so a server built for internal staff can start exchanging messages with any domain on the internet. Set federation_domain_whitelist to the partner domains you have agreed to, and firewall the federation listener on port 8448 so only those networks can reach it. Test with a partner account before go-live, and confirm the list in your change record.

Server name chosen badly

The server_name setting becomes part of every user ID and room ID, such as @user:example.com, so it is effectively permanent once accounts exist. Pick the domain that will still be correct after a rebrand or an acquisition, and plan delegation so the public name can point at the host. Ask your architects to confirm the name in writing before the first account is created.

Presence and call history expected to carry over

Skype for Business presence, call logs and the contents of Outlook-linked meetings do not move into a Matrix homeserver. Users who expect their history to appear on day one will treat the cutover as a failure. Tell users which data stays behind, agree on whether an archive is needed for records retention, and confirm with your compliance lead which conversations must be exported before decommissioning.

Self-signed certificates breaking Jitsi and mobile

If Jitsi is used for meetings, audio and video depend on HTTPS with a certificate issued for the correct domain. The Jitsi handbook warns that self-signed certificates cause problems, especially on mobile clients. Use certificates from your internal or public CA for the Jitsi host, test on iOS and Android before users receive the link, and confirm that the trust chain is installed on managed devices.

Rollback after Synapse schema changes

Synapse upgrades can change the database schema, and the upgrade notes warn that rolling back can be difficult. Treat each version bump as a one-way step: take a PostgreSQL backup and a copy of the configuration before every upgrade, read the upgrade notes for the target version, and rehearse the restore on a separate host. Confirm PostgreSQL and Python versions against the release notes before scheduling.

Edge retired before remote users have a path

Skype for Business Edge servers carry remote, federated and external access for staff outside the network. Removing them before Element clients, the Matrix reverse proxy and any Jitsi access path are working for remote users leaves people unable to chat or join meetings. Keep Edge running until a remote test user has completed login, messaging and a call from outside the network, then retire it in a separate change.

How the migration changes by estate size and starting point

A single-site estate with no external federation is the simplest starting point. Users, presence and persistent chat sit on one front end pool, and nothing outside the organization depends on Skype federation. That usually means the Matrix homeserver can be stood up on a single domain, with federation turned off until there is a reason to enable it. The sequence can be short: build the homeserver, connect login, move a pilot group, then move everyone else.

Federation scope: Set federation_domain_whitelist to an empty list so the homeserver does not federate, and firewall the federation listener as the Synapse documentation recommends.
Identity: Connect LDAP or an OpenID Connect provider before the pilot so user IDs match the directory from the start.
Rooms: Recreate persistent chat rooms in Element and decide which Skype history is worth an export, since Skype history does not move automatically.
Decommission order: Retire the front end pool only after users and rooms are confirmed on Matrix, then remove any dependent services.
Server name: Choose the server_name carefully at the start, because it fixes how users and rooms are identified.

Before cutover, confirm with your own team which Skype for Business features are actually in use, such as response groups or dial-in, since chat is only one part of what the front end provides.

A multi-site estate with several partner domains has more moving parts. Each site may have its own pool, its own DNS and its own Active Directory forest or domain, and partner organizations may be reached through Skype federation today. Federation becomes the central design decision, because each partner domain needs an explicit agreement on the Matrix side before traffic can flow.

Federation scope: List each partner domain in federation_domain_whitelist only after agreeing it with that partner, and keep the list short at first.
Delegation: Plan well-known delegation so that user IDs such as @user:example.com can be served from a host on port 443 rather than requiring every site to expose port 8448 directly.
Scaling: Consider worker processes with Redis early if several sites will connect to one homeserver, since the generic worker handles client, federation and event traffic.
Cutover: Move one site at a time and keep the other sites on Skype until the first site's rooms and partners are stable.
Decommission order: Retire front end pools site by site, and only after no partner still expects the old federation route.

Ask each partner which Skype federation features they rely on today, since Matrix federation covers messaging and rooms but may not replace every presence or conferencing behavior.

Questions buyers ask before moving from Skype for Business to Matrix

What does a Skype for Business to Matrix migration cost, and which parts are paid for?

The software cost can be zero for the community components, but the migration is not free. The main cost components are the Matrix homeserver (Synapse under AGPL-3.0 is free to run), the database (PostgreSQL is recommended for production), Redis if you scale with workers, the servers and storage underneath, the Element clients, the meeting service, and the people who plan, configure, test and cut over the system. Element Server Suite is sold in Community, Pro and Sovereign editions, so a support or licensing line only appears if you choose a commercial edition. Ask for a quote that separates one-time work (design, migration, testing, documentation) from recurring work (upgrades, patching, backups, support) and states what each line includes.

How long does a migration off Skype for Business Server take, and what sets the duration?

No fixed duration is supplied for this migration, so treat any number you see as a question to ask, not a commitment. The main drivers are the number of users and rooms, how many Skype for Business federation partners you must replace, whether login moves to LDAP or SSO, how much room history you need to carry over, and how many meeting and telephony dependencies sit outside the chat platform. Running both systems in parallel usually lengthens the plan, so ask the vendor or partner to show the parallel period, the decommission order for Edge and front end servers, and the acceptance criteria for each phase in the written scope.

What does the internal team need to provide for the migration?

Your team needs access and decisions more than new skills. Identity owners must confirm the directory source for login (LDAP or SSO through an OpenID Connect, SAML2 or CAS provider), network and DNS owners must plan the server_name, federation listener and any delegation, and operations staff must own the Linux, PostgreSQL and Redis platform after handover. Someone must also decide which Skype for Business rooms and federation contacts matter, and which legal or records requirements apply to retained chat. Ask for a RACI in the quote that names each internal role and the hours you should expect from it.

Can our own team run the migration without an implementation partner?

Yes, a capable internal team can do it, provided it has experience with Linux server administration, reverse proxies, DNS, certificates, PostgreSQL and identity federation. The Synapse documentation covers upgrades, workers and federation, but it also warns that rolling back can be difficult because of database schema changes, so a tested upgrade and backup procedure matters from day one. A partner is most useful for a fixed-scope design review, a documented cutover and a handover that your team can operate. Whichever route you choose, write down who owns the upgrade calendar, because Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life.

Do presence and call history carry over from Skype for Business?

Usually not in the way you might hope, so plan for it explicitly. Skype for Business presence is tied to its own client and server, and Matrix presence is a different model, so you should test how presence appears to users before cutover rather than assume a match. Call and meeting history from Skype for Business is generally not a Matrix data type, so any retained records need an export from the source system and a separate archive. Message history is a different question: it depends on what you export and where you store it, and your records retention policy should decide that before the cutover date.

How do the Element Server Suite editions differ from community Synapse?

Community Synapse is AGPL-3.0 software you can run yourself, while Element Server Suite packages Synapse with other components and offers editions for different needs. Per the supplied facts, the Community edition is free and AGPL and includes Synapse and Element Call, the Pro edition includes Synapse Pro, and the Sovereign edition targets air-gapped deployments. Element also began selling AGPL exceptions after its December 13, 2023 change to Synapse licensing. Ask Element for the feature list, support terms, update cadence and licensing conditions of each edition, and confirm whether your intended use needs an AGPL exception before you commit.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Skype for Business Server to a Matrix homeserver with Element clients runs in your data center or cloud accounts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Skype for Business feature in use, including persistent chat, federation partners, Edge-dependent external access and meeting dial-in.
Define in writing which identity source (LDAP or SSO) the Matrix login will use and which user groups move first.
Agree the decommissioning order for front end, Edge and related servers, with rollback points for each stage.

How we build

Deploy the Synapse homeserver with PostgreSQL, set server_name and delegation, and configure the chosen LDAP or OIDC login.
Test federation settings, including federation_domain_whitelist, and firewall the federation listener as the documentation advises.
Set up Element Call or Jitsi for meetings, with HTTPS certificates on a proper domain, and test audio and video across client types.

How we hand over

Deliver runbooks for backups, Synapse upgrades, database version requirements and the rollback limits described in the upgrade notes.
Document the room migration approach, user communication, and the cutover and coexistence period agreed in the scope.
Provide configuration records and evidence of tests so your security and compliance teams can review the system and assess it independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Synapse and client version upgrades, security testing of the homeserver and meeting services, and backup restore checks.
Confirm with us during scoping which support levels, response expectations and upgrade cadence the retainer will include.

Migrate from Skype for Business Server to Matrix and Element