Skype for Business end of support: why on-premises still has options
If your Skype for Business Server 2015 or 2019 estate still runs on premises after October 2025 and policy or regulation rules out cloud, two realistic paths remain: Microsoft's Subscription Edition or a self-hosted open-source stack. Teams in Microsoft 365 is excluded by the constraint, so this page does not treat it as an option. The open-source building blocks are Mattermost for persistent chat and channels, Matrix with Element for federation with partner organizations, and Jitsi for meetings and video. None of them is a one-to-one replacement, because telephony, room systems, Edge-based federation and presence behave differently or need separate components. Confirm each gap against your own feature inventory before you commit to a direction.
Start by listing what your estate actually uses: instant messaging, persistent group chat, scheduled meetings, PSTN dial-in, federation through Edge servers, and Active Directory sign-in. Each item maps to a different component, so the choice is rarely all or nothing. Mattermost Team Edition is free and self-hosted for teams under 250 users that do not need single sign-on, while SSO and AD/LDAP sync start with the paid Professional plan, according to the Mattermost editions documentation. A Matrix homeserver such as Synapse requires PostgreSQL 14 or newer for current releases, and Jitsi needs a valid domain certificate for audio and video to work. Check these prerequisites against your server and identity standards early.
Cost follows the components. Subscription Edition costs recur through licensing and the Windows and SQL Server infrastructure underneath it, and the licensing terms should be confirmed directly with Microsoft or your reseller. Open-source stacks shift cost toward one-time implementation, ongoing operations, patching, backup, and staff or partner time. Ask any implementation partner for a quote built from a written scope that names the platforms, integrations, user counts, high availability requirements and the support period. Compare the options on the same scope, and confirm whether your chosen edition or license tier includes the features your inventory depends on.
What an on-premises Skype for Business replacement must keep in-house
Once a team rules out cloud, the replacement has to meet the same constraints the old server did. The four requirements below cover where content lives, which directory signs users in, who controls partner connections and how the platform is updated without internet access.
Chat and meeting content
Messages, files, meeting media and recordings must be stored on servers the organization operates. Ask each candidate where message history, attachments and call recordings are written, and whether any component sends telemetry or content to a vendor-hosted service. Confirm the answer for every component, including search indexes, push notification gateways and any optional AI features. Mattermost, Synapse and Jitsi each keep their core data in local services you deploy, but each still needs its own review.
Identity from Active Directory
Users should keep signing in with their existing directory accounts, and leavers should lose access when their directory account is disabled. Check which directory integration each platform needs: Mattermost ties AD/LDAP sync and SSO to its paid tiers, while Synapse supports OpenID Connect, SAML2 and CAS. Plan how groups, guest accounts and service accounts will map to rooms, channels and conference roles before cutover.
Partner federation under your control
Skype for Business let the organization decide which outside domains could reach its users. The replacement needs the same control, with an explicit allow list and no open federation by default. For Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and the documentation recommends firewalling the federation listener as well. Document which partners are listed and who approves changes.
Updates and licenses without cloud access
Air-gapped and restricted networks cannot pull packages or license checks from the internet, so every update path must be planned in advance. Ask vendors how signed packages, container images and license keys are delivered offline, and who approves each transfer. Mattermost lists air-gapped deployment only in Enterprise Advanced, and Element offers a Sovereign edition for air-gapped use, so confirm the exact terms for your network.
Certificates and network ports
Clients on the corporate network must trust the certificates the replacement presents, and firewalls must allow the ports each service needs. Jitsi requires HTTPS with a proper domain certificate for working audio and video, and self-signed certificates cause problems, especially on mobile clients. Build an internal certificate authority or a certificate process before pilot users are onboarded, and list every inbound and outbound port in the change record.
Where Microsoft's two paths meet the on-premises constraint
Subscription Edition is the only Microsoft path that keeps the servers in your own datacenter, but it is still a Microsoft product under Microsoft licensing. The servers, the Front End and Edge roles, and the database stay on your hardware, so your data and call records remain under your control. What does not change is the vendor relationship: you buy subscriptions, you accept Microsoft's terms, and you depend on Microsoft's support lifecycle. Before you budget for it, confirm the licensing terms, the support end dates for the release you would deploy, and the hardware and operating system requirements directly with Microsoft and your reseller. Ask in writing whether any Teams-related features you rely on depend on cloud services.
Teams in Microsoft 365 is cloud-hosted, so Microsoft runs the service, the data center and the patching. That removes the on-premises constraint entirely, which is why it is the path most of Microsoft's own guidance points toward. Licensing has also moved. Microsoft introduced Microsoft 365 and Office 365 suites without Teams outside the EEA and Switzerland, plus a standalone Teams offering, effective April 1, 2024, and suites that include Teams are no longer sold to new subscribers worldwide. Confirm which SKUs your reseller can still sell in your country before you assume any suite option is available.
Whichever Microsoft path you consider, check the history question early. If you need to keep old Skype for Business conversations or meeting artifacts, identify where they live and whether they can be exported. Microsoft Teams Export APIs in Microsoft Graph cover Teams content, but they require admin-approved application permissions and an active Teams license on each exported user, so a Teams-based option does not automatically solve archive access. Document which records you must retain and who will own the export work, because that effort is separate from the licensing decision.
Which self-hosted Skype for Business alternative fits each requirement
This table compares Mattermost, Matrix with Element Server Suite and Synapse, Rocket.Chat and Jitsi Meet on data residency, identity, federation, licensing and trade-offs. Read each row against your own requirements, and treat the paid-tier gates as the first items to confirm in a quote.
| Requirement | Mattermost | Matrix with Element and Synapse | Rocket.Chat and Jitsi Meet |
|---|---|---|---|
| Data stays on-premises | Self-hosted single Linux binary on PostgreSQL; files need shared storage such as S3-compatible or NAS for high availability | Synapse self-hosted on PostgreSQL; Element Server Suite Sovereign supports air-gapped deployment | Rocket.Chat self-managed with on-premises and air-gapped options on paid plans; Jitsi Meet runs in your own servers |
| Identity options | SSO (SAML, OIDC, OAuth) and AD/LDAP sync from the Professional plan; Team Edition is for teams under 250 users without SSO | OpenID Connect, SAML2 and CAS through Synapse configuration; LDAP and SSO setup should be confirmed for your directory | Jitsi offers internal XMPP accounts, JWT tokens, LDAP and Matrix verification; Rocket.Chat identity features should be confirmed per edition |
| Federation model | No federation between separate servers; a single organization deployment | Federates with other Matrix servers on port 8448 by default; an empty federation_domain_whitelist disables it | Rocket.Chat federation is not a core use case here; Jitsi meetings are not federated |
| Licensing | Compiled binaries MIT; source for custom builds AGPL v3.0 or commercial license; admin tools Apache 2.0 | Synapse and Dendrite AGPL-3.0 with commercial licenses from Element; Element Server Suite Community, Pro and Sovereign editions | Rocket.Chat code outside ee directories is MIT; ee directories use the enterprise license; Jitsi Meet is Apache 2.0 |
| High availability | Clustering with redundant application, database and load balancer tiers only on Enterprise and above | Scaling through Synapse worker processes with Redis; design and support tier should be confirmed | Jitsi videobridges scale horizontally by adding more; Rocket.Chat HA depends on edition |
| Voice and video | Channels for chat; meetings and calls need a separate service such as Jitsi Meet | Element Call included in Community edition for voice and video | Jitsi Meet covers conferencing; confirm telephony and room system parity before relying on it |
| Main trade-off | Clean Slack-style import path; paid tiers needed for enterprise identity and HA | Strongest federation and encryption model, but more components to operate and upgrade carefully | Broad feature set; enterprise-licensed directories and a separate conferencing stack add review work |
How identity and meetings move off Skype for Business
Identity is the first decision in any move off Skype for Business, because it determines who can sign in and how user accounts stay in step with Active Directory. Mattermost gives you SAML, OIDC or OAuth single sign-on and AD/LDAP user sync only from the Professional plan, so a free Team Edition deployment will not offer either. Synapse, the Matrix homeserver, supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, which lets you point login at the directory you already run. Confirm which identity provider your estate uses, then check whether that provider can issue the protocol your chosen platform expects before you commit to a plan.
Jitsi takes a different route. Its Docker setup, configured through the .env file, can authenticate against internal XMPP accounts, JWT tokens, LDAP, Matrix user verification or a hybrid Matrix and JWT mode. The Jitsi handbook marks the older secure domain method, which uses username and password room creation, as deprecated for new installations and recommends JWT token authentication with a separate anonymous domain for guests. Jitsi also needs HTTPS with a certificate for a proper domain name, because audio and video depend on it, and self-signed certificates cause failures, especially on mobile clients. Plan the DNS name and certificate lifecycle before anything else in the meeting build.
SIP dial-in is a separate concern. Jitsi's Docker deployment runs the jigasi container as the SIP gateway, which is how callers reach a meeting from a phone line. Telephony trunks, dial plans, emergency calling and room systems were often tied to Skype for Business Enterprise Voice and Survivable Branch Appliances, so they rarely move with the chat and meeting workload. Ask your telephony team to inventory those dependencies early and treat them as their own project.
How to deploy the chosen stack under the constraint
This sequence takes a team still running Skype for Business Server 2015 or 2019 from a confirmed constraint to a retired on-premises estate. Each step closes with a check you can verify before the next one starts. The result is a chat server, a Jitsi meeting service and a pilot group working alongside the old system.
Confirm the constraint and license path
Document which workloads must stay on premises, which directory holds user accounts, and which path you chose: Mattermost Team Edition, a paid Mattermost plan, or Element Server Suite. Team Edition is aimed at teams under 250 users that do not need single sign-on, so SSO and AD/LDAP sync point to a paid plan. Ask Mattermost or Element for written terms that match your user count and deployment model. Done when a signed decision record names the edition, the directory and an owner for each service.
Integrate sign-in with the existing directory
Connect the platform to the directory your users already sign in with. In Mattermost, configure SAML, OIDC or AD/LDAP sync in the admin console on a plan that includes them. In Synapse, set oidc_providers, saml2_config or the CAS settings in homeserver.yaml. Test one account from each user group. Done when a test user signs in with the expected name and team membership, and a disabled account can no longer sign in.
Deploy PostgreSQL and shared file storage
Provision PostgreSQL for the chat server. Synapse recommends PostgreSQL for production, and version 1.143.0 and later require PostgreSQL 14 or newer. For a Mattermost high availability cluster, mount shared storage on every node, using Amazon S3, an S3-compatible store or NAS, because local file storage will not work correctly across nodes and risks corrupting files. Done when a file uploaded through one node opens from another node.
Install the chat server and pin its version
Install the server on a supported Linux host and pin the version you tested. Mattermost ships as a single binary, and it releases server builds on the 16th of each month. Set server_name in homeserver.yaml before any Matrix user exists, because it fixes how user and room identifiers are written. Record a rollback plan first, since the Synapse upgrade notes warn that rolling back can be difficult after schema changes. Done when the admin console or Synapse admin API reports the tested version.
Deploy Jitsi with HTTPS and open ports
On Debian 12 or newer, or Ubuntu 24.04 or newer, install OpenJDK 17 and Jitsi Meet from the quick start, or use the Docker setup. Open 80/TCP and 443/TCP for the web app and certificate issuance, and 10000/UDP for media. Open 5349/TCP for TCP fallback and 3478/UDP for STUN if your network needs them. Use a certificate from a trusted authority for your domain, because self-signed certificates cause problems, especially on mobile clients. Done when a two-person test call carries audio and video in a browser and on a mobile device.
Restrict federation to approved domains
This step applies to Matrix only. Set federation_domain_whitelist in homeserver.yaml to the partner domains you approve, because an empty list disables federation. Firewall the federation listener on 8448 so only those partners can reach it, and confirm delegation if your user IDs are served on port 443. Done when a test account on a domain outside the list cannot join or see a room on your server.
Run a pilot group alongside Skype
Choose a pilot group from one department and keep Skype for Business running for everyone else. Re-create the persistent chat rooms as channels or Matrix rooms, and move the pilot group's meetings to Jitsi. Track missed messages, sign-in failures and call quality against the criteria agreed in step one. Done when the pilot owner signs off in writing and the open defect list is empty or formally accepted.
Cut over and retire Skype servers
Move the remaining users in waves, then disable Skype for Business sign-in. Retire the front end servers first and the Edge servers last, once external access is no longer needed. Keep a restorable backup of the old database until your records retention period ends, as set by your compliance lead. Have your auditors confirm the retirement, since they issue any attestation. Done when the servers are powered off, a restore test succeeds and the decommission record is filed.
Choosing a release track you can keep running
Once the stack is self-hosted in an offline or restricted network, you own every patch, and the release track you pick now sets that workload for years. Mattermost publishes server binaries on the 16th of each month, and the Mattermost server releases page shows v12.0 supported until 2027-01-15 and v11.11 until 2026-12-15. For a team that cannot upgrade every month, v11.7 is the Extended Support Release, released on 2026-05-15 with support ending 2027-05-15. The previous ESR, v10.11, has already reached end of life on 2026-08-15, so any cutover plan built on it would start with an unsupported server. Confirm the current support dates on the releases page before you fix a target version.
Synapse needs a different kind of planning. Its upgrade notes warn that rolling back can be difficult because schema changes ship between releases, so treat each upgrade as a one-way step and take a full PostgreSQL backup and a configuration copy before every move. Synapse also drops support for Python and PostgreSQL versions once they reach upstream end of life, and from 1.143.0 it requires PostgreSQL 14 or newer. Ask your team to map the database and Python versions of the host operating system against those minimums, because an OS image that is current in your mirror may still be too old for the next Synapse release.
Whoever runs the platform also owns the staging, testing and approval of every update, including the air-gapped transfer of packages and container images. Write that workload into the cutover plan as a recurring task with named owners, a test environment that mirrors production, and a window for rollback. Your DeployOpen scope should state which of these tasks sit with your staff and which sit with the implementation partner, so the first major upgrade does not arrive unplanned.
Evidence the on-premises constraint will ask for
Once a team keeps chat, presence and meetings inside its own datacenter, the evidence trail becomes the main deliverable. The cards below list the records a CISO, auditor or regulator is most likely to ask for, and each one should be produced before cutover rather than reconstructed afterward. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any assessment outcome.
Architecture and data flow diagrams
Show where chat content, presence data, user identities, uploaded files and media travel, and which hosts hold each. For a Mattermost or Synapse path, include the PostgreSQL database, the file store and any Redis or load balancer tier. For Jitsi, show the web server, Prosody, Jicofo and videobridges. Reviewers will check whether any component sends data to a host outside the network, so label every external dependency, including mail relays and push services, and confirm each one with the vendor or your own environment.
Federation configuration and firewall rules
If the chosen stack federates, the record must state which domains are allowed and how the federation listener is reached. In Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and an empty list disables it. Document the port in use, the delegation records and the firewall rules that limit that port, and keep the change history. Reviewers will compare these rules against the segmentation described in the architecture diagrams, so the two documents must match.
Identity integration records
Auditors will ask how each account is created, how it is authenticated and how it is removed. Keep the directory sync or SSO configuration for each platform, the mapping of groups to roles, and the test results for a leaver scenario. Mattermost SSO and AD/LDAP sync sit in paid plans, and Synapse supports OpenID Connect, SAML2 and CAS, so the record should name the exact method and the identity provider. Confirm the supported options against the current documentation for the version you deploy.
Backup and restore test results
A backup policy is only evidence once a restore has been performed and recorded. Capture the scope of each backup, including the database, uploaded files and configuration, along with the restore time observed in a test and the person who signed off. For Mattermost high availability, file storage must be shared on S3, an S3-compatible service or NAS, so verify that the file backup covers that store. Keep dated restore logs for each platform in scope.
Release and patch record
Reviewers want to see which versions run in production, when they were applied and who approved them. Track the server version, client version and database engine version for each component. Mattermost publishes server releases monthly and marks some as Extended Support Releases, and Synapse drops support for older PostgreSQL and Python versions once upstream support ends. A dated register that links each version to its support end date shows the team is not running unsupported software.
Decision record for the chosen path
Record why the team picked Mattermost, Matrix with Element, Jitsi or a combination, and why the cloud options were ruled out. Include the requirements that drove the choice, such as data residency, air-gap rules or licensing cost, the alternatives considered, the owner of the decision and the date it was approved. Note the open items the decision accepts, such as features the chosen stack does not cover, so reviewers can see the trade-off was made deliberately and not by default.
How much does a Skype for Business replacement cost to run?
What are the main cost components of a self-hosted Skype for Business replacement?
The cost splits into four components: the software licence or support subscription, the infrastructure the platform runs on, the people who build and run it, and the video and telephony pieces that Skype for Business used to bundle. Open-source cores such as Mattermost Team Edition, community Synapse and Jitsi Meet carry no licence fee, so the larger lines are usually servers, storage, database administration and staff time. If you choose a commercial edition, the plan fee becomes a fourth line. Mattermost sells Professional, Enterprise and Enterprise Advanced as prepaid annual subscriptions priced by seat licence, and its pricing page lists no public prices, so ask sales for a written quote. Ask every vendor to itemize licences, support and any add-on features separately.
Which costs are one-time and which recur every year?
One-time costs include discovery, design, migration of users, channels and history, integration with directory and single sign-on, testing and the cutover itself. Recurring costs include hosting, storage, backups, database and operating system maintenance, monitoring, staff time for upgrades, and any commercial subscription. Mattermost releases a new server version each month and publishes support windows per version, so budget for regular upgrade work rather than a single project. Synapse also advises that rolling back can be difficult because of schema changes between releases, which makes testing upgrades in a staging environment a recurring cost worth planning for.
Can our internal team run a replacement without outside help?
Some teams can, especially if they already operate Linux, PostgreSQL, reverse proxies and identity systems. The honest test is whether you have people who can own the platform after go-live: patching, backups, certificate renewal, scaling and incident response. Mattermost high availability requires redundant application servers, database servers and load balancers, plus shared file storage such as S3, an S3-compatible service or NAS, and it is available only on Enterprise and Enterprise Advanced. Jitsi needs a web server, Prosody, Jicofo and videobridges, with ports 80/TCP, 443/TCP and 10000/UDP open. Many organizations use an implementation partner for the build and then keep operations in house. DeployOpen works on this basis, under a written scope.
How long does a cutover from Skype for Business take?
Duration depends on scope, which covers the number of users, the number of persistent chat rooms, how many federated partners you have, the voice and meeting features in use, and how many Edge and front end servers you retire. No single figure applies across estates, so ask for a timeline in the written plan and check that it includes a parallel-running period. Migration of chat history is a separate workstream, and the Slack migration tooling for Mattermost, for example, does not move integrations or user groups, so budget time to rebuild those by hand.
What does the work need from our side before it starts?
The client typically provides the target infrastructure, access to Active Directory or the identity provider, DNS and certificate authority access, firewall change approvals, a named business owner for each chat and meeting use case, and staff who can test real workflows. For Synapse production use, plan for PostgreSQL 14 or newer, since Synapse 1.143.0 and later require it, and Python 3.10 or newer for version 1.142.0 and later. For Jitsi, a proper domain certificate is needed because the handbook says self-signed certificates cause problems, especially on mobile clients. Confirm each requirement against the release you actually plan to deploy.
What should we ask for in a quote for this work?
Ask for a written scope listing the platforms, editions and versions in use, the number of users and rooms in scope, and the integrations included. Require separate line items for software subscriptions, implementation, migration, testing, documentation, training and any post-launch support or upgrade retainer, since ongoing support and upgrades are sold as retainers. Ask what is excluded, such as telephony, room systems or Slack Connect equivalents, who owns the infrastructure accounts, what acceptance criteria apply, and how change requests are priced. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes an on-premises chat and meeting replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the replacement for Skype for Business Server 2015 and 2019 runs in your data center or cloud accounts. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Skype for Business features your users rely on, such as persistent chat rooms, presence, federation and meetings.
- Confirm identity sources, Active Directory integration and whether single sign-on is required before choosing a chat platform.
- Record in writing which telephony, room systems and Edge functions are in or out of scope, with the fixed deliverables and timeline.
How we build
- Install and configure the chosen chat server and video service on hardware or virtual machines you provide, following vendor deployment guidance.
- Set up HTTPS certificates, firewall rules and network paths for meetings, since working audio and video depends on them.
- Test login, presence, group chat, meetings and failover in a staging environment before any user is moved.
How we hand over
- Document architecture, configuration, access roles, backup procedures and the upgrade path for each component.
- Run a cutover plan with a parallel-running period, user communication and a tested rollback procedure agreed with your team.
- Provide evidence and control documentation to support your own compliance assessment, noting that independent auditors issue any audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Confirm with the vendor and your own environment which release train, support window and database versions apply before scheduling upgrades.
- Schedule periodic security testing of the chat and meeting services as part of the retainer, with findings tracked to closure.
