Which open-source alternative to Webex fits your situation
If your renewal is coming up and you need meetings to stay inside your own infrastructure, Jitsi Meet is the most direct replacement for the meeting experience, while BigBlueButton fits teams that also want a virtual classroom with recording and polls, and Matrix with Element Call fits organizations that want chat and calls under one self-hosted system. Webex Video Mesh solves a different problem: it keeps media on your premises but leaves the service registered to and managed from the Webex cloud, so it is not an exit from Webex. Decide first whether you are replacing the meeting service or only moving media on-premises, because the answer changes the entire shortlist. Teams usually start looking at alternatives for one of four reasons: a licensing or pricing change at renewal, a data residency rule that requires media and recordings to stay in a specific location, a dependency on one vendor's roadmap, or the cost of running Video Mesh servers alongside Webex licenses. Licensing details differ by contract, so confirm the exact terms with Cisco and your reseller before you assume any savings. On the open-source side, Jitsi Meet is licensed under Apache-2.0 and BigBlueButton under LGPL-3.0, so you can run them without per-seat fees, but you will carry the infrastructure, staffing and support costs yourself.
Before choosing, check three things in your own environment: whether residency rules cover recordings and transcripts as well as live media, whether you need dial-in by phone or SIP, and how many concurrent participants you must support at peak. Jitsi Meet is lighter to deploy and suits ad hoc meetings, while BigBlueButton needs substantially more resources per session, so ask your architect to size both against your real peak. Webex Video Mesh may still be the right answer if your priority is local media for Webex users while you postpone a platform change, and that is a legitimate interim choice. Ask Cisco to confirm in writing which Video Mesh components remain managed from the cloud and what data leaves your network, so the residency assessment rests on documented facts rather than assumptions.
Open-source options for replacing Webex meetings
Each option runs inside your own infrastructure, but they differ in how they handle meetings, recordings, chat and identity. The cards below set out when each one fits, what it requires, and the main trade-off to weigh before you choose.
Jitsi Meet for browser-based meetings
HTTPS is required for multimedia to work, so plan certificates before anything else. Jitsi Meet is Apache-2.0 licensed and maintained by 8x8, Inc., which also sells hosted Jitsi as a Service. A self-hosted deployment combines the web front end, the Prosody XMPP server, Jicofo and Jitsi Videobridge, with optional Jibri for recording and streaming and Jigasi for SIP. It fits teams that want browser-based meetings with a comparatively small set of moving parts. The trade-off is that recording and dial-in add components you must patch, monitor and test.
BigBlueButton for recorded sessions
Plan the hardware before the license question, because BigBlueButton is the heaviest of the three. It is an LGPL-3.0 licensed virtual classroom, and v4.0.0 was published on October 14, 2026. It installs with bbb-install.sh on Ubuntu 24.04 and suits organizations where recordings, breakout rooms and whiteboards matter more than lightweight calls. Greenlight serves as the room manager front end. Expect to provision at least 16 GB of memory, 8 CPU cores, 500 GB of disk for recordings, UDP ports 16384 to 32768 and 250 Mbit/s symmetrical bandwidth.
Matrix with Element Call for chat-led teams
Element Server Suite Community includes Synapse, the Matrix homeserver, alongside Element Call for voice and video, under AGPL. This fits organizations that already want federated, end-to-end encrypted chat and want meetings inside the same client. Matrix is a different model from Webex, so identity, room design and chat history retention need planning before rollout. Confirm with Element which components, support tiers and licensing obligations apply to your deployment, since AGPL terms on modified code affect how you procure and maintain it.
Choosing between the three paths
Webex Video Mesh keeps media on-premises, but the software stays registered to and managed from the Webex cloud, so it is not a self-contained replacement. Each open-source option removes that cloud control plane but moves identity, certificates, backups and upgrades to your team or implementation partner. Run a pilot with your largest typical meeting, measure bandwidth at each site, and confirm recording storage and retention rules with your compliance owner before you commit to one path.
How each Webex capability maps to open-source options
This table maps the main Webex capabilities to the open-source options that cover them, with the gaps marked. Read each row as a question to answer for your environment: where the media runs, who administers the service, and which features your users depend on. Video Mesh keeps media on your premises, but the service stays registered to and managed from the Webex cloud, so it is a different model from a fully self-hosted stack.
| Capability | Webex (with Video Mesh) | Open-source options |
|---|---|---|
| Meetings and scheduled rooms | Cloud meetings, with Video Mesh placing media on an on-premises Cisco UCS server registered to the Webex cloud | Jitsi Meet covers ad hoc and scheduled meetings. Matrix with Element Call covers voice and video inside a Matrix deployment. Confirm room scheduling and calendar integration for each option. |
| On-premises media | Media stays local while Video Mesh has capacity, but the node is still registered to and managed from the Webex cloud | Jitsi and BigBlueButton run entirely in your infrastructure, with no required cloud control plane. Media and control both stay where you host them. |
| Overflow when local capacity runs out | Video Mesh overflows meetings to the Webex cloud when on-premises capacity is exhausted | Gap. Self-hosted options do not overflow to a vendor cloud. Capacity planning and horizontal scaling become your responsibility. |
| Recording | Cloud and local recording, managed through Webex | Jibri adds recording and streaming to Jitsi. BigBlueButton records natively. Confirm output formats and storage sizing, since BigBlueButton 4.0 documentation cites 500 GB of disk for recordings. |
| Transcripts and captions | Webex transcription features, managed by the vendor | Confirm per option. Transcription is typically added through a separate speech-to-text service, and you should verify language support and where audio is processed. |
| SIP and dial-in | PSTN and SIP dial-in through Webex calling and partners | Jigasi provides SIP connectivity for Jitsi. Confirm carrier, dial-in numbers and call-in support with your telephony provider for BigBlueButton and Matrix. |
| Interoperability with other platforms | Broad integration with Webex ecosystem and standards-based endpoints | Jitsi and BigBlueButton are browser-based and work with standard endpoints through SIP. Confirm room system and calendar integrations before committing. |
| Central administration | Control Hub manages users, policies and Video Mesh nodes from one console | Gap. No single equivalent console is implied. Plan for configuration management, identity integration and monitoring that you build or contract for. |
How self-hosting differs from Video Mesh for data residency
Webex Video Mesh keeps media on a Cisco UCS server in your data center, but that server is registered to the Webex cloud and managed from Control Hub, and it overflows to the cloud when local capacity runs out. Self-hosted Jitsi, BigBlueButton or Matrix with Element Call differ in a more basic way: the signaling, media, metadata and recording components all run inside your own cloud account, data center or air-gapped network, and no vendor control plane sits in the path. Before you rely on either design for residency, confirm each data type separately. Signaling and presence, meeting metadata such as room names, participant lists and timestamps, media streams, and recordings can each take a different route, and a single claim that meetings stay local hides those differences.
For Video Mesh, ask Cisco in writing which data still reaches the Webex cloud when a node is registered and healthy, which data moves only during overflow, and whether the registration, usage and diagnostic data is held in a specific region. Check the Video Mesh deployment guide for the exact traffic flows and the conditions that trigger cloud overflow, and test that overflow is disabled if your policy requires it. For a self-hosted design, the questions move to your own architecture: where the TURN relay runs for participants behind restrictive firewalls, where logs and monitoring data are stored, and whether any component calls an external service at startup or for updates. Jitsi also requires HTTPS for multimedia to work, so certificate management becomes part of your residency controls rather than an afterthought.
Recordings are the item most often overlooked. In a Video Mesh deployment, confirm where recordings are written when a meeting is held on premises, and whether the cloud copy is created by default. In a self-hosted BigBlueButton deployment, plan the storage location for recordings, because the installation documentation calls for at least 500 GB of disk for recordings, and decide whether that volume sits on encrypted storage inside your boundary. In a self-hosted Jitsi deployment, recording depends on the optional Jibri component, so you control both whether it is installed and where its output lands. Document each answer as a data flow diagram and keep it with your assessment evidence, because an auditor will ask where each category of meeting data is stored, not whether the platform is open source.
What a self-hosted replacement costs over several years
This table compares the cost components of staying on Webex with those of self-hosting Jitsi, BigBlueButton or Matrix with Element Call. Read each row as a question to put to a quote: who gets paid, whether the cost is one-time or recurring, and what pushes it up or down. The main takeaway is that infrastructure sizing, including the BigBlueButton 4.0 minimums, and internal skills often matter as much as the license line.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Webex subscription or license | Cisco or your Webex reseller | Recurring | Seat count, licensed features and contract term. Confirm the renewal terms and any changes to licensing with your account team. |
| Compute servers | Your hardware or cloud provider | Recurring (cloud) or one-time plus refresh (on-premises) | Concurrent meetings and participants. BigBlueButton 4.0 installs on Ubuntu 24.04 with at least 16 GB of memory and 8 CPU cores per server, so size from that minimum upward. |
| Bandwidth | Your network or internet provider | Recurring | BigBlueButton 4.0 needs at least 250 Mbit/s symmetrical bandwidth, plus UDP ports 16384 to 32768 open. Confirm with your network team whether this is already committed. |
| Recording storage | Your storage or cloud provider | Recurring and growing | BigBlueButton 4.0 needs at least 500 GB of disk for recordings. Retention policy and recording volume set the long-term figure. |
| Implementation and hardening | DeployOpen or your internal team | One-time | Scope, number of platforms, HTTPS and identity integration, and load testing. Ask for a fixed-scope written proposal with deliverables. |
| Migration of recordings and history | DeployOpen or your internal team | One-time | Volume of existing Webex recordings and whether transcripts must be preserved. Confirm export options with Webex before scoping. |
| Support and upgrades | DeployOpen, a retainer, or your internal team | Recurring | Upgrade cadence, on-call expectations and patching windows. A retainer converts this into a predictable recurring line. |
| Internal skills and staff time | Your employees | Recurring | Team familiarity with Linux, TURN and network tuning. Plan for training and on-call coverage. |
What you give up when you leave Webex and the usual workarounds
Moving off Webex means taking on duties the vendor performs today: keeping the service running, scaling beyond local hardware, connecting to room systems and phone networks, and giving administrators visibility. Each card below names one of those duties, the workaround that covers it, and what to confirm before you commit.
Vendor-managed uptime and updates
Webex runs the cloud service, applies its security patches and handles most upgrades for you. With Jitsi, BigBlueButton or Matrix, your team owns the servers, the TLS certificates, the database backups and the patch schedule. A practical workaround is a written runbook covering on-call rotation, maintenance windows and a tested restore procedure. Confirm with each platform's maintainers which versions receive security fixes and how long older releases stay supported.
Native cloud scale and overflow
Webex Video Mesh keeps meetings on local hardware and sends overflow to the cloud when on-premises capacity runs out. An open-source stack has no such fallback unless you build one. Size the media servers for peak concurrent participants, then decide whether to add a second site or a cloud region. Ask your team to load test with realistic meeting sizes before rollout, since media bandwidth and CPU, not user accounts, usually set the limit.
Room system and PSTN interoperability
Webex has vendor-supported connections to its own room devices and to calling services. Open-source platforms offer more limited options: Jitsi has an optional SIP gateway called Jigasi, while BigBlueButton and Matrix rely on community or custom integrations for hardware endpoints and telephone dial-in. Inventory every room codec, phone bridge and SIP trunk you use today. Then confirm, platform by platform, which of them work without custom code and who supports the integration if it breaks.
Managed administration and analytics
Webex Control Hub gives administrators one console for users, policies, device health and usage reports. Self-hosted tools expose administration through configuration files, admin panels and logs that you collect yourself. Decide early which reports auditors and service owners need, such as meeting counts, recording access and failed joins, and build those from logs or a monitoring stack. Confirm which admin functions each platform provides out of the box and which need extra tooling.
Polished mobile and desktop clients
Webex ships native apps for each major mobile and desktop platform, with background noise handling and consistent device behavior maintained by the vendor. Open-source options differ in client maturity. Jitsi and Element Call run in browsers and offer apps, while BigBlueButton is primarily browser-based. Test the clients your staff actually use on the networks they actually use, including VPN and guest Wi-Fi, and record which features are missing before you set expectations.
How to move from Webex to self-hosted meetings
This sequence moves meetings, recordings and integrations from Webex to a self-hosted platform in controlled stages, so each group can switch with a known fallback. It ends with a documented, decommissioned Webex estate and a record of what was migrated and what was retired.
Inventory meetings, rooms, users and integrations
Your collaboration or IT team lists every Webex site, licensed user, meeting room and device, plus the calendar, SSO, SIP trunk, LMS and other integrations that depend on Webex. Record which meetings are recurring, which have external guests, and which rely on dial-in numbers. Done means you have a single inventory that names an owner for each item and marks the integrations that will need a replacement or a rewrite.
Export existing recordings and transcripts
Identify which recordings and transcripts must be kept for records, policy or legal hold, then export them from Webex while the administrator still has access. Confirm the file formats and metadata you receive, and check whether your retention rules require encrypted storage in your own environment. Done means every retained item sits in an archive you control, with a log of what was exported and what was excluded.
Map Webex features to the chosen platform
Compare each feature your users depend on with the candidate platform: Jitsi Meet, BigBlueButton with Greenlight, or Matrix with Element Call. Cover recording, breakout rooms, dial-in, SIP, live captions, polls, device support and single sign-on, and mark each as available, available with add-ons, or a gap. Confirm any capability you cannot verify in the platform's own documentation. Done means you have a signed-off gap list that shows which workflows need a workaround or a change in habit.
Build the self-hosted environment and test access
Deploy the chosen platform in your own cloud account, data center or air-gapped network, then configure identity, TLS certificates and network rules. For Jitsi, serve every page over HTTPS, because the Jitsi self-hosting guide states that HTTPS is necessary for multimedia to work. For BigBlueButton 4.0 on Ubuntu 24.04, open UDP ports 16384 to 32768 and confirm the hardware and bandwidth in the install documentation. Done means test meetings work from inside and outside your network, with media passing through the firewall and load tests run at your expected peak.
Run a pilot group on the new platform
Choose a small group that represents your main meeting types, including one with external guests and one with room hardware. Give them written guidance on joining, recording and reporting problems, and collect feedback through a short structured review. Done means the pilot group has completed its normal meetings on the new platform, and the open issues are logged with an owner and a fix or an accepted workaround.
Run both platforms in parallel
Keep Webex active while new meetings are scheduled on the self-hosted platform, so users can fall back if something breaks. Monitor call quality, join failures, capacity and recording completion each week. Done means you have a stable record for the whole parallel period, and the business owners accept that the new platform meets the requirements in the gap list.
Cut over links, devices and integrations
Update meeting links, calendar templates, dial-in numbers, SSO configuration and device provisioning, then announce the cutover date and publish the new joining instructions. Redirect or retire old Webex links so users do not join a meeting that no longer exists. Done means the calendar, device and integration checks pass, and the service desk reports no unresolved cutover tickets.
Decommission Webex and document the result
Once the cutover is stable, disable Webex licenses, remove integrations and revoke API tokens, and confirm with your provider how account data is deleted or returned. Keep the archive of exported recordings under your retention policy and document the final configuration, backup schedule and support ownership. Done means a signed record shows Webex is switched off, data disposition is confirmed in writing, and the self-hosted platform has a named operations owner.
Which option fits by situation
Residency requirements usually mean that meeting media, chat and recordings must stay inside your own cloud account, data center or air-gapped network. Jitsi Meet is the simplest fit here because it runs as a set of services you control, and it does not need a vendor cloud to route a meeting. Webex Video Mesh also keeps media local, but the software stays registered to and managed from the Webex cloud, so confirm with your legal and security teams whether that control plane counts as acceptable residency for your data.
- Jitsi Meet: the web front end, Prosody, Jicofo, Jitsi Videobridge and optional Jibri all run in your environment, so media and recordings stay where you place them.
- BigBlueButton: a good fit when recordings and session data must be stored on your own disks, but it needs substantial capacity on each server.
- Matrix with Element Call: suits organizations that also need self-hosted chat, with the server components under your control.
- Webex Video Mesh: keeps media on premises but depends on the Webex cloud for registration and management, which may not meet a strict residency rule.
- Condition to check: whether your residency policy covers control-plane metadata, logs and account data as well as media.
Before you choose, map every data type (media, recordings, chat, logs, identity) to a location and confirm each with your data protection owner.
Cost-driven exits usually come from per-seat renewals or from add-on modules that multiply the licence bill. With self-hosting, you move cost from licences into infrastructure, staff time and support. The main recurring costs are compute, storage, bandwidth, monitoring and the engineers who patch and upgrade the platform. Jitsi Meet is generally the lightest to run for ad hoc meetings, while BigBlueButton carries heavier hardware needs and therefore a higher recurring footprint.
- Jitsi Meet: Apache-2.0 licensed, so there is no per-user licence, but you pay for servers, bandwidth and operations.
- BigBlueButton: LGPL-3.0 licensed with no licence fee, but a single server needs at least 16 GB of memory, 8 CPU cores and 500 GB of disk for recordings, with 250 Mbit/s symmetrical bandwidth.
- Element Server Suite Community: includes Element Call under AGPL, though you should check which features and support levels a paid tier adds.
- Mattermost Entry: the free tier limits calls to 40 minutes, which may not suit long meetings.
- Condition to check: whether staff time to operate the platform outweighs the licence savings at your user count.
Ask any implementation partner for a quote built from written scope, and separate one-time setup from recurring operations and upgrades.
Classroom and webinar use needs more than a meeting room: shared whiteboards, polls, breakout rooms, presenter controls and recordings that students can replay. BigBlueButton is built around this use case and is the strongest match among the three options. Jitsi Meet works well for simpler sessions and can add recording through Jibri, but it is less oriented toward structured teaching. Confirm the feature list you need against current documentation before you decide.
- BigBlueButton: purpose-built for virtual classrooms, with presentations, polls and breakout rooms.
- Greenlight: BigBlueButton's room manager front end, which helps teachers create and manage rooms.
- Jitsi Meet with Jibri: suitable for lighter sessions and live streaming, but with fewer classroom-specific tools.
- Scale condition: large webinars with many attendees need load testing against your own hardware, since BigBlueButton's requirements grow with concurrent participants.
- Condition to check: whether you need a learning management system integration, which should be verified for each platform.
Run a pilot class with your actual content and student count before you retire the Webex deployment.
Teams that already run chat on Matrix, or that want chat, voice and video in one self-hosted system, should look at Matrix with Element Call. Element Server Suite Community bundles Synapse with Element Call for voice and video, under AGPL. This option changes the model: meetings sit inside a messaging platform rather than a standalone conferencing tool, which suits asynchronous collaboration but may feel different to users accustomed to Webex. It is not a drop-in replacement for a large webinar or lecture format.
- Synapse and Element Call: provide Matrix-based chat with voice and video calls in one deployment.
- Federation: Matrix can federate with other servers, which affects who can join your rooms, so review federation settings before launch.
- User change: people used to scheduling Webex meetings will need training on rooms and clients.
- Condition to check: whether your use case is mostly calls among a known group, rather than large external meetings.
- Licence check: confirm current licence terms and included features on the Element pricing page before deployment.
Test call quality with your real user locations and network paths, because media relays and TURN configuration strongly affect the result.
Organizations with many integrations, such as calendar systems, identity providers, contact centers, SIP telephony or room hardware, should weigh integration effort before choosing. Jitsi Meet offers Jigasi for SIP connectivity, which can bridge some telephony needs. Webex has a large native ecosystem, so replacing those links often means building or configuring them yourself. Map each integration in use today and mark whether it is required on day one.
- Jigasi for SIP: provides a route to telephone dial-in for Jitsi Meet deployments.
- Calendar and identity: confirm which single sign-on and calendar connectors your chosen platform supports or can be extended to support.
- Room hardware: check that existing video room systems can join the new platform before retiring Webex endpoints.
- Webex Video Mesh: may remain the better choice for a short transition if you cannot replace every integration at once.
- Condition to check: whether any integration is unsupported, since that becomes custom development work.
Inventory every integration first, then ask a partner for a fixed-scope integration plan with written deliverables.
How to keep recordings and avoid lock-in when exiting Webex
Exit planning for Webex starts with a question most teams leave until the contract is ending: how does your tenant export recordings and transcripts, and in which formats? Confirm this in your own tenant before you pick a replacement, because the answer decides how much of your meeting history can move without manual rework. Ask your Webex administrator and your account team to show the export options available to your licence type and your Control Hub configuration, and record who has the rights to run them. Do not assume that a recording stored in the cloud is the same as a recording you can take with you. Some export paths depend on the account type, the recording location and the retention policy in force, so treat each one as something to verify, not something to presume.
Once you know what leaves the tenant, check that the files are stored in open formats that a self-hosted platform can read. A practical test is to export a sample set covering video, audio, chat and any transcript or caption files, then store them in a location you control and keep a manifest that maps each meeting to its files, owners and dates. Then play them back on the platform you plan to run, whether that is Jitsi, BigBlueButton or Matrix with Element Call, and confirm that audio sync, file naming and transcript timing survive the move. Note that these platforms record in their own ways, so a recording made on Webex and a recording made on a new platform may not be interchangeable. Plan for a retention decision on both sides, and agree in writing who owns the archive once the Webex subscription ends.
Questions buyers ask before replacing Webex
What drives the cost of replacing Webex with self-hosted software?
The cost is set by the people and infrastructure you need, not by a license fee, because Jitsi Meet and BigBlueButton are Apache-2.0 and LGPL-3.0 licensed. Costs fall into four components: servers and bandwidth in your cloud or data center, the engineering time to deploy and integrate, ongoing operations and upgrades, and support or retainer work if you buy it. Recurring costs grow with concurrent users, recording volume and the number of regions you serve. Ask any partner for a quote built from a written scope that lists each component separately, and ask which parts are one-time and which recur.
How long does a Webex replacement take to implement?
The timeline depends on scope, not on a fixed duration. The main factors are how many meeting modes you need (browser meetings, recording, dial-in, large webinars), whether you integrate with identity, calendars and existing rooms, how many environments you run, and how much your change and security review processes require. Jitsi and BigBlueButton have documented install paths, so a small pilot can be set up quickly, but production readiness depends on testing and approvals. Ask for a schedule with milestones and written acceptance criteria before work starts.
What does the work need from our internal team?
You need named owners for infrastructure, identity, networking and security, plus people who can approve firewall changes, certificates and data handling. A self-hosted platform also needs an operations owner for monitoring, patching and backups after go-live. Your team should also decide who users contact for support and how recordings are stored and retained. Ask your provider which of these roles they will fill, which you must fill, and how knowledge transfer and runbooks will be handled.
Can our own engineers self-host Jitsi or BigBlueButton without outside help?
Yes, many teams do, because both projects publish installation documentation and Jitsi offers Docker containers as well as Debian and Ubuntu packages. Self-hosting is realistic for a team with Linux, networking and TLS experience, but it adds ongoing duties. Jitsi's self-hosting guide states that HTTPS is necessary for multimedia to work, and BigBlueButton 4.0 requires UDP ports 16384 to 32768 along with significant memory, CPU and disk. Assess your team's skills honestly, run a pilot, and decide whether outside help covers implementation only or also continuing operations.
What HTTPS and firewall settings do Jitsi and BigBlueButton need?
Jitsi needs a valid HTTPS certificate on the web front end, because its self-hosting guide states that HTTPS is necessary for multimedia to work. Media traffic relies on UDP, so firewall rules must allow the media ports the chosen components use, and your network team should confirm the required ports against the current installation documentation. BigBlueButton 4.0 specifically needs UDP ports 16384 to 32768 open. Plan certificate renewal, reverse proxy configuration and inspection policies, because TLS-inspecting firewalls can disrupt real-time media.
Will self-hosted meetings scale to large events and webinars?
Scale depends on how you size and distribute the platform, not on the software alone. Jitsi splits work across the Jitsi Videobridge, Jicofo and Prosody components, so bridges can be added as load grows. BigBlueButton is designed for classroom-style sessions, and its install requirements show that a single server needs at least 16 GB of memory and 8 CPU cores. For very large webinars, load test your target participant count and bandwidth before committing, and confirm with your provider how the architecture scales beyond one site.
What should Webex Video Mesh customers ask before switching?
Ask what Video Mesh does for you today. Video Mesh runs on an on-premises Cisco UCS server, is registered to the Webex cloud, and is managed in Control Hub, and it overflows to the cloud when local capacity runs out. A self-hosted replacement keeps media and control in your environment but removes that cloud overflow, so you must size capacity for peak demand. Ask how calendar integration, device support, single sign-on and recording storage will work after the move, and whether a hybrid period with both platforms is needed.
How do we move existing Webex recordings and data?
Recordings and chat history stay in Webex until you export them, so plan that export early. Confirm with Webex which formats and download methods your tenant supports, then decide where archived files will live and who may access them. Data retention rules, legal holds and any regulatory retention periods should be settled before cut-over. Your provider should list migration tasks, owners and verification steps in the written scope.
How DeployOpen scopes, migrates and supports your Webex replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Webex replacement, that means agreeing on which platform fits your meeting, recording and identity needs before any installation begins.
How we scope
- Inventory current Webex use: meeting volumes, regions, SIP and PSTN links, recording needs and integrations with calendars and identity.
- Decide between Jitsi, BigBlueButton or Matrix with Element Call based on the use cases you confirm, with gaps stated in writing.
- Agree deliverables, timelines and exclusions in a written, fixed-scope document before any work starts.
How we build
- Deploy the chosen platform in your environment, including HTTPS certificates, firewall rules and the UDP media ports the platform requires.
- Size servers against the vendor's published requirements and confirm bandwidth, memory and storage with your network team before purchase.
- Test sign-in, joining from common browsers and devices, recording and, where applicable, dial-in, and document the results.
How we hand over
- Deliver architecture notes, configuration records, runbooks and a user guide written for your administrators and end users.
- Walk your operations team through backup, upgrade and monitoring procedures so they can run the service without us.
- Provide a migration plan for existing Webex recordings and user accounts, with the steps your team needs to confirm with Cisco first.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Repeat security testing of the deployed service on a schedule you agree in the written scope.
- Prepare systems, controls and evidence for your compliance assessment, while independent auditors issue any report or certification.
