Migrate from Webex to BigBlueButton

Migrate from Webex to BigBlueButton: what the move involves

BigBlueButton fits presenter-led, structured sessions, so a move away from Webex makes sense when most of your meetings are teaching, training or webinars with slides, whiteboard, polling and breakout rooms. The migration is mainly three pieces of work: building a server, changing how sessions are scheduled and created, and deciding what happens to existing recordings. It is not a like-for-like swap of a meeting client, and it is not a small change for a team that runs ad hoc calls from a personal room. Renewals, data residency requirements and lock-in are the usual reasons teams start this review, and the decision should rest on how your sessions actually run today.

The platform or IT team usually does the work, often with an implementation partner who builds the server, configures authentication and tests the session flows. The Greenlight room manager can be installed on the same server, and external sign-in can be added through OpenID Connect, so scheduling and login are part of the plan from the start. BigBlueButton 4.0 requires a clean server installation, not an upgrade, and the install docs state that direct upgrades from 2.6, 2.7 or 3.0 are not supported. If you run an existing BigBlueButton 3.0 server, plan a new build and a data migration rather than an in-place update. Confirm the current hardware, bandwidth and firewall requirements against the BigBlueButton install docs before you size the server.

The main risk is underestimating how much Webex work sits outside the meeting itself: calendar integrations, LMS links, user accounts and recording retention. Ask your implementation partner for a written scope that covers server sizing, a TURN plan for users behind restrictive firewalls, recording storage and retention, a cutover date for new sessions, and a rule for archiving Webex recordings before the contract ends. Ask for these items in a fixed-scope quote so the deliverables and timeline are agreed in writing before work starts.

Which Webex capabilities map cleanly to BigBlueButton

This table compares common Webex meeting and training capabilities with their BigBlueButton equivalents. Read each row as a starting point: clean means BigBlueButton covers the capability in its documented feature set, needs rework means the workflow changes or needs extra components, and gap or confirm means you should verify the fit in your own environment before committing.

Capability	Webex side	BigBlueButton position
Audio and video	Webex meetings with audio, video and screen sharing	Clean: BigBlueButton provides audio, video, chat and screen sharing in its virtual classroom
Slides with annotations	Presenting documents with participant annotation in Webex	Clean: slides with annotations are a core BigBlueButton feature, so test with your own decks and file types
Polling	Polls run during meetings and webinars	Clean: polling is included, but confirm result export and reporting match what your instructors need
Multi-user whiteboard	Whiteboard for collaborative sketching	Clean: a multi-user whiteboard is included, which suits workshops and teaching sessions
Shared notes	Notes shared alongside a session	Clean: shared notes are included, so confirm how notes are retained after the session ends
Breakout rooms	Breakout sessions assigned from the host	Needs rework: breakout rooms exist, but facilitators should rehearse assignment and return flows before cutover
Recording	Cloud or local recordings downloaded from Webex	Needs rework: recordings are stored on your server, so you own storage sizing, retention and download workflows
LMS embedding	Webex integrated into LMS platforms through connectors	Needs rework: BigBlueButton is embedded in Canvas, Moodle Cloud, Sakai, D2L and Schoology, but each integration needs its own setup and testing
Sign-in and room management	Control Hub manages users, licenses and sign-in	Gap or confirm: Greenlight v3 supports OpenID Connect, but Control Hub administration has no direct equivalent and needs confirmation

How the BigBlueButton server, Greenlight and LMS fit together

The core of the deployment is a single BigBlueButton server installed with bbb-install.sh on a clean Ubuntu 24.04 64-bit host. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so plan a fresh server rather than an in-place upgrade of an existing install. The same script can add the Greenlight room manager or LTI support on that server, which is the first decision to make: if the only users are staff joining rooms from a link, Greenlight on the same host is enough, and if teaching happens inside an LMS, LTI or the API becomes the entry point. Size the host against the install docs, which call for 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. Confirm these figures against the current documentation before you order hardware, because the sizing scales with concurrent rooms and recording volume.

Network planning needs the most attention before go-live. Users must reach TCP ports 80 and 443 and UDP ports 16384 to 32768, and the server needs a valid hostname for SSL. The LibreOffice document conversion runs in a Docker sandbox, so Docker must be present on the host. A TURN server is recommended for participants behind restrictive firewalls, and a meeting that works on the office network but fails from a hotel or a student dormitory usually points to missing TURN coverage. Ask your network team to confirm that the UDP range is open both inward and outward at the perimeter, and test from outside the campus or corporate network before the first training session. The LMS and API integration rests on one rule: every BigBlueButton API call carries a checksum computed from a secret shared with the server. The docs recommend SHA-256 by default and warn never to embed the shared secret in a web page. In practice, LMS plugins and LTI tools must call the server from the back end, and any custom page that builds join links in the browser must receive only the generated, signed URL or use LTI. Treat the shared secret as a credential, store it in your secrets manager, and rotate it through a planned change if it has been exposed.

Migration sequence from inventory to decommission

This sequence moves teaching, workshop and webinar sessions from Webex to a self-hosted BigBlueButton server in stages, so each step produces a record that the next one depends on. Scheduling links, LMS placements and the Webex site are changed only after a pilot and a parallel run have confirmed the new platform works for your sessions.

Inventory sessions, recordings and LMS integrations
Owners of the Webex site, usually the IT administrator with input from the teaching or training leads, list every recurring session, its host, its audience size, and which features it uses: slides, whiteboard, polling, breakout rooms, recording or chat. The same list records where each meeting link appears, including the learning management system, intranet pages, calendar invitations and any scripted integrations. Recordings are catalogued by owner, retention need and format, since Webex exports will be the input for archiving. The output is a session inventory with a link map, reviewed by each department that runs sessions. It is done when every recurring session has a named owner and a decision on whether it moves, archives or retires.
Build and size the BigBlueButton server
The platform team installs BigBlueButton 4.0 on a clean Ubuntu 24.04 64-bit server using the bbb-install.sh script, because the install documentation does not support direct upgrades from 2.6, 2.7 or 3.0. Sizing starts from the documented minimums 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. The team also confirms that TCP ports 80 and 443 and UDP ports 16384 to 32768 are reachable, that a valid hostname is in place for SSL, and that Docker is available for LibreOffice conversion. The output is a sizing record and a build record, with peak concurrent session counts from the inventory compared against the documented minimums. Confirm with your network team whether a TURN server is needed for participants behind restrictive firewalls.
Configure access, LMS and room management
The team decides how people sign in and how rooms are created before any pilot users arrive. Greenlight can be installed with the same script for room management, and Greenlight v3 can use OpenID Connect against your existing identity provider, with Keycloak suggested in the docs if you need Google, Microsoft or SAML sign-in. The LMS administrator tests the embedded BigBlueButton placements in a non-production course. API secrets are stored only on the server side, never in a web page, and checksums are set to a supported hash. The output is a configuration record listing sign-in method, room naming rules, LMS integration settings and secret storage location, signed off by the security owner.
Run a pilot with a small group of teachers or trainers
Choose a small group of teachers or trainers who run different session types, such as a lecture with polling, a hands-on workshop with breakout rooms and a live webinar with a large audience. Each pilot user runs at least one real session on the new server while a support contact is present. Participants are asked to report audio, video, whiteboard, screen-sharing, recording playback and LMS access problems, and the team measures server load during each session. The output is a pilot feedback log linked to each session, along with a list of gaps, such as features the pilot group relies on that the team has not confirmed. The step is complete when every session type in the inventory has been run once and the log has a decision for each open issue.
Run Webex and BigBlueButton in parallel
For a defined period agreed by the program owner, sessions can run on either platform while scheduling links point to both. The team compares attendance, join failures, recording completeness and support tickets for the same session types on both systems. Recordings from BigBlueButton are checked for playback on the intended devices, and the archive procedure for Webex recordings is tested end to end. The output is a parallel-run report with comparison metrics per session type and a list of users who needed help. Do not end this phase until the report shows that each session type has a working path on BigBlueButton and that archived recordings open correctly.
Cut over scheduling links and LMS placements
The program owner changes calendar templates, LMS course placements, intranet links and any scripted invitations to point to BigBlueButton rooms, using the link map from the inventory as the checklist. Each change is made in a controlled batch, and the old Webex links are left to redirect or display a notice for a period agreed with users. Support staff are briefed on the new join steps and the location of recordings. The output is a signed-off cutover checklist where every link in the map is marked as changed and tested, with the approver's name and date recorded. Keep a rollback plan for the LMS placements until the parallel-run report is accepted.
Decommission the Webex site
Once cutover is signed off, the team confirms that every recording needed for retention has been exported and stored in the agreed location, using the Webex export process and the archive plan from the inventory. Users are removed or deactivated, integrations are disabled, and the contract end date is confirmed with the vendor, along with any data deletion steps the contract requires. Records of exports, access removals and deletion confirmations are retained for audit. The output is a decommission record that lists archived recordings with their locations, disabled integrations, and vendor confirmation of the end of service. Confirm with your procurement and legal teams what the Webex terms require before any deletion begins.

What data and integrations move, and what you rebuild

Recordings can usually be carried over as files, but meeting links, invitee lists, LMS placements and sign-in are configuration that you recreate on BigBlueButton. Inventory each item before cutover, and confirm what your Webex site's recordings and APIs allow, since export options depend on your licensing and admin settings.

Webex recordings as files

Recordings are the one item you can usually take out of Webex as media files. Confirm with your Webex administrator which recordings can be downloaded, whether the export is per recording or batch, and which file formats and transcripts come with them. Store the originals in your own object storage with a retention label, then decide which ones BigBlueButton needs to replay. BigBlueButton keeps its own recording format, so Webex MP4 files are archives, not replayable BigBlueButton sessions.

Scheduled meeting links

Webex personal room and scheduled meeting URLs will stop working once the site closes. Each BigBlueButton room is a Greenlight room or an API-created meeting with its own join links, so you must publish new URLs and update every calendar invite, bookmark and embedded link. Build a list of recurring training series and workshop rooms first, because these are the links most often pasted into course material and wikis.

Invitee lists and attendance history

Invitee lists from Webex calendars are not automatically a BigBlueButton asset. Export the lists from your calendar or Webex scheduling tool where your site allows it, and rebuild the access lists in Greenlight or your LMS. Attendance and poll results are per session in BigBlueButton, so decide which records you need to keep as evidence and export them from Webex reports before the contract ends.

LMS course placements

BigBlueButton is embedded in Canvas, Moodle, Sakai, D2L and Schoology, so course placements usually move as LMS configuration, not as Webex data. Check which Webex links sit inside course shells, which activities reference recordings, and which instructors manage them. Each placement must be recreated with the BigBlueButton external tool or plugin in the LMS, and then tested with a student account.

Greenlight rooms with OpenID Connect sign-in

Greenlight rooms and their sign-in are rebuilt, not migrated. Greenlight v3 uses OpenID Connect configured through environment variables, and the project suggests Keycloak to add Google, Microsoft, SAML or other logins. Map each Webex sign-in group to a Greenlight role, define who may create rooms, and set the redirect and client settings against your identity provider before users are invited.

Calendar and SSO integrations

Webex integrations with Outlook, Google Calendar, and single sign-on through your identity provider do not carry over. Calendar invitations must be generated from the BigBlueButton room or LMS, and sign-in must be rewired to your identity provider. Ask your identity team which Webex connectors are active, then document the replacement for each and test invitations for external guests.

What changes for scheduling and recordings

Scheduling changes first. Webex users typically create a meeting in Webex, send a calendar invitation with the Webex join link, and let the Webex cloud hold the room. On BigBlueButton, rooms are created through Greenlight, through an LMS that embeds BigBlueButton, or through the BigBlueButton API, where each room is identified by its own meeting ID and join URL. Every invitation template, calendar series, LMS course link and bookmarked Webex address therefore needs to be rebuilt, and teachers need to know that a room link from the old site will not open a BigBlueButton room. Decide early which system is the source of truth for rooms, whether that is Greenlight with OpenID Connect sign-in or the LMS, and confirm with your LMS administrator how embedded rooms are created and shared.

Recordings are a storage decision before they are a migration task. BigBlueButton keeps recordings on the BigBlueButton server itself, so the install documentation's figure of 500 GB of disk for recordings (50 GB without recording) is the starting point for capacity, not a detail to settle later. Estimate how many hours of sessions you run each term, how long each recording must be kept under your retention schedule, and whether recordings must be copied to separate storage. Ask your records and legal teams which retention periods apply to training and teaching material, and plan an archive job before the Webex contract ends so that existing Webex recordings are downloaded and checked while the account still works. Confirm with Cisco what export formats and access the site administrator has for those files, since the target format and folder structure will differ from Webex's output.

What drives cost and effort in a Webex to BigBlueButton move

This table lists the cost and effort components of moving Webex meetings and training to a self-hosted BigBlueButton server, with who is paid, whether each item is one-time or recurring, and what raises or lowers it. Use it to build a written scope and to check that a quote covers every line.

Component	One-time or recurring, and who is paid	What raises or lowers it	What to ask for in a quote
Server hardware or cloud instances	Recurring if cloud instances, one-time if hardware. Paid to the cloud provider or hardware vendor, plus the team that provisions them.	Concurrent classes and sessions, and the 16 GB RAM, 8 CPU core minimums in the install docs. Extra instances for peak load raise cost.	Instance type or hardware spec per server, count for production and staging, and the sizing assumption for concurrent users.
Network bandwidth	Recurring. Paid to the data center or cloud provider.	The 250 Mbit/s symmetrical minimum per server, plus any TURN relay traffic for users behind restrictive firewalls. Lower concurrency and a TURN server placed on the same network reduce spend.	Committed bandwidth, egress pricing and whether TURN traffic is included or billed separately.
Storage for recordings	Recurring as recordings accumulate. Paid to the storage provider or hardware cost of disks.	The 500 GB minimum disk for recordings (50 GB without recording). Retention period and recording length drive growth. Archiving to cheaper storage lowers cost.	Initial disk size, growth estimate based on your recording hours, backup copies and retention policy.
Implementation labor for the build	One-time. Paid to the implementer or internal staff for install, TLS, firewall rules, UDP port range and document conversion setup.	Number of environments, whether a clean Ubuntu 24.04 install is required, and how many firewall and network changes are needed.	Fixed-scope deliverables, a named test plan and acceptance criteria, and the hours or days assumed for each step.
LMS integration	One-time for the integration, recurring for maintenance when the LMS upgrades. Paid to the implementer or LMS administrator.	Which LMS you run (for example Canvas, Moodle or D2L), how many courses use BigBlueButton, and whether an LTI connection is needed.	The integration method and supported LMS versions, test course results, and who maintains the connector after go-live.
Identity work for OpenID Connect	One-time for configuration, recurring for user lifecycle changes. Paid to the implementer and identity team.	Whether you use Greenlight v3 with an existing identity provider or add Keycloak to bridge Google, Microsoft or SAML sign-in.	Identity provider mapping, claims and group rules, and how user removal is handled when staff leave.
Training for presenters and moderators	One-time for the initial program, recurring for new staff. Paid to the trainer or internal training team.	Number of presenters, their familiarity with Webex, and how much the breakout, poll and whiteboard workflow differs from current sessions.	Session format, materials, and whether recordings of the training are provided for later onboarding.
Ongoing operations and upgrades	Recurring. Paid to internal operations staff or a support retainer.	Patch cadence, the separate upgrade path (4.0 is installed clean, not upgraded directly from 2.6, 2.7 or 3.0), monitoring, backups and incident response hours.	Scope of monitoring and backup, upgrade plan for the 4.0 line and the 3.0 maintenance releases, response times, and who holds the on-call duty.

How the move differs by starting point

Schools and universities that run most sessions from a learning management system usually find the migration simplest, because BigBlueButton is already embedded in several LMS platforms, including Canvas, Moodle Cloud, Sakai, D2L and Schoology. Sessions are typically scheduled as course activities rather than as standalone meetings, so the scheduling change is mostly about where instructors click. Recordings tend to be tied to course shells, which makes retention and access rules a question for the registrar and the LMS administrator as much as for the IT team. Plan for the cluster of students who join from home networks, since UDP reachability and a TURN server matter more here than the number of concurrent users.

Server sizing: Size for the peak timetable, not the average. A single server needs at least 16 GB of RAM with swap, 8 CPU cores and 250 Mbit/s symmetrical bandwidth.
Scheduling: Confirm which LMS version and BigBlueButton integration path your institution will use, then map existing Webex links to course activities.
Recordings: Decide retention before cutover, and plan 500 GB of disk for recordings on the server, or 50 GB if recording is turned off.
Presenter training: Instructors need practice with slides, annotations, polling and breakout rooms inside the LMS context.
Network: Open TCP 80 and 443 and UDP 16384 to 32768 and test from student-facing networks.

Confirm the exact LMS integration steps and sizing for your enrollment peaks with the BigBlueButton documentation and your LMS vendor before setting a cutover date.

What usually goes wrong and how to prevent it

Most BigBlueButton migrations that stall do so for predictable reasons: the server is built the wrong way, the network blocks media, or the data and links change at cutover. Each card below names one of these risks for a Webex-to-BigBlueButton move and the check that prevents it.

Upgrading in place from older versions

BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported. Teams that try to upgrade an existing server in place often end with a broken installation and lost test time. Plan a clean server installation and move configuration, branding and users across by hand. Confirm your server operating system version before scheduling any work.

Undersized server hardware

A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 500 GB of disk for recordings, or 50 GB without recording. Teams often size for the number of users but forget that recordings and slide conversion consume disk and CPU. Size for peak concurrent sessions and recording volume, then test a full-class session before go-live. Ask your implementation partner to document the sizing assumptions in writing.

Blocked UDP media ports

BigBlueButton requires TCP ports 80 and 443 and UDP ports 16384 to 32768 to be reachable. Many corporate and campus firewalls allow web traffic but drop the UDP range, so audio and video fail while the login page still loads. Open the full UDP range in the firewall and any cloud security group before the pilot, and test from the networks where students and staff actually sit.

No TURN server for restrictive networks

Users behind restrictive firewalls, hotel Wi-Fi, or some home routers may not reach the media server directly, even when the ports are open on the server. The BigBlueButton install guidance recommends a TURN server for these users. Deploy a TURN server and test it from a restricted network during the pilot, because without it some participants will hear nothing and report the problem as a general outage.

Recordings left behind at contract end

Webex recordings and their transcripts do not move automatically to a new platform, and BigBlueButton keeps its own recordings on the server disk. If the Webex contract ends before recordings are downloaded, the material may be gone. Export and verify recordings from Webex during the parallel run, store them in your own object storage or file archive, and set a retention policy for BigBlueButton recordings so disk does not fill silently.

API secrets leaking into web pages

Every BigBlueButton API call must carry a checksum computed with a secret shared with the server, and the documentation warns never to embed that secret in a web page. Custom portals or LMS plugins that build join links in browser code expose the secret to anyone who views the source. Compute checksums on the server side only and rotate the shared secret if a page or repository has ever contained it.

LMS and sign-in changes breaking links

Teachers often embed meeting links in courses, calendars and LMS pages, and those links stop working when the room URL, the Greenlight front end, or the sign-in method changes. Greenlight v3 supports OpenID Connect for external sign-in, and Keycloak is suggested for adding other login methods. Map every existing Webex link to its new room, configure sign-in before cutover, and confirm that the LMS integration behaves the same for staff and students.

Questions buyers ask before moving Webex sessions to BigBlueButton

How much effort and cost does a move from Webex to BigBlueButton involve?

The cost is mostly labor and hosting, and very little of it is a software license, because BigBlueButton is licensed under the LGPL-3.0. The main components are the servers and bandwidth you provision, the people who install, configure and secure the platform, the LMS or Greenlight integration, the migration of recordings and content, and the staff who run it afterward. Costs rise with the number of concurrent sessions, recording retention, the number of LMS integrations and the strictness of your identity requirements. Ask any partner for a fixed-scope quote that lists each component separately, and ask your own infrastructure team to price server hours, storage for recordings and symmetrical bandwidth against your current Webex contract. Your Webex subscription and any Video Mesh nodes are the baseline you are comparing against.

How long does a Webex to BigBlueButton migration take?

The timeline depends on how many sessions you must support, how many integrations must be rebuilt and how much testing your teaching or training staff need before cutover. Start with a clean server installation, since BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, and the install script runs on Ubuntu 24.04. Then plan time for identity setup, LMS embedding, a pilot with a small group of facilitators, and a parallel run that keeps Webex available. Ask any implementation partner to break the schedule into those phases in the written scope, and confirm your own change windows with the teams who depend on the sessions.

What does the migration require from our own staff?

It requires a small team with Linux server administration skills, someone who owns the LMS or Greenlight configuration, someone who can manage DNS, SSL certificates and firewall rules, and facilitators who will test polling, breakout rooms and the whiteboard in real sessions. The server needs a valid hostname for SSL, reachable TCP ports 80 and 443, and UDP ports 16384 to 32768, so your network team must approve those rules. Identity work needs whoever controls your directory. Confirm with your own teams how many hours each role can release during the pilot and who will hold on-call responsibility after go-live.

Can our team do the BigBlueButton migration without an implementation partner?

A capable Linux operations team can install BigBlueButton 4.0 from the project's installation documentation, but the question is whether they can also sustain it. Security hardening, OpenID Connect sign-in through Greenlight, TURN configuration for users behind restrictive firewalls, document conversion through Docker and recording storage all need ownership after the first install. Assess your team against that list honestly. If the gaps are in networking, identity or LMS integration, a fixed-scope engagement can cover those parts while your staff keep the operational knowledge. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and retainers cover ongoing upgrades and support.

Can we move our existing Webex recordings to BigBlueButton?

Webex recordings are not automatically converted into BigBlueButton recordings, so treat existing files as an archive question rather than a playback question. Export the recordings you must keep from Webex before the contract ends, store them in a location your compliance team approves, and decide which ones need to be re-published in BigBlueButton or your LMS. Check the exported file formats and whether your retention rules require metadata such as participant lists or session dates to travel with each file. Confirm the export options with Cisco and the retention obligations with your records or compliance owner before deleting anything from Webex.

How do we plan session capacity on BigBlueButton?

Capacity planning starts with the peak number of concurrent sessions, their expected participant counts and whether recording is on for each one. The published 4.0 minimums are 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 on one server. Larger deployments need additional planning, and the project's Scalelite load balancer can distribute meetings across several servers. Ask your infrastructure team to measure current Webex peak usage and to confirm whether your data center or cloud region can provide symmetrical bandwidth, then test the proposed sizing with a load test before committing to hardware.

What are the main risks of moving Webex sessions to BigBlueButton?

The main risks are losing features your facilitators rely on, underestimating operations and failing to test under real conditions. Confirm early that polling, breakout rooms, whiteboard, shared notes and slide annotation cover your workflows, and that the LMS or Greenlight setup meets your sign-in rules. Check that users behind firewalls can connect, which may require a TURN server. Also plan for the security work: API calls must be signed with a checksum computed from the shared secret, and that secret must never appear in a web page. Put each risk in the written scope with an owner.

How DeployOpen scopes and runs the move

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted BigBlueButton inside your own infrastructure, whether that is your cloud accounts, a data center or an air-gapped network. Most engagements are fixed-scope, so the server count, the Greenlight or LTI integration, the identity method, the recording policy and the cutover steps are written down and agreed before any work starts. For a Webex move, the scope should state which meeting types move (teaching, workshops and webinars with slides, whiteboard, polling and breakout rooms), which Webex features are out of scope, and who on your side signs off each stage.

The written scope also fixes the deliverables. Typical items include a sized BigBlueButton 4.0 server built on a clean Ubuntu 24.04 installation, since direct upgrades from 2.6, 2.7 or 3.0 are not supported, a TURN server decision for users behind restrictive firewalls, the TLS certificate and hostname, sign-in through Greenlight v3 with OpenID Connect, backup and restore runbooks, and operating documentation for your administrators. Ask for each item to be listed with an acceptance test, and confirm how recording storage retention will be handled against your policy.

DeployOpen does not publish a price list. A quote follows from the written scope, so the figures you receive will depend on the number of servers, integrations, environments and the testing you request. Ongoing support, upgrades and continuous testing are available as a retainer after go-live, which covers the recurring side of the work. Ask the quote to separate one-time implementation from recurring support, and confirm with your team which costs you carry in-house, such as bandwidth, storage and staff time.

Migrate from Webex to BigBlueButton