Open-source alternatives to Zoom

Which open-source Zoom alternative fits your renewal, data residency or lock-in problem

If your problem is a renewal, a residency rule or lock-in to a cloud service, Jitsi Meet is the better fit for browser-based meetings, and BigBlueButton is the better fit for classroom-style sessions that need recording. Both are self-hosted, so meeting media can run inside infrastructure you control. Jitsi Meet is Apache-2.0 licensed and runs from a web front end, the Prosody XMPP server, Jicofo and Jitsi Videobridge, with Jibri added if you need recording. BigBlueButton is LGPL-3.0 licensed and is built around a presenter, polls, breakout rooms and a shared whiteboard, which suits training and teaching.

Teams usually start looking at alternatives for one of three reasons: a renewal that changes the cost base, a rule that keeps meeting data inside a defined jurisdiction or network, or a desire to avoid depending on one vendor's cloud for every meeting. Zoom's own on-premises route, Zoom Node, is deployed on customer premises but managed from the Zoom cloud, so it addresses where media runs without removing the cloud management dependency. Self-hosted Jitsi or BigBlueButton removes that dependency, but you take on operations: patching, TLS, capacity and backups are yours. Before you decide, confirm with your security team whether a cloud-managed control plane is acceptable under your residency rule.

Start by listing which meetings need recording and who will watch them, because recording drives storage and bandwidth more than participant count does. BigBlueButton 4.0 documentation asks for at least 16 GB of memory, 8 CPU cores, 500 GB of disk for recordings and 250 Mbit/s symmetrical bandwidth, and Jitsi requires HTTPS for media to work. Also plan the export of existing Zoom recordings, which arrive as MP4, M4A, TXT chat, VTT transcript and CC.VTT caption files that you can download from the recordings page. Confirm those formats against your own account before you commit to a migration path.

Jitsi Meet, BigBlueButton and Element Call compared as Zoom replacements

Jitsi Meet, BigBlueButton and Element Call cover different parts of what Zoom does. Each one needs its own server footprint, its own identity setup and its own view of recording and chat. The cards below set out what each option is, where it fits and the main trade-off to weigh before a renewal decision.

Jitsi Meet for general meetings

Jitsi Meet is the closest like-for-like replacement for ad hoc and recurring meetings. It is Apache-2.0 licensed and maintained by 8x8, Inc., which also sells hosted Jitsi as a Service, so the self-hosted code path is open even when a vendor stands behind the project. A deployment combines the web front end, the Prosody XMPP server, Jicofo and Jitsi Videobridge, with optional Jibri for recording and Jigasi for SIP dial-in. Check how many concurrent participants your videobridge capacity must hold, and confirm HTTPS on the public hostname before users join.

Jitsi self-hosting prerequisites

Jitsi depends on HTTPS for multimedia to work, so certificate management is part of day-one operations rather than an afterthought. You can deploy from Docker containers or from Debian and Ubuntu packages, and your choice sets how upgrades and rollbacks are handled. Plan for the separate firewall and UDP media path, and for a recording storage location if Jibri is enabled. Ask your team who owns certificate renewal and bridge monitoring after go-live.

BigBlueButton for classrooms and webinars

BigBlueButton fits teaching, training and webinar work where breakout rooms, polls, shared presentations and built-in recording matter more than a generic meeting experience. It is LGPL-3.0 licensed and installs with a script on Ubuntu. The platform is heavier than Jitsi, with published minimums for memory, cores, recording disk and symmetrical bandwidth. Greenlight provides the room manager front end, so plan how accounts are created and how room links are issued to participants.

BigBlueButton capacity and network planning

The main trade-off with BigBlueButton is infrastructure weight. The published 4.0 requirements call for 8 CPU cores, 500 GB of disk for recordings, UDP ports 16384 to 32768 open and 250 Mbit/s symmetrical bandwidth. Those numbers are per server, so ask your vendor or integrator how sessions scale across nodes before you size hardware. Confirm the Ubuntu 24.04 host baseline with your platform team before you order servers or virtual machines.

Element Call inside Element Server Suite Community

Element Call is the option for teams that already run or want Matrix-based chat. Element Server Suite Community bundles Element Call with Synapse under AGPL, so voice and video sit next to chat, rooms and federation in one stack. It fits organizations that want messaging and calls under one identity and audit boundary. The trade-off is that you adopt Matrix as the collaboration platform, which means a user migration and a new client habit, not just a meeting link.

Choosing among the three options

Choose by the workload, not by feature count. Jitsi covers quick meetings with the lightest migration effort, BigBlueButton covers structured sessions with recording and breakouts, and Element Call covers organizations that want chat and calls in one federated platform. Many teams run two of them side by side during a transition. Ask each candidate to demonstrate your three most common meeting types on your own hardware before committing.

Which open-source option covers each Zoom capability, and where coverage falls short

This table maps the main Zoom capabilities to Jitsi Meet, BigBlueButton and Element Call, and flags where each option needs extra work or confirmation. Read each row as a starting point for a pilot, not a finished feature match. Items marked for confirmation depend on current release documentation and your own testing.

Capability	Jitsi Meet	BigBlueButton and Element Call
Meetings and screen sharing	Browser-based meetings with screen sharing. Needs HTTPS for multimedia to work, per the self-hosting guide.	BigBlueButton covers browser meetings with screen sharing. Element Call provides Matrix-based voice and video inside Element Server Suite Community.
Breakout rooms	Confirm current support and behavior in the release you deploy before promising it to users.	BigBlueButton is built around breakout rooms for classroom use. Confirm moderator controls and limits in current documentation.
Cloud and local recording	Recording and streaming run through the optional Jibri component. Plan storage and a separate recording host.	BigBlueButton records meetings natively. Plan 500 GB of disk for recordings per the install requirements, and confirm retention settings.
Transcripts and captions	Not a core feature. Confirm whether transcription is available or plan a separate speech-to-text service.	Confirm transcription and caption support in BigBlueButton 4.0 release notes. Zoom's VTT and CC.VTT exports are a different workflow.
SIP dial-in	Optional Jigasi component provides SIP connectivity. Requires separate telephony planning.	Confirm SIP and telephony options in current documentation. Dial-in is often a gap that needs a carrier or PBX integration.
Room management	Managed through configuration and Prosody and Jicofo settings. No built-in admin console for scheduling.	Greenlight is the room manager front end for BigBlueButton. Scheduling and user management depend on how you deploy it.
On-premises deployment	Docker containers or Debian and Ubuntu packages, deployed in your infrastructure with no vendor cloud dependency.	Installed with bbb-install.sh on Ubuntu 24.04. Needs at least 16 GB memory, 8 CPU cores and UDP ports 16384 to 32768.
Vendor-managed hybrid option	Not applicable. Jitsi is self-hosted only in this model.	Not applicable. Zoom Node remains managed from the Zoom cloud, which is a different control model.

How Zoom Node differs from a fully self-hosted Jitsi or BigBlueButton deployment

Zoom Node is hardware and software you run on your own premises, but its control plane is managed from the Zoom cloud. The published product modules include Zoom Meetings Hybrid, Recording Hybrid, Meeting Connector and Recording Connector. Your team hosts the components and keeps media and recordings within your network, while Zoom operates the management layer that configures and maintains them. Before comparing options, confirm with Zoom exactly which traffic, account metadata, licensing checks and telemetry still leave your environment, which modules you would deploy, and what the vendor must do if the cloud connection is interrupted. Those answers determine whether the deployment is local in the sense your data residency rules require.

A fully self-hosted Jitsi or BigBlueButton deployment removes the vendor control plane. Your team operates the web front end, signaling, media bridging, and any recording or telephony components, whether they run as Docker containers or as packages on Ubuntu or Debian. For Jitsi, that means Prosody, Jicofo and Jitsi Videobridge, with Jibri and Jigasi added only if you need recording or SIP. For BigBlueButton, the bbb-install.sh installer brings the stack up on a single server, and the same team then owns upgrades, backups, certificates and capacity planning. The trade is simple: you gain full control over where every component and log resides, and you take on the operational duties that Zoom's cloud otherwise performs for Zoom Node.

Plan the decision around what each model keeps local. With Zoom Node, the media path and stored recordings can stay on premises, but the management dependency does not disappear. With self-hosted open source, nothing depends on a vendor cloud, yet you must staff the on-call rota and test failover yourself. Ask Zoom for the documented outage behavior of Zoom Node, and in your own environment, run a timed test of a restored server, a certificate renewal and a recording retrieval before committing to either path.

What a self-hosted Zoom replacement costs across licenses, infrastructure and skills

This table breaks the cost of moving from Zoom to a self-hosted platform into its components, marking each as one-time or recurring and naming what drives it up. Use it to structure a quote request, since no prices are given here and your own concurrent users, recording volume and bandwidth will set the real figures.

Cost component	Who is paid or who pays	One-time or recurring	Main drivers
Zoom subscription or Zoom Node license	Zoom, under your current agreement	Recurring	Licensed seats or hosts, modules such as Zoom Node hybrid components, renewal terms. Confirm with Zoom what Zoom Node licensing covers.
Open-source software license	No license fee for Jitsi Meet (Apache-2.0) or BigBlueButton (LGPL-3.0)	Not applicable	Confirm any paid hosted or support tiers offered by project maintainers or vendors separately from the software itself.
Servers and compute	Your cloud provider or data center	Recurring	Concurrent users, number of video streams, whether Jibri or BigBlueButton recording runs on the same host. BigBlueButton 4.0 documentation lists 16 GB memory and 8 CPU cores as minimums.
Bandwidth	Your network provider or cloud egress billing	Recurring	Participants per meeting and video quality. BigBlueButton documentation lists 250 Mbit/s symmetrical bandwidth as a requirement.
Recording and transcript storage	Your storage provider	Recurring, grows over time	Recording volume and retention policy. BigBlueButton documentation lists 500 GB of disk for recordings as a starting requirement.
Implementation and integration	DeployOpen or your internal team, under a written scope	One-time	Number of environments, SSO and directory integration, TLS and network design, hardening, and documentation for assessors.
Migration of recordings and transcripts	DeployOpen, your internal team or a Zoom export tool	One-time	Volume of Zoom cloud recordings, file formats (MP4, M4A, VTT, CC.VTT, TXT), and how records map to users and retention.
Support, upgrades and monitoring	Internal staff or a support retainer	Recurring	Release cadence of the chosen platform, upgrade windows, on-call coverage, and how many components you run.
Internal skills	Your staff time	Recurring, with training as one-time	Linux administration, Docker or package management, XMPP or BigBlueButton operations, and network troubleshooting for UDP media.

What teams give up when they leave Zoom and the workarounds that close the gap

Moving from Zoom to a self-hosted platform trades vendor-run conveniences for work your own team or partner must carry. The cards below cover the losses teams most often underestimate and the practical workaround for each, with the checks to run in your own environment before you commit.

Polished desktop and mobile clients

Zoom's native apps handle device quirks, audio routing and background effects with little user input. Jitsi Meet and BigBlueButton rely mainly on browser sessions, so users on locked-down laptops or older phones may hit more friction. Pilot with your real device mix, including managed browsers, and confirm which features your users expect, such as screen sharing from mobile, virtual backgrounds and noise suppression, behave acceptably in each browser you support.

Vendor-run cloud recording pipeline

Zoom processes recordings, transcripts and captions in its own cloud and hands you files on a recordings page. Self-hosted, the recording path is yours to build. Jitsi uses Jibri for recording and streaming and BigBlueButton has its own recording stack, both of which need storage sized for video and a retention policy your legal team has approved. Confirm how transcripts and captions are produced, since neither platform should be assumed to match Zoom's caption output.

Managed scaling and capacity

Zoom adds media capacity on its side, so a sudden peak rarely becomes your problem. A self-hosted video bridge does not scale itself. Plan dedicated capacity for peak concurrent participants, including bandwidth from your edge, and decide whether you will add servers or accept limits during large events. BigBlueButton 4.0 documents its minimum server and bandwidth requirements, so use those as a floor and test with load tooling before a critical event.

Reliable connectivity through NAT and firewalls

Zoom's clients fall back to relays when direct media paths fail, and that fallback is managed for you. Self-hosted deployments need you to provide it. Plan a TURN service you operate, open the required UDP media ports on your firewall and confirm that corporate proxies allow WebRTC traffic. Jitsi also requires HTTPS for multimedia to work, so certificate lifecycle becomes an operational task. Test from networks that block UDP, since those cases decide whether remote staff can join at all.

Room and identity management

Zoom provides personal meeting rooms, SSO enrollment and admin controls from one console. Jitsi and BigBlueButton have less built-in administration. BigBlueButton's Greenlight front end adds room management and user accounts on top of the server, which covers many internal use cases. Confirm how it integrates with your identity provider, how moderators are assigned and how room access is logged, because those controls are often the first audit questions.

Integrations with calendars and business tools

Zoom's marketplace connects scheduling, chat, CRM and learning tools without custom code. A self-hosted platform gives you APIs and open components rather than prebuilt connectors. Map the integrations your teams use today, decide which are essential, and budget for custom integrations or middleware for the rest. Ask whether each connector must be maintained by your team after go-live, and who will patch it when the upstream product changes.

How to move from Zoom to self-hosted video conferencing and export existing recordings

This sequence moves meetings, users and recordings from Zoom to a self-hosted platform in controlled stages, ending with an archive of past recordings that your organization owns and can search. Each step closes with a check you can verify before the next one starts.

Inventory meetings, integrations and users
Start by listing who hosts meetings, how often, and for what purpose, including webinars, classroom sessions and external calls. Record every integration that touches Zoom, such as calendar plug-ins, single sign-on, room controllers, LMS links, CRM add-ins and SIP trunks, because each one needs a replacement or a decision to retire it. Ask the Zoom administrator to export the user list and the recording inventory from the admin console. The step is done when you have a signed-off list of user groups, integrations and recording volumes, with an owner for each row.
Export existing recordings and transcripts
Download recordings from the Zoom recordings page before any licence change or account closure. Zoom saves computer and cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, so keep all of them, because each file type serves a different purpose in an archive. Store the exports in a location you control, with a naming convention that includes date, host and meeting ID. The step is done when a sample of each file type from each user group opens correctly and the file count matches the inventory from the previous step.
Map rooms, accounts and identity
Decide how each Zoom user group maps to the new platform: which people get persistent rooms, which share rooms, and which join only through invitations. Confirm how accounts will authenticate, whether through your existing identity provider or local accounts, and who administers them. For Jitsi, plan the domain name and the certificate for HTTPS, since Jitsi's self-hosting guide states that HTTPS is necessary for multimedia to work. For BigBlueButton, plan room management through Greenlight. The step is done when a mapping document is approved by the business owners of each group.
Run a pilot against defined criteria
Deploy a non-production instance of Jitsi Meet or BigBlueButton and test it with one or two user groups. Use the Jitsi self-hosting guide and the BigBlueButton 4.0 installation documentation as the baseline. For BigBlueButton 4.0, confirm the target host runs Ubuntu 24.04 and meets the stated minimums of 16 GB of memory, 8 CPU cores and 500 GB of disk for recordings, that UDP ports 16384 to 32768 are open, and that the link provides 250 Mbit/s symmetrical bandwidth. For Jitsi, confirm valid HTTPS and the components you need, such as Jibri for recording or Jigasi for SIP. The pilot is done when every criterion is documented as passed, with test results for audio, video, screen sharing and recording.
Run old and new platforms in parallel
Keep Zoom active while users host a defined share of meetings on the new platform. Track which features people depend on, such as breakout rooms, polls, waiting rooms, live captions and cloud recording, and confirm each one works or has a documented workaround. Collect feedback on call quality across the network paths your staff and external guests actually use. Confirm that recordings from the new platform are stored and retrieved correctly. The step is done when the feature gap list is closed or accepted by the business owners.
Cut over users and update integrations
Move users in the agreed groups, update calendar invitations, single sign-on settings, LMS and CRM links, and any room hardware to point at the new platform. Publish a short guide for hosts covering how to start a meeting, record it and find recordings. Keep a rollback path for the first period after cutover. The step is done when integration tests pass, the support queue shows no unresolved access problems for the cutover group, and the remaining groups have a dated plan.
Decommission Zoom and retain the archive
Once every group has moved and the archive is verified, remove Zoom licences, disable integrations and revoke API keys and service accounts. Confirm with Zoom the terms for deleting cloud recordings and account data, and make sure your exports are complete before that date. Keep the archive under your retention policy, and document where each file type is stored and who can access it. The step is done when the decommissioning checklist is signed, access reviews show no remaining Zoom credentials in use, and the archive index has been spot-checked against the original inventory.

Which Zoom alternative fits a data residency, cost or regulated workload

When the rule is that meeting media, chat and recordings must stay inside your network or a named jurisdiction, the question is where the software runs, not which vendor you buy from. Both Jitsi Meet and BigBlueButton can run entirely inside your cloud account, data center or air-gapped network, so the media path and the recording storage remain under your control. Zoom Node takes a different approach: the modules sit on your premises, but they are managed from the Zoom cloud, which is a dependency you should document in your residency analysis.

Media path: Jitsi needs a web front end, Prosody, Jicofo and Jitsi Videobridge inside your environment, and optional Jibri and Jigasi for recording and SIP.
Recording storage: BigBlueButton 4.0 expects about 500 GB of disk for recordings on the install minimums, so size storage for your retention policy.
Transport: Jitsi requires HTTPS for multimedia to work, so plan certificate issuance and renewal from the start.
Network: BigBlueButton needs UDP ports 16384 to 32768 open and 250 Mbit/s symmetrical bandwidth at the minimum profile.
Management plane: Confirm with Zoom whether any control or telemetry traffic leaves your network under Zoom Node, and get the answer in writing.

Illustrative example: a bank whose policy requires recordings of client calls to stay in its own data center would deploy BigBlueButton there and keep Jitsi for ad hoc internal calls. Check the residency position with your data protection lead before you decide.

How to pull Zoom recordings and transcripts out before a renewal date

Start by inventorying what Zoom actually holds. Zoom saves computer and cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, and each of these can be downloaded from the recordings page. Export the full set for each recording rather than only the video, because the VTT transcript and TXT chat are the files people search for later and are the hardest to recreate. Confirm with your Zoom administrator which recording types your account has enabled, since cloud and local recordings are stored and retrieved differently and an export that covers only one type will leave a gap at renewal.

Before downloading anything, plan where the archive will live. Recordings are large, so ask your administrator for the total size of the cloud recording library and compare it with the free space on your target storage, including room for backups and the self-hosted recording component you plan to use. Check retention rules in the Zoom admin settings, because automatic deletion can remove content on a schedule you do not control. Then map each recording to its host and to the business owner of the meeting, such as a team, a customer account or a training program. Hold deletion until the owners have confirmed in writing that their recordings are copied and that any legal hold or records obligation has been met.

Export paths differ by platform, so do not assume the Zoom process applies to other vendors. Microsoft Teams offers the Teams Export APIs, which return links to meeting recordings in MP4 and transcripts in VTT or DOCX, but only for meetings a given user organized. Webex has its own deployment and management model, so confirm its export options directly with the vendor before planning a Webex migration. Treat each platform as a separate inventory exercise and record, for every source, who holds an export right and what the file formats are.

What a Zoom replacement costs, how long it takes and what it needs from your team

What does it cost to replace Zoom with open-source software?

The software licence is free for Jitsi Meet and BigBlueButton, so the cost sits in infrastructure, people and support. Cost has four components: servers or cloud instances, bandwidth, staff time to install and operate the platform, and external help if you buy it. Infrastructure is recurring, while design, installation, integration with your identity provider and hardening are largely one-time. BigBlueButton 4.0 documentation lists at least 16 GB of memory, 8 CPU cores, 500 GB of disk for recordings and 250 Mbit/s symmetrical bandwidth per server, so recording volume and concurrent meetings drive the bill most. Ask any quote to separate one-time and recurring costs.

How long does a Zoom migration take?

No researched timeline applies to every organization, so confirm the duration against your own scope. The main drivers are the number of platforms in use, whether recordings must move, how many user groups need single sign-on, the network and firewall approvals required for UDP media, and how much testing your compliance team expects. A pilot with one department usually moves faster than a company-wide cutover because it surfaces firewall and browser issues early. Ask the provider for a schedule with milestones tied to written acceptance tests.

What does my team need to supply for a self-hosted video platform?

Your team supplies the environment, the access and the decisions. Expect to provide a cloud account or data center capacity, DNS names and TLS certificates, because Jitsi's self-hosting guide states that HTTPS is necessary for multimedia to work. You also need firewall changes for the media ports, such as UDP 16384 to 32768 for BigBlueButton 4.0, an identity provider for sign-in, storage and backup policy for recordings, and a named owner for patching. Agree who approves changes before work starts.

Can we self-host Jitsi or BigBlueButton without outside help?

Yes, if your engineers can run Linux servers, containers and reverse proxies, and have time to operate them. Jitsi can be deployed with Docker containers or Debian and Ubuntu packages, and BigBlueButton installs with its bbb-install.sh script on Ubuntu 24.04. The harder work is ongoing: upgrades, monitoring, capacity planning, recording storage, backups and incident response. Decide whether your team will own those tasks for the life of the platform, because an internal-only plan that lacks an on-call owner tends to fail first on operations.

How do I export existing Zoom recordings and transcripts?

Download them from the Zoom recordings page, where cloud and computer recordings can be saved as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files. Check that each meeting's recordings are available before any retention period ends, and confirm with your Zoom administrator that you have the rights to export recordings for every user. Store the files in a location with access controls, record where each file came from, and keep a manifest so you can verify the migrated set against the source. Confirm your Zoom plan's retention settings with your administrator, because they determine how much history is still available.

What should I ask for in a fixed-scope quote for a video platform migration?

Ask for a written scope that lists platforms, environments, user counts, integrations, recording and transcript volume, and the acceptance tests that close the work. The quote should separate one-time work from recurring support, name the deliverables such as runbooks and backup tests, and state what the client must supply. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers, and DeployOpen does not publish a price list, so a quote follows from the written scope.

Which compliance evidence should a Zoom replacement produce?

The platform should produce evidence that access is controlled, changes are recorded, backups restore, and recordings are stored and deleted according to policy. Ask your auditors which controls they will test, then map each to a configuration, log source or test result. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. Confirm the exact evidence list with your auditor before implementation begins.

How to decide between Jitsi Meet, BigBlueButton and Element Call

The first decision is the primary use. Jitsi Meet suits ad hoc meetings where people join from a link, with the web front end, Prosody, Jicofo and Jitsi Videobridge carrying the load. BigBlueButton is built for classes and recorded sessions, with polls, breakout rooms and a shared whiteboard, and it is the stronger fit when a teaching or training workflow is the main requirement. Element Call fits organizations that already run or plan to run Matrix, where voice and video sit alongside chat and identity. Settle this question first, because the other criteria follow from it.

Next, check server resources and recording needs. BigBlueButton 4.0 installs with bbb-install.sh on Ubuntu 24.04 and needs 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. Jitsi recording runs through the optional Jibri component, and Jibri adds its own hosts and capacity planning. Ask how many concurrent participants and recorded hours you expect, then confirm the sizing with each vendor or project before you commit hardware. Also confirm SIP needs: Jigasi is the optional Jitsi component for SIP dial-in, and dial-in requirements often decide the choice for telephony-heavy organizations.

Then decide whether chat and federation matter, and check free-tier limits. If users need persistent chat that federates with other organizations, Matrix with Element Call is the relevant path, and Element Server Suite Community includes Element Call under AGPL. Mattermost Entry, the free commercial tier, limits calls to 40 minutes, which shows why you should verify any free tier's call length, participant cap and feature gates against current documentation. For a pilot, run one ad hoc meeting scenario on Jitsi Meet and one recorded class scenario on BigBlueButton, with HTTPS in place from the start, since Jitsi's guide notes HTTPS is necessary for multimedia to work. Measure bandwidth, recording storage and recording retrieval before you widen the pilot.

How DeployOpen scopes, migrates, hardens and supports your Zoom replacement

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source video platforms inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory current Zoom usage, including meeting types, hosts, recording volumes, SIP or room integrations and retention needs.
Confirm where media, recordings and transcripts must reside under your data residency and access rules.
Agree in writing which platform, hosting model, integrations and deliverables are in and out of scope.

How we build

Deploy the chosen platform, such as Jitsi Meet or BigBlueButton, in your environment with HTTPS and firewall rules configured.
Test call quality, screen sharing, recording and network traversal with your actual user groups before cutover.
Document configuration, sizing and the security controls applied so your team can review them independently.

How we hand over

Migrate existing recordings and transcripts from Zoom into your chosen storage, with an agreed inventory of what moved.
Deliver runbooks for administration, backup, upgrades and incident response to your operations staff.
Prepare control evidence and documentation for your own compliance assessment, which independent auditors perform, not DeployOpen.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover platform patching, backup verification and capacity reviews agreed in the written scope.
Ask any provider to confirm which platform versions, licenses and hosting costs your quote includes.