Migrate from Zoom to BigBlueButton: what the move involves
A team running training, classes or webinars on Zoom that wants self-hosted control should plan for a platform build plus data and integration work, not a meeting-link swap. Replacing Zoom with BigBlueButton means provisioning servers, opening the right network paths, wiring BigBlueButton into the learning management system or portal where people join, and deciding how recordings and historical content are kept. Usually the platform or infrastructure team owns the servers and networking, the security team owns certificates, identity, API secrets and access rules, and the LMS or training owner owns course links, roles and the cutover for learners and instructors.
Effort and risk concentrate in three places: server capacity, network reachability and integrations. A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings and 250 Mbit/s symmetrical bandwidth, and it needs TCP ports 80 and 443 plus UDP ports 16384 to 32768 reachable. Confirm these against your expected class sizes and concurrent sessions before anything is ordered. BigBlueButton 4.0 also does not support direct upgrades from 2.6, 2.7 or 3.0, so plan a clean server installation rather than an in-place upgrade of an existing test box. Ask whoever will run the deployment to confirm the supported Ubuntu release and the current installation steps in the BigBlueButton install documentation before scheduling work.
Treat the Zoom exit as a project with its own inventory. Recordings, transcripts and captions should be downloaded and archived before any Zoom license ends, and the scheduling, roles and LMS links that depend on Zoom must be rebuilt by hand. Run a pilot with a small set of courses or sessions, test join behavior from the networks your learners actually use, and confirm with your security team how BigBlueButton API secrets and identity sign-in will be handled before you widen access. Ask your implementation partner for a written scope that names each of these items, who signs off on each, and what acceptance testing will cover.
Which Zoom capabilities map to BigBlueButton, and which need rework
This table maps the Zoom capabilities that training, class and webinar teams use most to their BigBlueButton equivalents. Each row is marked clean, needs rework or gap, so you can see where sessions move over as they are and where content, process or extra tooling changes. Confirm each feature against the BigBlueButton version you plan to run, because capabilities differ between releases.
| Zoom capability | BigBlueButton equivalent | Status |
|---|---|---|
| Meetings and audio or video sessions | Core virtual classroom with audio, webcam video and chat in a room | Clean |
| Breakout rooms | Built-in breakout rooms set up by the moderator during a session | Needs rework |
| Polling | Built-in polls for presenters, with results kept in the session | Needs rework |
| Whiteboard and annotation | Multi-user whiteboard and slide annotation, which replaces Zoom's shared whiteboard | Needs rework |
| Screen sharing | Desktop and application screen sharing from the browser | Clean |
| Cloud recording and transcripts | Built-in recordings stored on the server; Zoom's transcript and caption files need a separate tool | Needs rework |
| LMS embedding | Integration with Canvas, Moodle and other LMSs; confirm the connector for your LMS version | Needs rework |
| Scheduling and room links | Persistent rooms through Greenlight; calendar invitations need your own process or LMS | Needs rework |
| Admin controls and user management | Server-level settings and room management; SSO requires an external identity provider | Gap |
| Webinar registration and Q&A | Not provided as a registration or large-audience Q&A product; use other tools | Gap |
| Large-audience streaming | Depends on server capacity and streaming setup; plan capacity before committing | Gap |
What BigBlueButton 4.0 needs in servers and bandwidth
Plan for a dedicated server with at least 16 GB of RAM plus swap, 8 CPU cores with high single-thread performance, and 500 GB of disk for recordings. The published BigBlueButton 4.0 install documentation gives 50 GB as the disk figure when recording is switched off, so the storage decision drives most of the disk sizing. The server runs on Ubuntu 24.04 64-bit, and the bbb-install.sh script is the supported installation path. Before you order hardware or a cloud instance, confirm these figures against the current install page, because the documentation is the authority for each release.
Network planning matters as much as the machine itself. The documentation asks for 250 Mbit/s of symmetrical bandwidth, so upload and download must be equal, not just a fast download link. The server needs TCP ports 80 and 443 reachable for the web interface, and UDP ports 16384 to 32768 for media. Firewall rules, load balancers and cloud security groups must allow these ports end to end. A valid hostname with a working SSL certificate is also required, so reserve a DNS name before installation. Docker is needed for sandboxed LibreOffice document conversion. Ask your network team whether users sit behind restrictive corporate or school firewalls, because those users may only reach the platform through a TURN server, which the documentation recommends deploying alongside the server.
Do not treat a current BigBlueButton 2.x or 3.0 server as a candidate for an in-place upgrade. The install documentation states that direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server for 4.0 and migrate configuration, branding, users and integrations by hand. Build the new server in a staging environment, test it with a pilot class, and keep the old system running until recordings and LMS links have been verified. Ask your vendor or internal team to confirm the upgrade path that applies to your existing version before you schedule any cutover.
Which Zoom data and integrations to export and rebuild
Moving training and classes off Zoom takes more than moving video. Recordings and transcripts have documented export paths, while LMS links, meeting schedules, user accounts and sign-in settings must be recreated in the new environment. Work through these cards before cutting over so nothing is lost when Zoom access ends.
Cloud recording files
Zoom saves cloud recordings as MP4 video and M4A audio, and they download from the recordings page. Export every course session you must keep, and record which files belong to which course and date, because the recording store will not carry those links across for you. Check your retention rules before you download, since the copies you need for records may sit in a different place from the ones learners watch. Plan storage for these files on the BigBlueButton server or an archive, since its 500 GB recording disk is sized for new sessions only.
Chat, transcripts and captions
Each cloud recording can also include TXT chat, VTT transcript and CC.VTT caption files. Chat logs often hold questions and answers that instructors reference later, so export them with the video rather than treating them as optional. Confirm with your accessibility lead that the caption files meet your requirements, because captions you export from Zoom will not be regenerated by BigBlueButton automatically.
LMS course links and embeds
Zoom links placed in Canvas, Moodle, D2L or Schoology courses will break once Zoom is retired. Inventory every course page, module and announcement that points to a Zoom meeting or recording, then decide which BigBlueButton room or LMS-embedded session replaces each one. BigBlueButton is embedded in these LMSs, so confirm which integration path your LMS version uses before you rebuild links in bulk.
Scheduled meetings and calendars
No supplied source confirms that Zoom meeting schedules can be bulk transferred into BigBlueButton, so treat recurring class schedules and calendar invitations as manual work until a vendor confirms otherwise. Ask Zoom which schedule and invitation data can be exported in your plan, and ask BigBlueButton or your integrator how rooms and recurring sessions should be created. Keep a spreadsheet of each session time, host, and attendee group in the meantime.
User accounts and sign-in
Learners and instructors need accounts in the new system, and Zoom accounts do not move across. Greenlight v3 supports external authentication through OpenID Connect, configured with environment variables, and the docs suggest Keycloak to add Google, Microsoft and SAML login methods. Decide which identity source is authoritative, map roles such as host and moderator, and test each login path with a pilot group before you retire Zoom logins.
Admin settings and integrations
Zoom admin policies, such as waiting rooms, recording permissions and domain restrictions, along with any SSO or calendar connectors, must be documented and rebuilt by hand. Record each setting, its owner and the reason it exists, then set the equivalent on the BigBlueButton server, Greenlight and the identity provider. Keep API secrets out of web pages, since BigBlueButton API calls require a checksum built with a shared secret.
The migration sequence from inventory to decommission
This sequence moves Zoom training, classes and webinars to BigBlueButton in five controlled phases, so each session type is proven on a clean server before Zoom is switched off. Each phase ends with a written output that the next phase depends on.
Inventory courses, classes, webinars and recordings
Start by listing every recurring session on Zoom: which courses or teams use it, which LMS pages link to meetings, which webinars run on a schedule, and which users host. Record the hosting accounts, the recording and transcript files in the cloud, and the chat, caption and attendance exports each team relies on. Ask the Zoom administrator to confirm the account list and the recording retention settings in writing. The output is a single inventory sheet with one row per session type, its owner, its LMS or web link location, and its archive status. The step is done when the course owners have signed off on their rows.
Pilot on a clean BigBlueButton 4.0 server
Install BigBlueButton 4.0 on a fresh Ubuntu 24.04 server using bbb-install.sh, since direct upgrades from earlier branches are not supported. Check that the host meets the published specification: at least 16 GB of RAM with swap, 8 CPU cores, 500 GB of disk if recording is kept, and 250 Mbit/s symmetrical bandwidth. Confirm TCP ports 80 and 443, UDP ports 16384 to 32768, a valid hostname with SSL, and a TURN server for users behind restrictive firewalls. Connect one LMS course to the server, then run a test session with a pilot group that includes students on home networks. The output is a signed test record covering join, audio, video, screen share, recording playback and the LMS launch.
Run Zoom and BigBlueButton in parallel
Keep Zoom active for sessions already in progress and for any course not yet moved, and move new cohorts or term-based classes to BigBlueButton first. Give facilitators a short guide covering the whiteboard, shared notes, polling and breakout rooms, since these replace features they may use on Zoom. Track each session in the inventory with its platform, attendance, audio or connection issues and any recording problems. Review the log with course owners at fixed points, so that gaps appear while Zoom is still available. The output is a parallel-run log that shows which session types work reliably and which still need changes.
Cut over scheduled sessions and LMS links
Move each remaining session type in the order set by the inventory, starting with those that the pilot proved. Update the LMS links, calendar invitations and Greenlight room links so that students reach the BigBlueButton room without searching for a new address. Set the Zoom meeting pages to point to the new rooms, and tell registered participants about the change in advance. Confirm that each LMS launch opens the correct room and that the instructor can start and end the session. The output is a cutover checklist per course, signed by the course owner, with no scheduled Zoom sessions left for the migrated courses.
Archive and verify Zoom recordings before decommission
Download every cloud recording that must be kept, including the MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files that Zoom saves for each recording. Store them on your own storage with a folder structure that matches the inventory, and keep the BigBlueButton recordings on the same server or storage plan you sized earlier. Open a sample from each session type to confirm playback, captions and transcripts, and compare file counts against the Zoom list. Ask your records or compliance owner to approve the retention rules for the archive before any deletion. The output is a verified archive index that maps every Zoom recording to its new storage location.
Decommission Zoom after archive verification
Once the archive index is approved, disable scheduled Zoom meetings and webinars, remove the LMS links to Zoom, and revoke licenses for users who no longer need them. Document the Zoom settings, integrations and admin roles that were in use, so they are known to the team after the account closes. Confirm with your Zoom administrator and contract owner when the subscription ends and how the account data is handled under your agreement. The output is a closed decommission record that lists the archive location, the approval date, the revoked accounts and the retained documentation.
How the move differs for teaching, training and webinars
Where classes already run from Canvas, Moodle, Sakai, D2L or Schoology, BigBlueButton is usually embedded in the course rather than opened as a separate site. Instructors create a session from the course page, learners join with their course login, and attendance and recordings sit next to the course materials. The BigBlueButton project states that these LMSs represent over 75% of the worldwide LMS market, which is a reason to check the integration path for your exact LMS version before planning.
- Integration method: Confirm whether your LMS uses the built-in BigBlueButton integration or LTI, and whether that is supported on the BigBlueButton version you plan to run.
- Server placement: The
bbb-install.shscript can install LTI support on the same server, which simplifies a small deployment but adds load to it. - Course migration: Zoom links embedded in old course pages will break, so inventory every course that references a Zoom meeting.
- Permissions: Map instructor, teaching assistant and learner roles in the LMS to moderator and viewer roles in BigBlueButton.
- Recordings: Decide whether session recordings are attached to courses automatically and how long they are kept.
Before committing, test one course end to end with a real instructor and a learner account on the same network conditions your students use.
Corporate training usually runs on standing rooms that trainers reuse across cohorts. Greenlight is BigBlueButton's room manager front end, and Greenlight v3 supports external sign-in through OpenID Connect, configured with environment variables. The Greenlight documentation suggests Keycloak to add Google, Microsoft, SAML and other login methods, which lets a training team sign in with the company directory rather than maintaining local accounts.
- Persistent rooms: Create one Greenlight room per trainer or course so links and materials stay stable between cohorts.
- Directory sign-in: Connect Greenlight to your identity provider through OpenID Connect, and plan Keycloak if you need SAML or other methods.
- Access control: Decide which rooms are open to any signed-in user and which require an invitation.
- Learner experience: Test polling, shared notes and breakout rooms with the groups that will use them, since these replace features many teams rely on in Zoom.
- Scale: Plan for concurrent cohorts, because each BigBlueButton server has finite capacity.
Confirm the exact Greenlight and Keycloak configuration keys against the current documentation for your release, and test the sign-in flow with a non-administrator account.
Presenter-led sessions fit BigBlueButton's model: a small set of presenters share slides, screens and polls, and attendees mostly listen and use chat. BigBlueButton does not provide registration pages, event ticketing or large-audience broadcast features in the way Zoom Webinars does, so those functions must come from other tools. Teams should separate the meeting engine from the surrounding event workflow before choosing a design.
- Registration: Use a separate form or event tool to collect registrations and send join links.
- Q&A: Decide whether questions come through chat, a form, or a moderated tool, and train moderators before the session.
- Audience size: Test the number of attendees you expect, since large audiences need more server capacity and bandwidth than a classroom.
- Pooling servers: Scalelite is a project that pools several BigBlueButton servers behind one entry point, which can spread load across events.
- Recording: Confirm where presenter sessions are stored and who can download them.
Run a rehearsal with the number of attendees and the registration flow you plan to use, and confirm Scalelite's current setup steps before relying on it for live events.
What drives the cost and duration of the move
This table lists the factors that change what a Zoom to BigBlueButton move costs and how long it takes, and how to keep each one manageable. No price or duration is given here, so use the rows to scope a written quote.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| LMS integrations | Each LMS (for example Canvas, Moodle, D2L or Schoology) needs its own integration setup, testing and user-facing instructions, and each adds scope to the quote. | Start with the one or two platforms that carry most classes, and confirm which integration path each LMS version supports before scoping. |
| Recording volume and archive size | Zoom cloud recordings must be exported and stored, and the BigBlueButton server needs roughly 500 GB of disk for recordings (50 GB without recording) according to the install docs. | Inventory recordings by age and course, archive old material first, and agree a retention rule before migration starts. |
| Concurrency and server count | Peak concurrent classes set how many 16 GB, 8-core servers with 250 Mbit/s symmetrical bandwidth are needed, and scaling out adds pooling work such as Scalelite. | Measure real peak sessions from Zoom usage reports, then size for that peak with a clear plan to add servers later. |
| Identity integration | Connecting Greenlight to an identity provider through OpenID Connect, often via Keycloak, adds configuration, group mapping and testing. | Decide early whether login uses the LMS, an existing directory or local accounts, and keep the first rollout to one method. |
| TURN and firewall work | BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768 open, a valid hostname for SSL, and a TURN server is recommended for users behind restrictive firewalls. | Ask the network team to review firewall rules and proxies before installation, and test from the networks students and staff actually use. |
| Operations staff | Someone must patch, back up, monitor and upgrade the servers. Upgrading from 2.6, 2.7 or 3.0 to 4.0 requires a clean install, so migration plans need that step. | Assign named owners for patching and backups, document the runbook, and ask the vendor or partner what support is included in any retainer. |
What usually goes wrong when moving to BigBlueButton
Most failed BigBlueButton moves come from a handful of decisions made early, such as server sizing, network ports and how recordings are handled. The cards below cover the risks that tend to surface during a Zoom cutover and the check to run before each one causes a problem.
Undersized production servers
A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth. Teams often pilot on a small test machine and then run a full class of participants on the same specification. Load test with a session that matches your largest real class or training cohort, and confirm the sizing before the first live date.
Blocked UDP media ports
Audio and video travel over UDP ports 16384 to 32768, and TCP ports 80 and 443 must also be reachable. Corporate and campus firewalls often allow HTTPS but block UDP, so users connect, see slides, and then hear nothing. Open the UDP range on the server and on every edge firewall, and plan a TURN server for users behind restrictive networks.
Missing HTTPS hostname
BigBlueButton needs a valid hostname with an SSL certificate that browsers trust, because browsers block microphone and camera access on plain HTTP. A server reached only by IP address or with a self-signed certificate will load but fail at the device prompt. Register the hostname in DNS, issue the certificate before installation, and test from a managed student or employee laptop.
In-place upgrade instead of clean install
BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a server running an earlier release cannot be moved forward in place. Teams that try this often end with a broken recording pipeline or a Greenlight database mismatch. Build a new Ubuntu 24.04 server with bbb-install.sh, migrate content and room settings deliberately, and keep the old server running until cutover is verified.
Zoom recordings lost before download
Zoom cloud recordings are removed after the retention period set by your account, and deleted files cannot be recovered from Zoom. Teams that plan the cutover without an inventory often discover archive gaps after licenses lapse. Export MP4 video, M4A audio, chat, VTT transcripts and captions for every course or series, store them in your own storage, and verify file counts against the Zoom recordings list before cancelling.
Shared API secret exposed in a web page
Every BigBlueButton API call carries a checksum built from a secret shared with the server, and anyone who holds that secret can create or end meetings. Integrations that call the API from browser code leak the secret to every visitor. Keep the secret on the LMS or application server, never in front-end JavaScript, and rotate it after any integration change or staff departure.
LMS links breaking at cutover
Course pages in Canvas, Moodle or another LMS often hold meeting links, LTI launch settings and recording references that point to Zoom. When the cutover date arrives, instructors find dead links in old modules and scheduled sessions that still open the Zoom host. Inventory every course with a Zoom link, update the LTI configuration and calendar entries in a pilot course first, and run a dry-run session with one instructor before the term starts.
Questions buyers ask before moving from Zoom to BigBlueButton
How much does it cost to move from Zoom to BigBlueButton?
There is no BigBlueButton license fee, so the cost is what you pay for servers, bandwidth, storage, staff time and implementation. The main recurring costs are the server hosting or hardware, outbound bandwidth, disk for recordings and the staff who patch and support the platform. One-time costs cover the initial build, LMS integration, SSO and user rollout. The BigBlueButton 4.0 install documentation lists a minimum server of at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Ask any quote to separate hardware or hosting, bandwidth, storage, implementation and ongoing support, and to state how many concurrent sessions each server is sized for.
How long does a Zoom to BigBlueButton migration take?
The timeline depends on the number of LMS integrations, the number of users and sessions, how many recordings you must move, and whether you need SSO or a dedicated test environment. Most of the variation comes from the integration and rollout work rather than the server install itself. BigBlueButton 4.0 is installed on a clean Ubuntu 24.04 server, because direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a fresh build and a parallel run with Zoom. Your timeline should be written into a fixed-scope plan that lists each deliverable before work starts.
What does the organization need to provide for the move?
You need the server capacity, network access and people to run the platform. Infrastructure needs public DNS for a valid hostname, TCP ports 80 and 443 and UDP ports 16384 to 32768 reachable, and a TURN server is recommended for users behind restrictive firewalls. Docker is required for sandboxed document conversion. On the people side, you need an owner for the LMS integration, a contact who can approve SSO and identity settings, and instructors who can test sessions. Confirm with your network team that the 250 Mbit/s symmetrical link is available at each site where sessions will run.
Can our internal IT team do the migration alone?
An internal team can do it if it already runs Linux servers, reverse proxies, certificates and LMS administration, and if it has time to test under real class load. The install script can set up BigBlueButton together with Greenlight or LTI support on one server, which keeps the first build simple. The harder parts are sizing for peak sessions, LMS integration, recording storage, TURN and firewall rules, and ongoing patching of a multi-service stack. If those skills are missing, a fixed-scope engagement from DeployOpen can plan, implement, integrate, harden, document and hand over the platform inside your own infrastructure, and a retainer can cover upgrades and support afterward.
How long should we keep Zoom running in parallel?
Keep Zoom running until every recurring meeting, class and webinar type has a tested BigBlueButton path, every needed recording has been exported, and staff have been trained on the new room and LMS flow. The overlap period is set by your contract terms with Zoom, your academic or training calendar, and how long it takes to confirm that sessions run reliably at peak load. Check your Zoom renewal date early, because it determines how much parallel running you can afford. Avoid switching during a term or a major training cycle.
What happens to our old Zoom recordings and transcripts?
Zoom does not move recordings for you, so you must download them before your Zoom access ends. Zoom saves cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files that you can download from the recordings page. Store them in your own archive with a clear folder structure that maps to courses or programs, and check retention rules before deletion. BigBlueButton records its own sessions, so old Zoom content will not appear in its recording library unless you upload it to a separate repository or LMS. Confirm your retention and access rules with your records and compliance owners.
Does BigBlueButton replace Zoom Webinars?
BigBlueButton covers presenter-led sessions, classes and training with slides, whiteboard, polling, breakout rooms and chat, but it is not a drop-in replacement for Zoom Webinars at large audience sizes. Webinar needs such as registration pages, large-audience streaming, Q&A moderation and analytics usually come from other tools that you must select and integrate. Server capacity for large audiences is a separate sizing exercise, and the pooling option Scalelite is one way to spread sessions across several servers. Before deciding, list your largest expected audience, registration flow and reporting needs, and confirm each with the platform owner.
Is BigBlueButton secure enough for our sessions?
Security depends on how you deploy and operate it. BigBlueButton requires a valid hostname for SSL, and every API call must carry a checksum computed with a secret shared with the server, using SHA-256 by default and SHA-384 or SHA-512 since version 2.5. The API documentation warns never to embed the shared secret in a web page, so the LMS integration must generate checksums on the server side. For user login, Greenlight v3 supports external authentication through OpenID Connect, and the docs suggest Keycloak to add other login methods. Review these settings with your security team and confirm them against your own policy.
How DeployOpen scopes and runs a Zoom to BigBlueButton migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Zoom to BigBlueButton, we start with the training, class and webinar workflows you run today, then agree a written scope before any server is built.
How we scope
- We inventory which Zoom sessions, LMS links, recurring rooms and webinars move to BigBlueButton and which stay on Zoom.
- We confirm server sizing against the 16 GB RAM, 8-core and 250 Mbit/s symmetrical bandwidth requirements for your expected concurrency.
- We agree in writing how existing Zoom recordings, transcripts and captions are exported, stored and retained before migration starts.
How we build
- We install BigBlueButton 4.0 on a clean Ubuntu 24.04 server, since direct upgrades from earlier branches are not supported.
- We configure HTTPS with a valid hostname, UDP ports 16384 to 32768, a TURN server for restrictive networks and Greenlight rooms for presenters.
- We connect your LMS, such as Moodle or Canvas, and test sign-in through external authentication where your policy requires it.
How we hand over
- We deliver documentation covering installation, room and user administration, recording storage, backup and restore procedures.
- We run test sessions with instructors and moderators, covering whiteboard, polling, breakout rooms and recording playback before rollout.
- We provide a runbook for upgrades, checksum secret handling and capacity changes, so your team can operate the platform after handover.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, and you should confirm the terms in your quote.
- Ask for a quote based on the written scope, which should separate one-time setup from recurring hosting, bandwidth and support costs.
