What a BigBlueButton migration involves
Most BigBlueButton migrations fall into one of three situations, and each one is a planned cutover with its own data and access questions. The first is a clean-install move to 4.0. BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so an existing server is replaced with a fresh one rather than updated in place. The second is carrying Greenlight rooms and recordings across to the new server. The third is moving classes that currently run on Zoom or Teams onto self-hosted BigBlueButton, which usually means rebuilding meeting links, LMS placements and user access rather than moving any stored data.
Each situation raises different questions. A clean install forces you to decide what stays on the old server until the new one is verified, how DNS and the valid SSL hostname switch over, and whether recordings are copied or left on a read-only archive. Greenlight migration depends on which Greenlight version holds the rooms and how user accounts map to the new sign-in method. Zoom or Teams moves depend on who owns the meeting schedules, which calendars and LMS course shells must be updated, and what happens to recordings stored in the old platform. Confirm each of these with your own data owners before choosing a date.
In-house teams usually handle a migration when they already run Linux servers, have someone comfortable with the BigBlueButton install script and reverse proxy settings, and can schedule a short parallel run with the old service. Teams bring in a partner when the cutover touches many LMS integrations, when recording archives are large or subject to retention rules, or when the change must be completed in a fixed window with written acceptance criteria. Ask any partner to show how they will verify the new server before users are moved.
What the migration work includes
A BigBlueButton migration splits into six work packages, each with a defined output. The handover at the end is what your team keeps after the partner leaves, so confirm each deliverable is in the written scope.
Current environment inventory
The inventory records the existing BigBlueButton version, hosting layout, Greenlight or LMS connections, custom branding, recording volume and any load balancing. It also lists which users, rooms and integrations depend on each part. Ask for this inventory as a named deliverable, since it sets the scope for every later package.
New Ubuntu 24.04 server build
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so the work builds a clean server rather than modifying the old one. The build checks memory, CPU, disk, bandwidth, open TCP and UDP media ports, a valid SSL hostname and Docker for document conversion before installation.
Greenlight or LMS reconnection
Each front end, whether Greenlight or an LMS such as Canvas or Moodle, must be pointed at the new server with the correct URL and shared secret. Checks cover sign-in, meeting creation, join links and recording playback from each integration. Confirm which integrations your current setup uses before estimating this package.
Room and recording transfer
Greenlight room settings and recordings can be carried over where the tooling supports it, while other data may need to stay on the old server. The package defines exactly which rooms, recordings and settings move, and records what cannot be transferred. Ask the partner to confirm the transfer method for your version pair before work starts.
Cutover and rollback planning
The cutover plan sets the sequence for DNS or LMS endpoint changes, freezing new meetings, validating the new server and keeping the old server available for return. The rollback plan states the trigger conditions and the steps to restore the previous service. Ask who holds authority to call a rollback during the window.
User and instructor communication
Instructors and students need notice of the new join URLs, any changed login steps, recording access rules and the planned service window. The package drafts these messages, agrees the timing with your communications owner and covers the support path for questions after cutover. Confirm who sends the messages and who answers them.
What drives migration cost and duration
This table lists the migration drivers that change effort, how to keep each one under control, and what to put in a written quote.
| Driver | Why it changes effort | How to keep it down | Put in the written quote |
|---|---|---|---|
| LMS instances and courses | Each instance needs its own API secret, endpoint and test. Every course that embeds room links must be re-linked. | Retire inactive courses before the move. Agree which courses carry over and which start clean. | Number of instances, courses in scope, and who re-links embedded rooms. |
| Recording volume and format | Recordings must be copied, converted or indexed. Large archives in mixed formats take longer to validate and move. | Set a retention cut-off and move only recordings still needed. Confirm the 500 GB recording disk figure before sizing. | Total hours or size, source formats, target storage, and checksum validation of copied files. |
| Greenlight rooms and users | Each room needs a mapped owner, name and access setting. User accounts must match the new identity source. | Export only active rooms and map owners in a spreadsheet. Remove duplicate or dormant accounts before import. | Room and user counts, mapping rules, and who signs off the mapping. |
| Identity sources to reconnect | Greenlight v3 external login is configured through OpenID Connect settings. Each extra provider adds testing and failure cases. | Limit login methods to those in use. Route Google, Microsoft or SAML logins through one bridge such as Keycloak. | Each login method to connect, the bridge component, and test accounts for each. |
| Test, staging and production | Each environment needs its own server, hostname, certificates and LMS registration. Cutover is tested in each one. | Keep one clean test build as the template. Use the same install script and configuration in every environment. | Number of environments, servers per environment, and whether test data is migrated or reset. |
| Firewall and TURN changes | TCP 80 and 443 and UDP 16384 to 32768 must be reachable. A TURN server is recommended for restrictive networks. | Request all firewall rules in one change window. Reuse the existing TURN service if it meets the port and sizing needs. | Firewall change requests, TURN server work, and who coordinates with the network team. |
| Zoom or Teams content | Exported files need conversion and storage. Referenced links stay in the old platform and need a retirement plan. | Decide per course whether to export, reference or drop content. Export only what teachers will reuse. | Export scope per course, conversion work, the export method confirmed with the vendor, and who contacts teachers about old links. |
How the migration is delivered
The sequence moves a BigBlueButton service from inventory to verified production, with a defined rollback point at cutover, and durations for each phase are set in the written scope.
Discover and inventory the current service
Catalog every room, recording, LMS launch point, identity source, and bandwidth and port dependency on the current tool, whether Greenlight, Zoom or Teams. Your team and DeployOpen review the list together. The step closes with a signed inventory that marks each item as moving, retiring or needing a decision.
Design the 4.0 target and check sizing
Design the target against the 4.0 requirements: Ubuntu 24.04 64-bit, at least 16 GB RAM with swap, 8 CPU cores with high single-thread performance, 500 GB disk with recording (50 GB without), and 250 Mbit/s symmetrical bandwidth. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so the target is a clean install. The output is an approved design and sizing note.
Build and test in a non-production environment
Install BigBlueButton 4.0 on a non-production host using the install script, adding Greenlight or LTI support where in scope. Configure API shared secrets, Greenlight v3 OpenID Connect sign-in if required, and Scalelite if a server pool is needed. Test audio, video, screen sharing, breakout rooms and LMS launches. The output is a test report with open defects logged.
Rehearse data and integration migration
Run the migration of recordings, Greenlight rooms, LMS links and scheduled classes against a copy of the source data. Confirm with the vendor and your own tests which items move cleanly and which must be recreated, since each source tool exports data differently. Measure transfer time and resolve checksum or link failures. The output is a rehearsal log and a validated runbook.
Cut over with a defined rollback point
Freeze changes on the source, then switch DNS records or LMS endpoints to the new servers within the agreed window. Record the rollback point before switching, including the previous DNS values and confirmation that the source service remains available. If checks fail, the rollback point defines what is restored. The output is a cutover record signed by the service owner.
Verify production and hand over
Repeat the rehearsal checks against live endpoints: join flows from each LMS, recording playback, TLS certificate validity, firewall reachability on the required TCP and UDP ports, and call quality with real users. Document the configuration, runbook and monitoring. Operations transfer to your team under the support terms in the written scope. The output is a verification report and handover pack.
What teams keep in-house and what they outsource
This table shows which parts of a BigBlueButton 4.0 migration usually stay with the client's own staff and which are often handed to an implementation partner, with the skills each part needs.
| Work item | Usually kept in-house | Often outsourced |
|---|---|---|
| Which courses, rooms and recordings move | Decides which Greenlight rooms, LMS courses and recordings are kept, archived or retired, since only staff know which classes are still active | Helps build an inventory script or report that lists rooms and recordings from the existing tool so the decision has data behind it |
| Communication to instructors and students | Owns the schedule, notices and support channel, and knows which departments depend on sessions during term | Provides draft guides for joining a session on the new service and training material for instructors |
| Server build on Ubuntu 24.04 | Approves the hosting location, cloud account and change window | Installs and configures the BigBlueButton 4.0 server on a clean host, with Linux administration, Docker and DNS and SSL setup |
| Host hardening | Sets security baseline, owns firewall policy and exception approval | Applies host hardening and firewall rules for TCP 80 and 443 and UDP 16384 to 32768, with network firewall and Linux administration skills |
| Identity and sign-in integration | Chooses the identity source and approves who may create rooms and host sessions | Configures Greenlight v3 OpenID Connect or LMS integration, with identity administration and LMS administration skills |
| Data transfer scripts | Validates that transferred recordings and room data match what the business expects to keep | Writes and runs transfer scripts for recordings and room settings, with scripting and LMS administration skills |
| Rehearsal and rollback testing | Runs acceptance tests with instructors and confirms a test class can be joined from each LMS | Runs repeated rehearsals of the cutover and documents rollback steps, with Linux administration and LMS administration skills |
| Cutover sign-off | Gives the final go or no-go decision and owns the communication after cutover | Prepares the runbook, monitoring checks and rollback plan that the sign-off decision relies on |
What usually goes wrong and how to prevent it
Most failures come from treating the move as an upgrade, when it is a new deployment that must carry rooms, recordings and classroom links across. Each card names the failure, the prevention step and the check that shows the step worked.
Attempting an in-place upgrade
BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, and the install docs recommend a clean installation on Ubuntu 24.04 64-bit. Prevention: build the 4.0 server fresh and carry configuration across by hand, keeping the 3.0 host unchanged. Check: confirm the new host installs cleanly and the 3.0 host still serves meetings until cutover.
Missing Greenlight data in transfer
Greenlight room settings, user accounts and recording files are stored and handled separately, so a single export rarely captures everything teachers rely on. Prevention: inventory each data type and decide which ones need a separate transfer before cutover. Check: on the new server, confirm a migrated room keeps its name and settings and that a sample user can open the recordings they own.
Missing UDP media ports or TURN
The server needs TCP 80 and 443 and UDP 16384 to 32768 reachable, and a TURN server is recommended for users behind restrictive firewalls. Teams often test on the office network and miss media failures on home or hotel connections. Prevention: open the UDP range at the cloud and host firewalls and plan a TURN path. Check: run a test call from an outside network with audio, video and screen share.
LMS links pointing at the old server
Canvas, Moodle, Sakai, D2L and Schoology courses hold links and integration settings tied to the server hostname and credentials. After cutover, old course links can open the retired host or fail API checksum validation. Prevention: list every LMS course template and integration, then update the hostname and credentials on the LMS side before go-live. Check: launch a meeting from each template and confirm it joins the new server.
Losing Zoom or Teams recordings
Zoom and Teams exports are video files that do not appear in BigBlueButton's recordings list or LMS playback. The install docs size a 4.0 server with 500 GB of disk for recordings, and imported archives need their own storage allowance. Prevention: decide where archived files will be hosted, who can access them and how course links point to them. Check: open a sample export from a course link and confirm its access permissions match the original.
Cutover without a tested rollback
A cutover with no rehearsed rollback can leave a course without a working server during its first live session. Prevention: keep the 3.0 host running, document the DNS and LMS changes, and set a go or no-go decision point before switching. Check: run a rollback drill in a non-production window, switch DNS back to the old host and confirm a test meeting joins there.
How the work changes by starting point
BigBlueButton 4.0 cannot be upgraded in place from 3.0, so the work is a clean 4.0 installation on Ubuntu 24.04 with configuration and content carried across. The existing 3.0 server stays live until the new one is verified.
- Host sizing: Confirm the new server meets the 4.0 minimums for RAM, CPU, disk and bandwidth, and decide whether it replaces the old host or runs beside it.
- Recordings: Decide which recordings move, where they will be stored, and who keeps access to older material.
- Front end and LTI: Plan how Greenlight or LTI settings are reinstalled and which shared secrets are regenerated.
- Network: Confirm TCP 80 and 443, the UDP media range, the hostname for SSL and the TURN plan before the DNS switch.
Servers on 2.6 or 2.7 also need a clean 4.0 installation, and the older branch usually means more undocumented customization. The scope starts with an inventory of what the old server actually does before any installation begins.
- Customizations: List custom branding, presentation templates, scripts, cron jobs and any changes made to configuration files.
- Integrations: Confirm the LMS plugin or LTI version and check it against 4.0 before cutover.
- Recordings: Test that recordings made on older versions still play after migration, and decide whether they are archived instead of republished.
- Operating system: Plan for the full host rebuild, since the older Ubuntu release is not carried forward.
Moving from Zoom or Teams changes the scope from a server project to a content and workflow project. Live classes, recorded sessions, meeting links and user accounts all need a plan, and the work is driven by teaching schedules as much as by infrastructure.
- Recordings: Confirm with the Zoom or Microsoft 365 administrator who can export recordings, in what format, and how long retention applies.
- LMS links: Confirm which LMS embeds BigBlueButton and how course links to Zoom or Teams meetings will be replaced.
- Sign-in: Decide whether users sign in through the LMS, which removes separate Zoom or Teams accounts from the workflow.
- Feature parity: Test polling, breakout rooms and whiteboard use with instructors, since behavior differs from the tools they use now.
A multi-server estate adds the load balancing layer and the shared services behind it. Scalelite presents a pool of BigBlueButton servers as one endpoint, which means the migration covers every server in the pool and the components that connect them.
- Shared services: Confirm where PostgreSQL, Redis and the NFS volume for recordings will run, and who operates them.
- Pool consistency: Confirm each server meets the 4.0 requirements and uses the same shared secret before it joins the pool.
- Rolling cutover: Plan which servers are drained and moved first so live classes stay on the remaining capacity.
- LMS endpoint: Confirm the LMS points to the Scalelite endpoint, and that the LMS version supports it without per-server settings.
What the client needs to provide
Before we can scope a BigBlueButton migration, we need a complete picture of what exists today and who can approve the move. Start with an inventory of every current server, its operating system and its BigBlueButton version, including any Greenlight or LTI components installed alongside it. Note which systems run 2.6, 2.7 or 3.0, because direct upgrades to 4.0 are not supported and the existing estate will drive whether we rebuild on clean Ubuntu 24.04 hosts or move users across.
Next, supply the LMS and Greenlight configuration. For each learning management system, list the BigBlueButton endpoint URL, the shared secret handling method, the LTI or plugin version and any course-level settings that embed meeting links. For Greenlight, provide the environment configuration, the list of rooms with their owners and the recording retention rules that apply to each group. Confirm the LTI and plugin compatibility with your LMS administrator and the LMS vendor before scoping, since their release schedules set what can be tested.
Provide access to the DNS zone, TLS certificate process and firewall change process for the hostnames and networks involved. We need to know who can create records, who renews certificates and how long a firewall change takes to approve. The media path depends on TCP ports 80 and 443 and UDP ports 16384 to 32768, so network owners should confirm those ports and any TURN requirements for users behind restrictive firewalls.
Name the people who approve cutover, including a business owner, an LMS administrator, a network owner and an on-call contact for the cutover window. Also provide the academic calendar with teaching periods, exam weeks, and any events where live classes cannot be interrupted. Cutover must avoid those dates, so the calendar should be confirmed by the academic administrators rather than estimated from memory.
Frequently asked questions
Can I upgrade BigBlueButton 3.0 to 4.0 in place?
No. The BigBlueButton install documentation states that direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a clean server installation on Ubuntu 24.04 64-bit is recommended. A clean build leaves behind old packages, configuration and firewall or TLS drift, and it gives your team a known baseline to test against. The 3.0 branch still receives maintenance releases, so plan the cutover window, the data you keep from the old server and the LMS or Greenlight reconnection as one project.
What sets the cost and duration of a BigBlueButton 4.0 migration?
The written scope sets both. The main drivers are the number of servers and whether you need a Scalelite pool, whether Greenlight or LMS integrations must be rebuilt, how many rooms and recordings must carry over, the SSO and TURN work, and how many test cycles your LMS owners need. DeployOpen works on fixed-scope engagements, and a quote follows from that scope. Ask for line items for each driver, separate one-time work from recurring support, and a statement of which tasks your staff perform.
Can our own team migrate BigBlueButton to 4.0 without a partner?
Often yes, if the skills are on staff. The install is documented and uses the bbb-install.sh script, and 4.0 runs on Ubuntu 24.04. Your team needs Linux administration, TLS, firewall and network skills for the UDP media range, and experience with your LMS or Greenlight setup. Your staff will also need to provide a named technical contact, access to the current servers and backups, DNS and hostname control, firewall change authority, LMS administrator time for testing and a cutover sign-off owner.
What hardware does a BigBlueButton 4.0 server need?
The minimum in the install documentation is 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 of symmetrical bandwidth. Ports TCP 80 and 443 and UDP 16384 to 32768 must be reachable, the server needs a valid hostname for SSL, and Docker is required for sandboxed document conversion. A TURN server is recommended for users behind restrictive firewalls. These are minimums, so confirm the sizing for your peak concurrent users before ordering hardware.
Do Greenlight rooms and recordings move to the new server?
The supplied documentation does not describe an automatic transfer path for Greenlight rooms or recordings, so confirm the method with your deployment before promising it. Greenlight v3 is configured with environment variables, and external sign-in through OpenID Connect is a separate step from room data. Identify your Greenlight version, where room data is stored and where recordings sit on the old disk. Ask for a copy plan that is tested with sample rooms and recordings before cutover.
What happens to Zoom or Teams recordings when classes move to BigBlueButton?
Recordings made in Zoom or Teams stay on those platforms unless you export them. BigBlueButton records meetings on its own server, so it does not pick up those files on its own. Confirm with each vendor which export formats you can obtain, and confirm with your team whether those files can be stored, linked or converted for playback in your environment. Decide retention with your records and legal owners before you turn off the old service, and plan the archive as its own workstream.
How DeployOpen scopes, delivers and hands over this work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so a BigBlueButton 4.0 migration or move from Zoom or Teams runs in your cloud accounts, data centers or air-gapped network. Work is agreed as a fixed scope with written deliverables before it starts.
How we scope
- The written scope lists the server count, OS baseline, network paths and integrations for your BigBlueButton 4.0 migration or source-tool move.
- Scope records how existing 2.6, 2.7 or 3.0 rooms, Greenlight accounts and recordings will be carried over or retired.
- Engagements are fixed-scope, and the quote follows from that written scope, including any ongoing support retainer.
How we build
- We install BigBlueButton 4.0 on a clean Ubuntu 24.04 64-bit server, since direct upgrades from earlier branches are not supported.
- We configure TCP 80 and 443, UDP 16384 to 32768, SSL hostname, Docker-based conversion and TURN for restrictive networks, then test calls end to end.
- For LMS or Greenlight users, we test API checksums, login paths and recording access before any user cutover.
How we hand over
- You receive configuration records, network and port maps, runbooks and the migration cutover log for your own team.
- Recording and room data moved from the earlier system is verified against an agreed checklist before the source is decommissioned.
- Handover includes a walkthrough of patching the 3.0 and 4.0 branches so your staff can apply maintenance releases.
How we support
- Post-migration support, patching and LMS integration testing are available as a retainer, scoped in writing.
- Ask the support provider what on-call hours, response targets and monitoring for call quality are included before signing.
- Confirm with the vendor which 3.0 maintenance releases and 4.0 updates apply to your deployment before scheduling each change.
