Open-source alternative to Webex Messaging: the short answer
If a Webex renewal, a licensing change or a data residency requirement is pushing your messaging off the Webex suite, the realistic self-hosted replacements for Webex spaces are Mattermost and Matrix with Element. Mattermost is the closer fit for a conventional team chat model with channels, direct messages and a single server you run, while Matrix with Element suits organizations that want open federation or a protocol that other clients and bridges can use. Neither is a drop-in copy of Webex spaces, so plan the migration around how your teams actually use them.
The right choice depends on whether meetings move too. If you keep Webex Meetings or move calls to a separate tool, Mattermost can host its own calls for short sessions, but its free Mattermost Entry tier limits calls to 40 minutes, so confirm what your edition includes. Element Call, which is part of the Matrix stack, covers voice and video inside the same platform as the messages. Webex's messaging data cannot be moved wholesale into either system, so expect to export what Webex allows, archive the rest, and decide which history you actually need to carry over.
Licensing differs in ways that matter for procurement. Mattermost is open core: its compiled binaries are MIT licensed, its custom build source falls under AGPL v3.0, and paid Professional, Enterprise and Enterprise Advanced plans are sold by seat count. Synapse, the most common Matrix homeserver, is AGPL-3.0 licensed and developed by Element, which also sells commercial licenses and the Element Server Suite. Ask each vendor to confirm in writing which features sit in which tier, especially single sign-on, high availability and air-gapped operation.
Which Webex messaging capabilities map to Mattermost and Matrix
This table maps the Webex messaging capabilities most teams rely on to Mattermost and Matrix with Element, and flags where each option needs a paid tier or an extra component. Read each row as a question to answer in your own pilot, since plan limits and integrations change between releases. The main takeaway is that Mattermost covers most team chat needs on a single server, while Matrix covers federation and cross-organization chat but needs more components to match Webex's admin and meeting features.
| Webex capability | Mattermost | Matrix with Element |
|---|---|---|
| Spaces and team chat | Teams, channels and private channels map closely to Webex spaces; one server hosts all teams | Rooms and spaces map to Webex spaces; large rooms need more server capacity planning |
| Direct messages and group messages | Built in, including group messages between users on the same server | Built in, with end-to-end encryption available per room; confirm encryption defaults for your rooms |
| File sharing | Files stored on local disk or shared storage; high availability needs S3-compatible storage or NAS on every node | Files stored by the homeserver's media store; plan storage growth and retention for media |
| Search and retention | Message search is built in; retention policies are an admin setting to confirm on your plan | Search depends on the homeserver setup; confirm message search and retention options for your server version |
| Guest access | Guest accounts are available; confirm the guest role and channel limits for your plan | Guests join through federation or invitations; federation can be restricted to listed domains |
| SSO and directory sync | SSO (SAML, OIDC, OAuth) and AD/LDAP sync start at the Professional plan | Synapse supports OpenID Connect, SAML2 and CAS; directory sync needs a separate tool or a custom process |
| Meeting join links and calls | Calls are limited to 40 minutes on Mattermost Entry; longer calls need a paid plan or a self-hosted Jitsi link | Voice and video use Element Call with a LiveKit SFU, which adds components to operate |
| High availability | Clustering is available only on Enterprise and Enterprise Advanced plans | Requires a worker-based design with Redis and PostgreSQL planning; no single plan switch |
| Webex Assistant, whiteboard and third-party apps | Confirm integrations for each Webex-specific feature against current vendor documentation; expect replacements rather than direct equivalents | Confirm bridges and bots for each Webex-specific feature against the Matrix bridges list before cutover |
Mattermost or Matrix with Element: when each fits
Mattermost and Matrix with Element both replace Webex spaces, but they fit different organizations. The cards below cover the architecture, licensing and operating costs that should drive the choice, along with the enterprise features and federation controls to confirm before a cutover.
Mattermost as a single binary
Mattermost runs as a single Linux binary backed by PostgreSQL, with a team-oriented model of channels, teams and integrations that suits organizations moving from Webex spaces. The small footprint is the main draw, since one server process and one database cover most departments. Check which features your team needs before choosing a tier, because high availability and air-gapped deployment are gated behind enterprise plans.
Matrix with Synapse and Element
Matrix with Synapse and Element fits organizations that need federation with other organizations or end-to-end encryption across many external partners. Synapse is the most widely documented Matrix homeserver and is developed by Element. Plan for a more involved setup than a single binary, and confirm that your encryption and key-recovery requirements are met by the Element clients you deploy.
AGPL and commercial licensing
Mattermost binaries are MIT licensed, while custom builds from source fall under AGPL v3.0 with a commercial alternative from Mattermost, Inc. Synapse is AGPL-3.0 with commercial exceptions from Element, and Element stated in December 2023 that future Synapse contributions would be AGPLv3. Ask legal counsel whether modifying either server and offering it to users triggers source disclosure, and whether a commercial exception is needed.
Synapse PostgreSQL and Redis footprint
A production Synapse deployment needs PostgreSQL, and scaling with workers adds Redis to relay replication between processes. This is the largest operational difference from Mattermost. Budget for backups, database upgrades and monitoring of both services. Synapse upgrade notes warn that rolling back can be difficult because of schema changes, so test each release in staging before production.
Mattermost high availability and air-gap tiers
Mattermost high availability needs redundant application servers, database servers and load balancers, and it is available only on Enterprise and Enterprise Advanced. Its cluster also needs shared file storage such as S3, an S3-compatible service or NAS, since local file storage risks corrupting files. Air-gapped deployment sits in Enterprise Advanced. Ask Mattermost for written confirmation of which tier covers your exact requirements.
Synapse federation controls
Synapse federates on port 8448 by default, and its federation_domain_whitelist setting restricts federation to listed domains, while an empty list disables it entirely. Set server_name before first start because it fixes how users and rooms are identified. Firewall the federation listener as well, since the docs recommend it. Decide the allowed domain list with your security team before go-live.
Keeping chat and video together after leaving Webex
Mattermost handles spaces, channels and direct messages, but it does not run video itself in the way Webex does. The usual pattern is to keep Mattermost as the chat home and connect it to a self-hosted Jitsi Meet or BigBlueButton room through meeting links posted in channels or generated by a plugin. Call behavior depends on the plugin and edition you choose, so confirm that before promising users a single button in the chat client.
- Meeting links: Users paste or generate a Jitsi Meet or BigBlueButton room URL in a channel, which keeps the video server independent of the chat server.
- Entry tier limit: Mattermost Entry, the free commercial tier, limits calls to 40 minutes, so longer calls need a paid plan or an external room.
- Plan-gated features: SSO and AD/LDAP sync start at the Professional plan, and high availability is limited to Enterprise and Enterprise Advanced, so budget for the tier you need before rollout.
- Two audit trails: Chat history stays in PostgreSQL on Mattermost, while meeting recordings sit on the video server, so retention rules must cover both.
- Single-node versus cluster: A high availability cluster needs shared file storage on S3, an S3-compatible service or NAS mounted on every node.
Before you commit, confirm the call plugin, tier and retention settings in writing, and test a full meeting from a channel link on each client type your staff use.
Matrix combines chat and voice or video in one protocol. Element Call provides video inside Element clients, and Element Server Suite Community bundles Element Call with Synapse under AGPL. Element Call uses its own media path, a LiveKit SFU, rather than the Jitsi Videobridge or BigBlueButton servers, so a Matrix deployment is a separate video stack to operate, not an extension of the Jitsi setup.
- Bundled stack: Element Server Suite Community includes Element Call alongside Synapse, which lets one vendor package cover chat and calls.
- Separate media path: Calls traverse the Element Call infrastructure, so firewall rules, TURN and bandwidth planning must cover it in addition to the Synapse server.
- Edition gap: Confirm which Element Call features and support terms belong to the Community bundle versus the paid Pro edition.
- Federation controls: Synapse federation can be restricted with federation_domain_whitelist, and an empty list disables it, which matters when you connect to outside organizations.
- Room migration: Webex spaces map to Matrix rooms, but history, membership and bots do not move automatically.
Ask the vendor for the current component list and LiveKit operating requirements before sizing, and verify that Element Call meets your call size and client platform needs.
During a migration, users often need one sign-in for chat and video while Webex is still in use. Both platforms can take identities from an existing identity provider, so the chat and meeting services can share a directory and avoid a second password store. Plan the identity side before cutover, because account mismatches are a common source of lost history and duplicate users.
- Mattermost SSO: SAML, OIDC and OAuth are available from the Professional plan, with AD/LDAP user sync, so group membership can follow the directory.
- Synapse SSO: Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, so a corporate IdP can sign users into Matrix.
- Jitsi authentication: Jitsi can use JWT tokens, LDAP or Matrix user verification, which lets a meeting link reuse the same identity source.
- Account naming: Agree on the username format before rollout, because Matrix user IDs and Mattermost usernames are built from different fields.
- Sign-in fallback: Keep a break-glass local admin account and test SSO failure paths before removing Webex.
Confirm with your identity team which SAML or OIDC attributes map to groups and roles, and test a full sign-in on each client before you disable the old service.
The most common failure after a chat and video move is not a broken call but lost context. Chat history, meeting recordings, transcripts and captions end up in different stores, and users look in the wrong place. Webex exports, Zoom and Teams export formats differ, so no single export covers everything, and the self-hosted platforms add their own storage paths to manage.
- Chat history: Mattermost keeps messages in PostgreSQL and Matrix keeps room history in Synapse, so export and retention need separate runbooks.
- Recording locations: Jitsi recordings from Jibri and BigBlueButton recordings sit on the video host, which needs storage sized for them. BigBlueButton 4.0 documentation lists 500 GB of disk for recordings as a starting requirement.
- Transcripts and captions: Confirm whether your video platform produces transcripts and where they are stored, since the chat platform will not hold them.
- Cross-links: Meeting links posted in chat become dead when recordings are purged, so set retention on both sides together.
- Archive plan: Decide what leaves Webex, in what format, and where it will be searched after the contract ends.
Before cutover, write a map showing where each artifact lives and who owns retention for it, and test a search that finds a message, a recording and a transcript for the same meeting.
How Mattermost or Synapse connects to identity and meetings
The sign-in path is the first thing to design. Users authenticate through an identity provider that speaks SAML, OIDC or LDAP, and the messaging server trusts that assertion rather than holding its own passwords. For Mattermost, SSO over SAML, OIDC or OAuth and AD/LDAP user sync are included from the Professional plan, so the decision is which identity source is authoritative for joiners, leavers and group membership. For Synapse, the equivalent settings are oidc_providers, saml2_config and CAS in the configuration file, and the server_name value fixes how every user ID such as @user:example.com is formed. Changing that value after accounts exist is effectively a migration, so confirm it before the first user signs in. Meeting links follow the same identity: a room or channel carries the user's account, and the meeting link opens the self-hosted Jitsi or Element Call instance that the team has chosen.
Scaling is where the two platforms differ most in operations. A Mattermost high availability cluster needs redundant application servers, redundant database servers and redundant load balancers, and it is available only on the Enterprise and Enterprise Advanced plans. Every node must mount the same shared file storage, either Amazon S3, an S3-compatible service or NAS, because local file system storage will not work correctly and risks corrupting files. Synapse takes a different route: the main process and its workers all connect to Redis, which relays replication between processes, while the generic worker handles client, federation and event traffic. Redis then becomes a component you must size, secure and monitor. Before committing, ask your team to confirm the storage platform, the Redis topology and the identity provider's group claims, and check the Mattermost high availability cluster documentation against your planned architecture.
The diagram that accompanies this section shows these paths in one view: sign-in from the identity provider, client traffic to the messaging server, shared storage and Redis on the back end, and meeting links leaving to the video service. Use it to walk through failure cases with your architects. Ask what happens to sessions when a load balancer or application node fails, whether file uploads remain available from every node, and whether a Synapse worker restart disrupts replication. Those answers determine the cluster design more than the feature list does, so record them in the implementation scope before procurement.
Moving spaces, users and history off Webex
This sequence turns Webex spaces and members into a documented, piloted and cut-over Mattermost or Matrix deployment, with a clear record of which history moved and which stayed behind. Each step ends with a check that the next one depends on.
Inventory Webex spaces and members
The Webex site administrator, with the messaging owner, lists every space, its members, guest accounts, moderators and retention settings. Export the list from Control Hub or the admin tools available in the tenant, and record which spaces are active, which are read-only and which hold regulated content. The step is done when every space has an owner, a member count and a retention decision, and the list is signed off by the business units that use it.
Decide what history can leave Webex
Confirm with Cisco, in your own Webex tenant, which message export formats, attachment downloads and API access your plan allows for spaces and compliance archives. Separate three groups: history you can export in a usable form, history you can export only as raw files, and history that cannot be exported at all. Record the decision for each group with the legal and records owners. The step is done when every space is tagged with its history outcome and that outcome is approved in writing.
Provision the chat server and identity
Build the target platform: Mattermost on Linux with PostgreSQL, or a Synapse homeserver with PostgreSQL, depending on the choice made for the wider rollout. Connect sign-in to your existing identity provider through SAML, OIDC or LDAP, and check which of these your chosen edition or server version supports. Set up backups and file storage, and confirm the plan for upgrades. The step is done when test accounts sign in through the identity provider and a restore from backup has been tested.
Map spaces to channels or rooms
Design the target structure. In Mattermost, a Webex space usually maps to a team channel or a private channel within a team, while in Matrix it maps to a room within a space. Decide how direct spaces become direct messages or small rooms, how guests are handled, and who creates and administers each container. Write the mapping as a table with source space, target container, owner, access model and retention. The step is done when the mapping table has been reviewed by the users who will feel the change most.
Import pilot data and run a pilot group
Import the history that the decision in step two approved, using the import tooling for the target platform, and load it into a staging environment first. Select a pilot group of users from a few spaces, and have them run their real work in the new platform for an agreed period while the old spaces stay open. Collect problems with attachments, notifications, mobile apps and search, and track fixes in a single log. The step is done when the pilot group signs off on the mapped spaces and the import results are checked against the source inventory.
Plan the cutover and communications
Agree a cutover date with the business owners, and decide whether Webex spaces become read-only, are archived or are deleted after an approved retention period. Prepare user guidance, a support route and a rollback plan that covers the platform's database and file storage. Confirm the connections to the self-hosted meeting platform, so that joining a call from a chat room works as intended. The step is done when the cutover runbook is approved and a rehearsal has run in staging.
Run the cutover and retire Webex messaging
Import the final data, switch users to the new platform, and set the old Webex spaces to the state chosen in the cutover plan. Monitor sign-in, delivery and support tickets during the first working days, and fix issues before they become habits. After the agreed period, remove Webex messaging licenses where the contract allows, and document the retained archives and where they are stored. The step is done when no active business work happens in Webex, the archive location is recorded and the licenses are released or scheduled for release.
What does replacing Webex messaging cost and take?
What are the main cost components of replacing Webex messaging with self-hosted chat?
The cost has five main parts: servers and storage, the database, licensing for any paid tier, staff time, and integration work. Infrastructure is paid to your cloud provider or data center vendor. Software is free under the open-source license for Matrix with Synapse or Mattermost's compiled binaries, but a paid Mattermost or Element tier adds a per-seat subscription. Staff time covers installation, identity integration, backups, upgrades and user support, and it is usually the largest recurring item. Integration covers connecting chat to the meeting platform and to your identity provider.
Which costs are one-time and which recur every year?
One-time costs include planning, the initial installation, identity and single sign-on configuration, data migration, user onboarding materials and the first security review. Recurring costs include server and storage capacity, database hosting and backups, staff time for upgrades, paid subscriptions where a commercial tier is chosen, and support for users. Upgrades recur on a regular cadence. Mattermost publishes server releases monthly, and its Extended Support Releases carry a defined support window, so budget for the upgrade work every year rather than treating the install as finished.
What drives the cost of self-hosted messaging up or down?
The biggest drivers are the number of concurrent users, whether you need high availability, how much file history you keep, and the paid features you require. For Mattermost, high availability clustering needs redundant application servers, database servers and load balancers, plus shared file storage such as S3-compatible storage or NAS, and it is only available on the Enterprise and Enterprise Advanced plans. For Matrix, Synapse scales with worker processes and Redis, and large federated deployments need more database capacity. Retention policy, search indexing and the number of integrations also add load. Keeping the user count small and the retention window short lowers both hardware and storage cost.
What should I ask for in a quote for replacing Webex messaging?
Ask for a written scope that lists the platform (Mattermost, Synapse with Element, or both), the number of users and expected concurrency, the target environment, and whether high availability is included. Request separate line items for infrastructure you will pay directly, implementation, identity integration, data migration, security hardening, backup setup, documentation and handover, and ongoing support or upgrades. Confirm which features need a paid tier, and ask the vendor for its current published licensing terms in writing, because Mattermost pricing is quoted through sales. Ask what is excluded, such as user training or changes to the Webex Meetings link.
Can our internal team run self-hosted messaging without an outside partner?
Many teams can, provided they already run Linux servers, PostgreSQL and a reverse proxy, and have someone who owns upgrades and on-call response. The work that is hardest to staff internally is usually the first setup: identity integration, a high availability design, backup and restore testing, and a documented upgrade path. Synapse upgrades can be hard to roll back because schema changes between releases are not always reversible, so a tested backup before every upgrade is essential. If your team lacks that depth, a fixed-scope engagement can cover the build and handover, followed by a retainer for upgrades and support.
How long does a Webex messaging replacement take?
The duration depends on scope rather than on a fixed number. The main variables are how many users and teams move, whether single sign-on and directory sync must work from day one, whether high availability is required, how much chat history migrates, and how many integrations must be rebuilt. A small pilot with one platform and basic sign-in takes much less time than a multi-site, highly available deployment connected to meetings and compliance logging. Ask for a timeline in the written scope, with milestones for design, pilot, cutover and handover, and confirm which parts depend on your own change approval windows.
Can we migrate our Webex chat history to the new platform?
Partly, and it depends on what Webex exports and what the target supports. Confirm with Webex what messaging data your site can export before the contract ends, and check its format and completeness in writing. Mattermost has a documented migration path from Slack, which is useful for planning but is not a Webex importer, so a Webex migration usually needs a custom script or a tool you validate yourself. Matrix rooms can be populated through the client-server API, but imported history often appears differently from native events. Plan a test import, verify message counts and attachments on a sample of rooms, and decide which history is archival only.
Does self-hosted messaging need extra security and compliance work?
Yes. Your team owns the controls that Webex previously handled, including TLS certificates, access to the database and file storage, backup encryption, logging, and patching. Connect single sign-on to your identity provider, enforce multi-factor sign-in there, and document who can administer the server. Synapse federation should be restricted with an allowlist if you do not need open federation. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports and certifications, so confirm early which assessment your organization needs.
What to confirm before you commit to a platform
Start by listing every Webex messaging feature your teams use today and checking each one against the target platform. Spaces, threaded replies, file sharing, guest access, retention rules, and the Webex apps and bots your teams rely on are the usual gaps. Confirm in writing which of these have a direct equivalent in Mattermost or Matrix with Element, which need a workaround, and which you will drop. Also list the integrations with Microsoft Teams-era tools, calendars and ticketing systems, because each one needs an owner, a connector and a test. Mattermost and Matrix both have integration and bridge options, but the set you need must be confirmed against your own systems, not assumed from a feature list.
Next, settle data residency and identity before choosing a version. Decide where messages, uploaded files and the PostgreSQL database must physically sit, who can administer them, and whether any data may leave your network. For Mattermost, check the current release and support dates on the server releases page for the version you intend to run, and confirm whether your plan includes SSO and AD/LDAP sync and whether high availability needs the Enterprise tier. For Matrix, confirm the Synapse version you will deploy, its PostgreSQL and Python requirements in the upgrade notes, and whether you need worker processes and Redis at your scale.
Finally, write down your federation policy before the first user logs in. In Synapse, federation is controlled by settings such as federation_domain_whitelist, and the documentation recommends firewalling the federation listener as well. Decide whether your server may talk to other organizations, which domains are allowed, and how server_name will identify your users, because changing it later is difficult. Agree the same decisions for Mattermost guest access and external sharing. Ask your security team to test the controls, and ask your vendor or partner to show the configuration in your own environment before cutover.
Risks that derail a messaging migration
Most messaging migrations stall on a handful of predictable issues: chat and video drifting apart, platform version floors, hard-to-reverse upgrades, storage design, and exposure of federation endpoints. Each card names the mitigation to plan for before users move off Webex spaces.
Chat and video in separate silos
If Mattermost or Matrix handles chat while meetings stay on Jitsi or BigBlueButton, users must switch tools mid-conversation and lose the link between a thread and the call that followed it. Decide early which meeting join links will appear inside channels and rooms, and who owns the single sign-on identity both systems use. Test a full workflow end to end with real channel members before cutover, not just each tool on its own.
Unsupported database and Python versions
Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer. A server built on an older base can stop receiving compatible upgrades at the moment you need one. Inventory the database and runtime versions in your target build before you install, and confirm the minimum versions against the upgrade notes for the release you plan to deploy.
Synapse rollback after schema changes
Synapse upgrades can change the database schema, and the upgrade notes warn that rolling back is often difficult. Once users have posted messages on a newer release, reverting the code alone may not restore a working server. Take a verified database backup immediately before each upgrade, rehearse the upgrade on a copy of production data, and record the exact release you are moving from so recovery is a planned procedure.
Local file storage in Mattermost clusters
A Mattermost high availability cluster needs shared file storage on Amazon S3, an S3-compatible service or a NAS mounted on every node. Local file system storage will not work correctly in a cluster and can corrupt files. Confirm the storage design with your infrastructure team before procurement, and budget for the high availability tier, since clustering is available only on the Enterprise and Enterprise Advanced plans.
Federation exposure on Matrix
Synapse federates on port 8448 by default, so a server reachable from the internet can exchange data with any homeserver unless you restrict it. The federation_domain_whitelist setting limits federation to listed domains, and an empty list disables it entirely. For an internal-only deployment, set the allowlist deliberately, firewall the federation listener, and confirm with your security team which external domains, if any, need access.
Low user adoption after cutover
Teams that moved from Webex spaces often bring habits with them: pinned files, guest access, mobile notifications and bots that expect Webex APIs. Adoption falls when those habits are not mapped to the new platform. Run a pilot group, document how each common Webex task is done in Mattermost or Element, and plan a read-only period for the old spaces so people can find history without confusion.
How DeployOpen scopes and delivers the messaging replacement
The sequence moves from a written scope to a documented, hardened messaging platform that is wired to identity and to meeting links, so chat and video do not end up in separate silos. Each step closes with a check the client can verify.
Agree the scope in writing
DeployOpen starts by documenting what is in scope: which Webex spaces and messaging data must be replaced, the target platform (Mattermost or Matrix with Element), the number of users, the channels and rooms that matter, and which meeting platform the chat links will point to. The client's security, identity and compliance owners review the draft, and the agreed scope, deliverables and timeline are signed off before any installation work begins. The output is a written scope document that both parties have approved.
Confirm the platform and edition choice
Before building anything, DeployOpen and the client confirm the platform choice against the requirements gathered in scope. For Mattermost, this includes the edition, since high availability clustering and FIPS 140-3 compliance are listed for Enterprise and air-gapped deployment for Enterprise Advanced, and the team should confirm current terms with Mattermost sales. For Matrix, it includes the homeserver choice and whether Element Server Suite Community or a commercial option fits. The output is a recorded decision with the edition, version track and licensing terms the client has accepted.
Install the platform in your infrastructure
DeployOpen plans and installs the chosen platform inside the client's own cloud accounts, data centers or air-gapped network. For Mattermost, that means a Linux server with PostgreSQL and, for clustered setups, shared file storage on S3, an S3-compatible service or NAS, because local file storage will not work correctly across nodes. For Matrix, that means Synapse with PostgreSQL, with worker processes and Redis if the scale calls for it. The output is a running staging environment that the client has accessed and tested.
Integrate identity and sign-in
DeployOpen connects the platform to the client's identity provider so users sign in with existing accounts and leave the Webex login behind. For Mattermost, this typically means SAML or OIDC single sign-on and AD or LDAP user sync, which the Professional plan and above include according to the Mattermost pricing page. For Synapse, it means configuring oidc_providers, saml2_config or CAS. The output is a test group of users who can sign in and be deprovisioned through the agreed process.
Connect chat to meeting links
DeployOpen wires the chat platform to the self-hosted meeting service the client has chosen, so a channel or room can start a call without a Webex link. For Matrix, this can mean Element Call, which uses a LiveKit SFU and needs its own services operated. For Mattermost, it means integrating a self-hosted Jitsi or BigBlueButton link flow. The team confirms each integration against the current vendor documentation before handover. The output is a tested meeting-launch path from chat, with the ownership of each component documented.
Harden and document the deployment
DeployOpen applies hardening that matches the agreed scope, including TLS certificates, restricted administrative access, network controls and, for Synapse, a federation_domain_whitelist with the federation listener firewalled. It also records configuration, backup and restore procedures, and an operating runbook. Where the client is preparing for a compliance assessment, DeployOpen prepares the controls and evidence, but independent auditors and certification bodies issue any audit report or certification. The output is a hardening record and runbook that the client's staff can follow.
Cut over and hand over
DeployOpen plans the cutover with the client, including user communication, the approach to historical Webex content and the rollback path. Because Synapse upgrade notes warn that rolling back can be difficult after schema changes, the rollback plan is confirmed before the switch. After go-live, the client's administrators are trained and the handover is signed off. The output is a completed cutover record and a handover document that names who runs the platform day to day.
Agree a retainer for upgrades and support
Ongoing upgrades, patching, backup checks and support are offered as a retainer, separate from the fixed-scope build. Mattermost publishes new server versions on the 16th of each month and tracks ESR support windows, and Synapse drops support for Python and PostgreSQL versions when they reach upstream end of life, so the client should confirm the upgrade cadence the retainer covers. The output is a written support agreement that states the response expectations, the upgrade schedule and the points at which the client decides on changes.
