Skype for Business Server vs Matrix and Element: which fits your estate
Skype for Business Server fits estates committed to Microsoft server infrastructure and Server/CAL licensing, while Matrix with Element fits teams that want self-hosted chat, federation with partner organizations and an open-source server they can run themselves. The decision turns on four questions: how deeply your identity, Exchange, Active Directory and telephony already depend on Microsoft components, whether conferencing and voice must stay on the same platform, who will operate a Synapse homeserver day to day, and whether federation with outside organizations is a requirement or a nice-to-have. Answer these before comparing license quotes, because they determine how much of the estate moves at all.
Start with the dependency inventory. List every workload that touches Skype for Business today, including Enterprise Voice trunks, room systems, Edge-based external access, and any application that uses the Skype for Business client libraries. Each item will either have a replacement in the Matrix ecosystem, need a separate product such as Jitsi for meetings, or stay on Microsoft infrastructure. Confirm with your telephony and room-system vendors which of these they support with a Matrix-based chat stack, since that support is not a given. If your organization also runs a Subscription Edition renewal, price the licenses that would remain in place during any transition period.
Next, assess operating ownership. A Synapse homeserver is a Python application that normally runs on PostgreSQL and, for scale, uses Redis and worker processes, and Element Server Suite adds commercial support and editions for specific deployment needs. Identify the team that will own upgrades, database maintenance and federation settings, and confirm they can handle schema changes that make rollback difficult. Federation is the final test: if partner organizations must reach your users directly, plan the server_name, delegation and federation listener, or decide that a closed deployment with a federation whitelist is enough.
Which option fits which scenario
This table matches common Skype for Business Server situations to the option that fits best: staying with Microsoft, self-hosted Matrix with Element, or Element Server Suite. Read each row for the condition that makes the advantage matter, and confirm licensing and support terms with the vendors before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Active Directory and Microsoft licensing are central, and the estate must stay on Microsoft stack | Stay with Microsoft (Subscription Edition or Teams, as licensed) | Matrix needs an identity bridge (LDAP, OIDC or SAML) and separate operations. This only pays off if you are moving away from Microsoft licensing anyway. |
| Regulated organization must host chat in its own data center with a self-managed server | Matrix with Synapse, or Element Server Suite Pro or Sovereign | Synapse runs in your own infrastructure with full control of message storage. Confirm your regulator's expectations for retention and audit logs with your assessor. |
| Multi-organization program needs federation with partner organizations | Matrix with Element | Matrix federates between homeservers by design, with server_name and delegation controlling identity. Partners must also run federation-capable servers, and you must agree on allowed domains. |
| Team has no Linux or PostgreSQL operations skills | Element Server Suite or a managed-by-partner deployment, or stay with Microsoft | Synapse expects PostgreSQL and Redis for scale, and upgrades can be hard to roll back. Budget for training or a support retainer before choosing self-hosting. |
| Organization already runs Element Server Suite or needs an air-gapped deployment | Element Server Suite (Pro or Sovereign edition) | Existing Element tooling and the Sovereign edition for air-gapped networks reduce the number of separate components. Confirm offline update and licensing steps with Element before committing. |
| Chat history must stay in-house with retention you control, and no per-seat cloud fees are wanted | Matrix with Synapse (AGPL) plus Element clients | Data stays on your servers, but AGPL obligations and any commercial Synapse Pro needs review by legal. Confirm which edition you need with Element. |
How Matrix federation compares with partner access in Skype for Business Server
Federation in Matrix means two homeservers exchange messages and room state directly, so a user on one organization's server can join a room hosted on another without holding a local account. Skype for Business Server handles external reach through its own federation and Edge configuration, but the details of how your estate does that are specific to your deployment, so confirm your existing federation settings, allowed domains and Edge publishing rules in your own environment before you map them to Matrix. Write down which partner domains are currently reachable, who approves them and how they are removed, because those answers define the Matrix configuration you need.
On the Synapse side, identity is fixed by the server_name setting, which determines how users and rooms are named, for example @user:example.com. Synapse federates on port 8448 by default. If you want identities such as @user:example.com served from a different host, delegation lets remote servers find the federation endpoint through well-known responses on port 443, so the public name can stay on your web infrastructure. Changing server_name after users exist is effectively a rebuild, so settle it before the first production account is created. The Synapse federation documentation sets out the delegation options in detail.
The federation_domain_whitelist setting restricts federation to the domains you list, and an empty list disables federation entirely. The Synapse documentation also recommends firewalling the federation listener so that only approved peers can reach it, which is a network control as well as an application one. Federation matters when partner organizations must reach your users in shared rooms without guest accounts, sharing identity and history across the boundary. If your partner access is limited to occasional meetings or to a small set of external users, you may not need open federation at all, and a whitelist with a short list of partner domains is the safer starting point.
Capabilities side by side: chat, presence, identity and conferencing
This table sets Skype for Business Server capabilities against a self-hosted Matrix homeserver with Element clients and Element Server Suite. Read each row as a question to confirm against your own Skype deployment, since features depend on how your estate was built. Gaps such as telephony and room systems are marked, and they usually need a separate product.
| Capability | Skype for Business Server | Matrix with Element (Synapse) |
|---|---|---|
| Chat and rooms | One-to-one IM, group chat and persistent chat rooms managed by the server | Rooms with direct messages, threads and persistent history on your Synapse homeserver; confirm retention and room policies you need |
| Presence and status | Availability states from calendar and client activity, shown across Skype clients | Presence is provided by the homeserver and clients; confirm how status appears to users and whether it meets your policy |
| Identity and sign-in | Active Directory accounts and Windows integrated sign-in | Single sign-on through OpenID Connect, SAML2 or CAS; confirm LDAP login for your identity setup before planning |
| Federation with partners | Federation with other Skype and Lync organizations, controlled by Edge servers | Federation over port 8448 or delegation on port 443; a domain allow list can restrict partners; confirm partner servers support Matrix |
| Voice and video | Audio, video and desktop sharing in meetings through Skype conferencing | Calls and group video through Element Call; confirm bandwidth and TURN planning for your sites |
| Telephony and room systems | Enterprise Voice and room systems integrate with Skype infrastructure | Gap: not provided by Synapse or Element Call; source PSTN gateways and room hardware separately and confirm integration |
| Scaling and database | Front end pools and SQL Server back end sized by user count and roles | Worker processes coordinated through Redis; PostgreSQL recommended for production, and version 14 or newer for Synapse 1.143.0 and later |
| Vendor editions and support | Subscription Edition with Standard, Enterprise and Plus CALs under Microsoft licensing | Element Server Suite Community (AGPL, includes Synapse and Element Call), Pro (Synapse Pro) and Sovereign for air-gapped sites; confirm support terms |
Where the data lives, who can see it and what compliance work follows
Moving from Skype for Business Server to a self-hosted Matrix homeserver changes who runs each control. The cards below set out, for each area, who owns the control on both sides and what your team should have ready before an assessment. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors decide conformance.
Data location and hosting model
Skype for Business Server runs on Windows and SQL Server servers that you install and operate in your own datacenter, with Microsoft supplying the software. A self-managed Synapse deployment runs on servers or cloud accounts you choose, and its PostgreSQL database holds message history, room state and media references. Confirm in writing where the homeserver, database, backups and any media store will sit, and whether any component reaches an external service during normal operation. Document each data flow before the first assessment interview.
Identity and access control
On Skype for Business Server, users authenticate against Active Directory and administrators manage access through Windows groups and Skype administration tools. With Synapse, the identity source becomes a configured provider: OpenID Connect, SAML2 or CAS. Your team owns the mapping of groups to rooms, admin roles and deactivation steps for leavers. Record who approves access, how quickly accounts are disabled, and which accounts hold homeserver admin rights, because those accounts can read and alter server configuration.
Retention and deletion
Skype for Business Server keeps persistent chat according to the retention policies configured on the server, and deletion depends on your database and archiving setup. Matrix history is replicated across every server in a room, so deleting a message on your server does not remove copies held by federated partners. Write a retention schedule that states how long chat, files and media are kept, which settings enforce it, and how a deletion request is carried out and verified. Ask your counsel which obligations apply to your jurisdiction.
Audit evidence and logging
Auditors ask for evidence that access was granted, changed and removed, and that administrative actions leave a record. Skype for Business Server writes its logs to Windows and server log locations that your team already collects. A Synapse deployment needs logs from the homeserver, reverse proxy and database forwarded to a store you control, with retention set to match your policy. Confirm which events are logged, where they are kept, who can alter them, and how a sample of administrative actions can be traced back to an approver.
Federation and external access
Federation is where data leaves your control on purpose, so it needs its own approval. Synapse federates on port 8448 by default, and its federation_domain_whitelist setting limits partners to named domains. An empty list disables federation entirely. Skype for Business Edge servers play a similar role, and retiring them needs a separate change record. Keep an approved partner list with domain names, the business reason for each, and firewall rules that match the configuration, since the Synapse documentation recommends firewalling the federation listener.
Backup, recovery and shared responsibility
On Skype for Business Server, backup of SQL databases, file shares and server configuration is usually handled by an established backup platform in your datacenter. A Synapse deployment needs the PostgreSQL database, media store and configuration files backed up together, and restores tested on a schedule. Synapse upgrade notes warn that rolling back can be difficult because of database schema changes, so take a database backup before each upgrade. Assign who runs restores, who signs off on recovery tests and where the results are filed.
Element Server Suite editions against Server/CAL licensing
The Community edition is the free, AGPL-licensed entry point. According to Element's pricing page, it includes Synapse, the Matrix homeserver, and Element Call for voice and video. Most teams evaluate this edition first. It carries no license fee for the software itself, but hosting, patching, backups and staff time remain your costs.
- Software: Synapse and Element Call are provided under the AGPL, with no license fee for the code itself.
- Operations: Your team installs, upgrades and monitors the stack, including PostgreSQL and any worker processes.
- Support: Ask whether any vendor support is included, and what it covers, before assuming you have it.
- AGPL duties: If you modify Synapse and let users interact with the modified version over a network, source disclosure duties can apply. Have counsel confirm your position.
Ask Element to confirm in writing which components are included in Community, whether Element Call is covered, and what support is excluded.
The Pro edition adds Synapse Pro, Element's commercial build of the homeserver. The published edition description names Synapse Pro as included but does not give a full feature comparison with Community. Treat Pro as a contract conversation, because the differences that matter to you, and the terms under which you may run them, need to be stated in writing.
- Synapse Pro: The commercial build of the homeserver, licensed separately from the AGPL code.
- Feature differences: Request a written, feature-by-feature comparison with Community, including any features that exist only in Pro.
- Support terms: Confirm response channels, severity handling, covered environments and who is entitled to open tickets.
- Upgrade path: Confirm how Synapse Pro releases track upstream Synapse and how upgrade notes and migration help are delivered.
Request the Pro order form and the feature comparison before you set them beside your current Skype for Business support arrangements.
The Sovereign edition targets air-gapped deployments, where servers have no route to the internet. For a Skype estate in a disconnected or classified network, this edition needs the most careful written review, because updates, license checks and support all have to work without outbound connections.
- Air-gapped delivery: Ask how software, container images and security updates reach the disconnected network, and through what transfer process.
- License validation: Confirm whether the license requires any online check, and how renewals and key changes are handled offline.
- Support model: Ask who responds, through which channel, and how support works when your network is isolated.
- Component scope: Confirm which parts of Element Server Suite are included in Sovereign, including Element Call and any clients.
- Documentation: Ask which release notes, configuration guidance and security documentation you receive to support your own assessment work.
Get these answers from Element in writing before you commit, because offline updates and license handling decide whether the deployment can be operated at all.
Skype for Business Server is licensed through server licenses plus client access licenses (CALs) for users or devices. Microsoft also sells Skype for Business Server as Subscription Edition, which changes how the server is licensed compared with a perpetual purchase. The exact SKUs, Software Assurance status and CAL tiers depend on your agreement, so treat the structure below as the starting point for a conversation with Microsoft or your licensing partner.
- Server licenses: Each server running a role needs a server license under the agreement you bought it through.
- CALs: Users or devices need client access licenses for the features they use. Standard, Enterprise and Plus tiers unlock different capabilities.
- Subscription Edition: Sold as a subscription, which changes how renewals and license counts are managed over time.
- Underlying licenses: Windows Server and SQL Server licensing sit beneath the server and must be counted separately.
- Lifecycle dates: Confirm support dates for your version directly with Microsoft.
Pull your current agreement, a server and CAL inventory, and a written renewal statement from Microsoft or your reseller, and confirm current terms before comparing them with Element.
Synapse is distributed under AGPL-3.0, and Element offers commercial licenses that provide an exception to AGPL obligations. Element announced that future Synapse contributions would be licensed under AGPLv3 instead of Apache 2.0, moved the repositories to the element-hq organization on GitHub, and requires contributors to sign a CLA. Read the license choice as a question about how you will modify, distribute and host the code.
- AGPL-3.0: Running a modified Synapse for users over a network can trigger source disclosure duties for that modified version.
- Commercial exception: Element sells AGPL exceptions for organizations whose use does not fit the copyleft terms.
- Future contributions: Code contributed after the change is under AGPLv3, so check the license of each version you deploy.
- Earlier releases: Older releases were under Apache 2.0, which matters if you are maintaining a long-lived fork.
- Dendrite: Element's other Matrix server implementation is also AGPL-3.0-or-later.
Have counsel review your modification and hosting plans, then request exception terms from Element in writing if the AGPL does not fit your use.
What drives cost and operating effort on each side
On the Skype for Business side, the licensing layer is only the first cost. Server licenses and the Standard, Enterprise and Plus CALs are the visible line items, and the current licensing terms should be confirmed with your Microsoft partner or licensing advisor because the product is now sold as Subscription Edition. Beneath them sit the Windows Server and SQL Server layers that the estate depends on, along with the hardware or virtual capacity for front end, back end, Edge and monitoring roles. The largest recurring item is often people: administrators who keep certificates, Edge publishing, dial-in and room systems working. Ask for the license and subscription terms in writing, and ask the quote to separate server, CAL, Windows, SQL and support costs so you can compare them line by line with the Matrix side.
On the Matrix side, the software cost depends on whether you buy Element Server Suite or run community Synapse. The Community edition is AGPL and free to use, while the Pro and Sovereign editions are subscriptions; the quote should state which edition, which support tier and whether Synapse Pro and Element Call are included. The recurring infrastructure is the Synapse processes, a PostgreSQL database (PostgreSQL 14 or newer for Synapse 1.143.0 and later), Redis for worker replication, a reverse proxy and load balancer, and the identity integration with your directory or SSO provider. Identity integration, database design and the federation and Element Call setup are mostly one-time work, while hosting and staff time recur. The recurring work that most affects operating effort is upgrades. Synapse publishes frequent releases, the latest on the GitHub releases page being v1.163.0, and each one may change the database schema. The upgrade notes warn that rolling back can be difficult for that reason, so every upgrade needs a tested database backup and a staging run first. Synapse also drops support for Python and PostgreSQL versions once they reach upstream end of life, which forces periodic platform upgrades that are separate from Synapse itself. Ask any implementation partner to price a named upgrade cadence, a staging environment and a rollback plan, and confirm in writing who owns each step.
How a move from Skype for Business Server to Matrix runs in phases
The sequence moves identity, federation policy and persistent chat onto a self-hosted homeserver first, then meetings, and keeps the old front end and Edge servers running until users have switched over.
Confirm the chat, presence and conferencing scope
Inventory which Skype for Business features are actually in use: one-to-one IM, persistent group chat, presence, federation with partner organizations, dial-in audio, and desktop sharing. The IT platform lead owns this list, with input from business unit owners who run persistent rooms. Done means every feature is marked as migrate, replace, or retire, and telephony and room systems are flagged for separate planning because Matrix does not replace them.
Choose the identity method for login
Decide between LDAP-backed login and single sign-on through OpenID Connect or SAML2, which Synapse supports through its oidc_providers and saml2_config settings. The identity or security architect owns this decision, working with whoever runs Active Directory today. Confirm which identity provider will sit upstream and how account disablement flows through, then record the choice in a design document before any server is built.
Design server_name and the federation policy
Set server_name, which fixes how user IDs such as @user:example.com and room identifiers are formed and is hard to change later. Decide whether delegation will serve IDs from another host on port 443, and whether federation runs on port 8448 or is restricted. Use federation_domain_whitelist to list partner domains, or set it empty to disable federation. The security lead owns the policy and firewall rules for the federation listener. Done means a signed-off naming scheme and an allowlist that partner organizations have agreed to.
Stand up the homeserver with PostgreSQL and Redis
Deploy Synapse in your own environment with PostgreSQL as the production database and Redis for replication if you plan to use workers. Confirm the PostgreSQL and Python versions against the current upgrade notes before installing, since newer Synapse releases drop older versions. The platform engineering team owns the build, backup and patch routine. Done means a test homeserver accepts logins, creates a room, and passes a restore test from backup.
Migrate persistent chat into rooms
Map each persistent Skype for Business chat or group conversation to a Matrix room with a named owner and membership. Export what history your compliance team requires, because Skype for Business message archives are not carried into Matrix automatically, and decide whether archival copies stay in a separate store. The records or compliance lead signs off on what must be kept. Done means each room in scope is created, its members are invited, and the retention record is approved.
Move meetings to Element Call or another service
Choose the meeting service that replaces Skype for Business audio, video and desktop sharing, such as Element Call or Jitsi, and confirm it meets your conferencing requirements. The collaboration lead owns this choice and the cutover date for meeting links. Pilot with a small user group and check that calendar invitations, external guest access and screen sharing work. Done means pilot users complete a full meeting without falling back to Skype for Business.
Run both systems in parallel
Keep Skype for Business and the Matrix homeserver running side by side while users move in waves. Communicate which channel is authoritative for each team, and monitor logins, federation traffic and support tickets. The service owner runs the schedule and the help desk owns user communication. Done means every wave has been moved, open issues are closed, and users confirm that rooms and contacts work as expected.
Retire front end and Edge servers last
Once no active users or federation partners depend on Skype for Business, decommission the Edge servers first, then the front end, back end and any remaining Skype for Business components. The infrastructure owner handles removal, and the security lead confirms that external access paths are closed and firewall rules are removed. Telephony and room systems should be retired only after their separate replacement plan is complete. Done means no traffic reaches the old servers and the decommission is recorded in the change log.
What buyers ask before choosing or hiring help
What does a Skype for Business to Matrix migration cost, and what drives the price?
The cost depends on the written scope, not on a list price. Software costs are different from services: Synapse and Dendrite are AGPL-3.0 and free to run, while Element Server Suite comes in a free Community edition and paid Pro and Sovereign editions, so confirm the edition you need before budgeting. Services cost what the team must do: identity integration, room and retention design, federation policy, client rollout, load testing and documentation. Recurring costs include hosting, patching, backups and staff time. Ask any provider for a quote that separates one-time work from recurring support, lists each deliverable, and names the systems in scope, including Edge, telephony and room systems.
How long does moving from Skype for Business Server to Matrix take?
The timeline is set by the number of integrations, the depth of identity work and how long both systems must run side by side. Migrating users is usually the smaller task. Longer items include LDAP or SSO login, deciding which persistent chat rooms become Matrix rooms, testing federation with partner organizations, choosing and load testing Element Call or Jitsi, and retiring front end and Edge servers in order. Ask for a phased plan with dated milestones and exit criteria for each phase, agreed in writing before work starts.
What does our internal team need to provide for the project?
Your team needs to supply decisions and access. Expect to provide: directory administrators for LDAP or SSO configuration, owners of the Skype federation list and partner contacts, a Linux and database operations owner, network and DNS staff for server_name, delegation and firewall rules, and a business owner who signs off on retention and room structure. Also name a security approver for certificates and key handling. Ask the provider to list these roles in the scope so that gaps appear before the schedule is set.
Can our own engineers run this migration without outside help?
Yes, a capable team can deploy Synapse, PostgreSQL, Redis and clients without a partner, provided it has Linux, database, identity and network skills and time to test. The risks are in the edges: federation, identity mapping, meeting media and upgrade paths. Synapse upgrade notes warn that rolling back can be difficult because of database schema changes, so a tested upgrade procedure matters. A hybrid model is common: your staff own operations while a partner handles design, hardening and knowledge transfer. Decide which parts you will staff before you compare quotes.
Can Matrix replace Skype for Business federation with partner organizations?
Matrix can federate between homeservers, but it does not reproduce Skype federation one for one. Synapse federates on port 8448 by default, and delegation lets user IDs such as @user:example.com be served from another host on port 443. Your partners must also run compatible Matrix servers, and they must agree on identity, room policy and retention. Synapse's federation_domain_whitelist can limit federation to listed domains, and the documentation recommends also firewalling the federation listener. Confirm with each partner which servers they run before you promise cross-organization chat.
Is Element Server Suite required, or can we run community Synapse?
Element Server Suite is not required. Synapse is AGPL-3.0 and can be run from the open-source distribution, so you can start without a license purchase. Element Server Suite adds a packaged Community edition with Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. Element relicensed Synapse from Apache 2.0 to AGPLv3 with commercial licenses available, so review how the AGPL applies to your use and whether you need a commercial exception. Ask legal and your provider to confirm this in writing.
How are updates handled after go-live?
Updates are a recurring operations task. Synapse publishes releases on GitHub, and its upgrade notes describe schema changes and dropped support for Python and PostgreSQL versions when upstream support ends. For example, Synapse 1.143.0 and later require PostgreSQL 14 or newer. Plan a staging environment, take database backups before each change, and read the upgrade notes for every release you skip. Retainers for upgrades, patching and monitoring are available from DeployOpen, and the scope should state the response expectations in writing.
What changes for air-gapped networks?
Air-gapped networks need an offline plan for software, updates and licensing. Container images, packages and Synapse releases must be transferred through an approved process, and you must maintain your own backup and patch cadence. Element Server Suite offers a Sovereign edition for air-gapped deployments, which is worth comparing against a community install. Meeting media, identity and certificates also need internal sources. Ask for a written list of artifacts, transfer steps and the owner for each update, and confirm with the vendor what its air-gapped edition includes.
How DeployOpen helps evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Skype for Business Server to a Matrix homeserver with Element clients, we start with the written scope that decides which chat, federation and meeting features you actually need.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map Skype for Business presence, persistent chat, federation and Edge traffic to Matrix rooms, federation settings and Element Call.
- The scope lists which login path applies, such as LDAP or SSO, and which Synapse database and Redis components you will run.
- A quote follows from the written scope, so ask for the scope document before comparing any proposal.
How we build
- We install Synapse on PostgreSQL in your cloud account, data center or air-gapped network, following the upgrade notes for your chosen version.
- We configure server_name, delegation, the federation listener and federation_domain_whitelist so only partner domains can connect.
- We integrate identity through oidc_providers, saml2_config or CAS, and test sign-in against your directory before any user is onboarded.
- We run security testing on the deployment and document the configuration, including firewall rules for the federation port.
How we hand over
- You receive documentation covering architecture, configuration keys, backup procedures and the upgrade path for each component.
- We run a cutover rehearsal with your administrators and record the steps for retiring front end and Edge servers in order.
- Handover includes runbooks for user onboarding, room administration and federation partner requests, so your team can operate the platform.
- Compliance readiness material documents the controls you configured, while independent auditors and certification bodies issue any formal assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Synapse version upgrades, which the upgrade notes say can be hard to roll back because of schema changes.
- Support can extend to Element Server Suite edition selection and the licensing terms for your deployment, confirmed with Element.
- We can repeat security testing after each upgrade, so changes to federation and identity settings are checked before release.
