Can an open-source tool replace Zoom Webinars for your town halls?
If a Zoom Webinars renewal, a data residency rule or a licensing change is forcing the question, the short answer is yes for presenter-led sessions: Jitsi Meet with Jibri, or BigBlueButton, can host webinars and town halls on servers you control. Registration, attendee question handling and very large audiences are not built into either platform in the way Zoom Webinars packages them, so each of those needs a separate component or process. This section sets out those trade-offs, not a like-for-like feature match. Webinars work on a role model that meetings often do not need. Panelists and presenters hold audio, video and screen sharing, while attendees mostly watch and listen. In Jitsi, that split is usually handled by keeping attendees in a view-only or muted state, with a Jibri recorder or streamer capturing the room for broadcast. BigBlueButton gives presenters the slide deck, polling and whiteboard, and attendees a viewer role, which suits a structured session better than an open discussion. Decide early which of your events need panelists who speak and which need an audience that only watches. Before you choose, check three things in your own environment. First, confirm how your attendance numbers compare with the capacity of a single server, since the Jitsi scalable setup guide adds videobridges horizontally and BigBlueButton 4.0 has its own minimum hardware and bandwidth specification. Second, decide where registration, identity and Q&A will live, because neither platform replaces a registration form or a moderated question queue on its own. Third, test the live stream path end to end, including the recording and where the files land, with a rehearsal that mirrors a real town hall.
Which Zoom Webinars capabilities map to Jitsi and BigBlueButton
This table maps each common Zoom Webinars capability to the open-source option that covers it, with the gap you need to plan for. Use it as a checklist against your own Zoom admin console, since Zoom's registration and reporting details are not covered by the facts here and must be confirmed directly. The main takeaway is that meeting, streaming and recording map well, while registration, reporting and attendee management usually need separate tools.
| Capability | Open-source option | Coverage gap |
|---|---|---|
| Live presenters | Jitsi Meet for open presenter sessions, BigBlueButton for presenter-led sessions with slides and polls | Jitsi has no built-in presenter-only mode in the facts supplied, so confirm role controls before choosing it for large events |
| Attendee audience | Jitsi with Jibri streaming or BigBlueButton viewer seats | Audience size depends on your Jitsi videobridge count or BigBlueButton server capacity, so test with your expected viewer count |
| Live streaming to a broadcast destination | Jitsi with Jibri for live streaming | You provide the streaming destination and its keys, and you must confirm how Jibri handles failed outputs in your version |
| Recording | Jibri recording in Jitsi (one recording per Jibri instance) or BigBlueButton built-in recordings | Each Jibri instance records one session at a time, and BigBlueButton 4.0 recordings need planned disk space |
| Registration and approval | External form or email platform, or Greenlight rooms with external authentication | Neither Jitsi nor BigBlueButton provides full webinar registration with approval workflows, so confirm what your Zoom setup uses |
| Q&A and polls | BigBlueButton polling and chat, or an external Q&A tool for Jitsi | Jitsi has no native polling in the facts supplied, so plan a separate tool if Zoom Q&A is part of your event |
| Practice sessions | Test rooms on a staging Jitsi or BigBlueButton server | Practice rehearsals need a separate server, which adds hosting cost and operations work |
| Reporting and attendee analytics | Server logs and recording metadata, or an external analytics tool | Attendance reports from Zoom are not covered by the supplied facts, so confirm the exact reports you export before migration |
| SSO-based access | Greenlight v3 with OpenID Connect, or Jitsi with JWT tokens, often through Keycloak | Requires an identity provider such as Keycloak to add Google, Microsoft or SAML logins, which is extra setup work |
When Jitsi Meet or BigBlueButton fits a webinar workload
Zoom Webinars combines a large audience, registration and streaming in one product. Self-hosted Jitsi Meet and BigBlueButton cover parts of that workload, each with a different shape. The cards below show which session types each one suits, what it takes to run, and where the limits are before you commit.
Jitsi Meet with Jibri for live streaming
Jitsi Meet runs the meeting, and Jibri joins it as a headless browser to record or stream the session to an external endpoint. Each Jibri instance handles one recording or stream at a time, so a town hall that must be recorded and streamed at once needs more than one Jibri host. Check the Jibri hardware and the streaming destination before the event, and test a full-length session with the audience size you expect. Jitsi's audience handling depends on your videobridge capacity, which you should size with the scalable setup guide.
BigBlueButton for presenter-led sessions
BigBlueButton suits sessions where a presenter drives slides with annotations, runs polls, uses a multi-user whiteboard and splits attendees into breakout rooms. Those tools map well to training and structured town halls, but they are built around a classroom model rather than a broadcast model. Confirm with your team that the audience size, presenter count and interaction style fit before choosing it over Jitsi for large events.
Greenlight as the room manager
Greenlight is the room manager front end for BigBlueButton, giving hosts persistent rooms they can invite people into. It covers room creation and access for recurring sessions, but it is not a registration system, so sign-up forms, reminders and attendee lists still come from another tool. Plan the integration with your identity provider and registration platform as a separate workstream.
BigBlueButton 4.0 clean install requirement
BigBlueButton 4.0 installs on Ubuntu 24.04 with bbb-install.sh, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a new server is the recommended path. Existing BigBlueButton 3.0 users must plan a migration of recordings and room data rather than an in-place upgrade. Confirm the server specification, including 16 GB of memory, 8 CPU cores and 250 Mbit/s symmetrical bandwidth, before you schedule cutover.
Jitsi with JWT authentication for controlled access
Jitsi's handbook recommends JWT token authentication over the deprecated secure domain method for new installations, and it suggests a separate anonymous domain for guests. For a webinar, this lets your registration system issue signed tokens so only registered attendees can join a room, while speakers join as authenticated moderators. Confirm the token claims and room naming with your developers, and test that guest access stays limited to the intended audience.
How a Jibri live stream reaches a broadcast audience
A streamed Jitsi webinar depends on five components working in sequence. The web front end serves the meeting page to presenters and viewers, Prosody (the XMPP server) holds the session and user state, Jicofo (the conference focus) assigns participants to conferences, and Jitsi Videobridge routes the audio and video media. Jibri is the headless recorder and streamer: it joins the meeting as a hidden participant, captures the room and pushes it to a streaming destination. Because Jibri sits inside the same chain, a fault in any upstream component stops the stream. The official self-hosting guide states that HTTPS is necessary for multimedia to work, so the front end needs a valid certificate on a proper domain before any webinar test.
Audience reach is not set by Jitsi. It is set by the streaming destination you configure for Jibri, typically an RTMP ingest point on a platform or on your own media server. Whether viewers can reach that destination, how many can watch at once, whether replays are kept, and what the platform's terms allow are all questions to answer with the destination's provider and with your own legal and communications teams before launch. Run a rehearsal to the actual endpoint, from outside your network, to confirm the viewer path works end to end.
Plan capacity around the constraint that one Jibri instance handles one recording or stream at a time. If you need a live stream and a local recording of the same event, or two concurrent broadcasts, you need a second Jibri instance with its own resources. Confirm with the Jibri project documentation in the jitsi/jibri repository how instances are registered and how many can run per host, and budget the CPU and memory each instance needs for encoding. The Jibri container runs under a separate service, so test failover and restart behavior with a dry run before a live event.
Choosing Jitsi, BigBlueButton or a hybrid by webinar format
Large one-way broadcasts and town halls have a few presenters and a large audience that mostly watches and asks questions in text. Jitsi Meet fits this pattern best, because the presenter room can be streamed to a destination through Jibri, which runs a headless browser and captures the meeting. Plan for a Jibri instance per concurrent stream, since the project documents one recording or stream per Jibri instance, and add videobridges to carry the audience load.
- Server roles: a web front end, Prosody, Jicofo, several Jitsi Videobridge nodes for audience media, and one or more Jibri hosts for the outbound stream.
- Streaming destination: the stream goes to a platform you choose, such as a self-operated RTMP ingest or a video service with an RTMP endpoint. Confirm the destination supports the codecs Jibri produces.
- Registration: use an external form or event tool that issues links, then restrict entry with JWT tokens so only registered attendees get a valid room.
- Chat moderation: Jitsi's in-room chat is open to all participants, so moderation needs a plan such as a moderator role or a separate Q&A tool.
- Load: confirm bridge capacity with a test at your expected audience size before the event date.
Check that your streaming destination and registration tool run inside your approved hosting boundary.
Interactive training depends on participants doing things: answering polls, working in small groups, sharing their screens and writing on a shared surface. BigBlueButton is built for this pattern, with polling, a multi-user whiteboard, shared notes and breakout rooms in the core product. It is typically run as a single self-hosted server for smaller cohorts, with Scalelite available when you need to pool several servers behind one entry point.
- Server roles: a BigBlueButton 4.0 server on Ubuntu 24.04, sized to at least 16 GB of memory and 8 CPU cores, with UDP ports 16384 to 32768 open.
- Room management: Greenlight provides persistent rooms, and external authentication through OpenID Connect can be added with Keycloak for corporate sign-in.
- Registration: use the LMS or your enrollment system to create sessions, since BigBlueButton integrates with LMS platforms such as Moodle and Canvas.
- Chat moderation: the built-in chat can be restricted by role, but confirm the moderation controls your team needs in the current release.
- Session data: plan for the 500 GB of recording storage if you keep recordings, or 50 GB without recording.
Confirm the server specification and the clean install requirement for the release you plan to deploy before you order hardware.
Some events need both a broadcast audience and an interactive segment, such as a conference day with a keynote followed by workshops. A hybrid design runs the two stacks side by side: Jitsi handles the large, streamed keynote, and BigBlueButton hosts the interactive sessions. The trade-off is that you operate two platforms, two identity configurations and two sets of logs, so the case for a hybrid should be stated clearly before you commit.
- Server roles: a Jitsi cluster with Jibri for the keynote, plus a separate BigBlueButton server for workshops, each sized for its own peak.
- Identity: one identity provider can serve both stacks, but Jitsi JWT tokens and BigBlueButton checksum-signed API calls need separate secrets that are never placed in a web page.
- Registration: a single event tool can issue links that point attendees to the correct room for each session.
- Chat and Q&A: keep the tools for each session consistent so attendees do not have to learn two systems mid-event.
- Operations: budget staff time for two upgrade paths, since the two projects release on their own schedules.
If the event mix is occasional, ask whether a single stack with a larger server pool covers both formats before you accept the added complexity.
Before you split a program across two platforms, compare the formats your organization actually runs over a year. Most teams find that one format dominates, and the decision becomes simpler once that is clear. Jitsi suits high-volume broadcasts with streaming, while BigBlueButton suits presenter-led sessions where participants interact heavily with shared tools.
- Audience size: large one-way events lean toward Jitsi with bridge scaling and Jibri streaming.
- Interaction needs: polls, whiteboards and breakouts lean toward BigBlueButton.
- Streaming: if live streams to an outside destination are required, Jitsi with Jibri is the documented route.
- Staff skills: consider which team will run each stack after the first event.
- Quotes: ask any implementation partner to price each stack and the hybrid option separately, based on your written scope.
Write the event calendar down and test the chosen design with a rehearsal at realistic attendance before the first live session.
Running webinar tools beside the rest of your Zoom suite
Most organizations will not move every Zoom workload on the same day. Webinars can move to a self-hosted stack while regular meetings, chat and archived recordings stay where they are, but each link between the systems needs an owner and a test. The cards below cover the decisions that connect them.
Keep Zoom for other meetings
Moving webinars does not require moving every meeting. Decide which workloads stay on Zoom during the transition, such as internal stand-ups or external calls with partners who only use Zoom. Map each user group to a platform so calendar invitations, room links and support requests point to the right place. Confirm that your Zoom plan and contract terms allow a partial move before you change anything for users.
Zoom Node is not a coexistence bridge
Zoom Node runs on your premises but is managed from the Zoom cloud, so it is a different architecture from a self-hosted Jitsi or BigBlueButton server. Webex Video Mesh is also a Cisco-managed on-premises component tied to its cloud. Neither replaces a stack you operate yourself. Confirm with each vendor what traffic stays local, what still depends on their cloud, and how the two sets of systems would share a network segment.
Link identity with OpenID Connect or JWT
Webinar hosts and presenters should sign in with the same identity source they use elsewhere. For BigBlueButton Greenlight v3, OpenID Connect is configured through environment variables, and the project suggests Keycloak to add other login methods. For Jitsi, JWT tokens let your application issue room access for hosts and attendees, with a separate anonymous domain for guests. Test role mapping for presenters, moderators and attendees before the first live event.
Keep team chat in a separate tool
Zoom's in-meeting chat is only one part of the Zoom Workplace chat experience. Webinar Q&A and attendee chat need a home, and most organizations keep persistent team messaging in a separate product. Decide whether attendee questions stay inside the webinar tool or move to a team chat channel, and confirm how transcripts and chat logs are exported. Plan the integration as a separate project rather than assuming it arrives with the video server.
Archive existing Zoom recordings first
Past webinar recordings, transcripts and captions in Zoom are the files most likely to be lost during a move. Zoom provides MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files from the recordings page. Download them, check that playback and captions work, and store them in a location your records policy covers. Decide the retention period for each set of files before the Zoom subscription ends.
Plan capacity for the largest session
Webinar audiences put different load on a server than small meetings do. For Jitsi, the scalable setup guide says videobridges scale horizontally by adding more, and suggests a 4 CPU, 8 GB central server with 4 or 8 CPU and 8 GB RAM per videobridge. For BigBlueButton 4.0, the install documentation lists 16 GB RAM, 8 CPU cores and 250 Mbit/s symmetrical bandwidth per server. Test the peak attendee count with your own network before promising a session size.
What server capacity large webinar audiences require
Start with the BigBlueButton 4.0 baseline: at least 16 GB of memory with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB if you do not record) and 250 Mbit/s of symmetrical bandwidth, on Ubuntu 24.04 installed through bbb-install.sh. Because 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, plan a clean server for the new release rather than an in-place upgrade of an existing one. Presenter video, screen shares and recording all draw on the same machine, so a town hall with a large audience and a recording requirement is the case where the disk and bandwidth figures matter most. The 250 Mbit/s figure is a minimum for the server, so confirm your uplink with your hosting provider before you commit to a date.
For Jitsi, the scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB of RAM for each videobridge. Videobridges scale horizontally, and the default install is already set up for that, so capacity grows by adding bridges rather than by enlarging one machine. Jibri recording and streaming run on separate hosts, and each Jibri instance records one meeting at a time, so a webinar that is streamed live and recorded needs its own sizing decision. Neither project supplies a concurrent audience figure for a given server, so the number of viewers one bridge or BigBlueButton server can carry is not known from the documentation. Load-test with your own presenter count, viewer count, camera and screen share settings, and recording or streaming enabled before you promise an audience size.
When one BigBlueButton server is not enough, Scalelite pools several BigBlueButton servers behind a single entry point, which is the usual route to more capacity in that stack. Separately, a TURN server is recommended for participants behind restrictive firewalls, and BigBlueButton expects UDP ports 16384 to 32768 to be reachable, so a webinar audience on corporate networks may need TURN before it can join. Ask your network team to confirm whether external viewers can reach those UDP ports, and test from the networks your audience will actually use.
Moving webinar schedules, registrants and recordings off Zoom
This sequence moves archived webinar content, registration and reporting records, and a working Jitsi or BigBlueButton room into your own infrastructure, so attendees and presenters can switch over without losing history.
Export Zoom recordings, transcripts and captions
The webinar owner or Zoom account administrator downloads every cloud recording from the recordings page, including MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files. Zoom's file format guidance explains what each file contains, so check that each webinar has the set you expect. Store the files in a location you control and confirm that a sample of each type opens correctly before you delete anything from Zoom. Done means every archived webinar has a verified copy outside Zoom, with a list of where each file lives.
Document registration, reporting and attendee lists
Record how registration pages, confirmation emails, reminder sequences, attendee reports and polling results are produced today, and who owns each one. Zoom's registration and reporting features do not carry over to Jitsi or BigBlueButton, so each function needs a named replacement, such as a form tool, a mailing list or a CRM, which you must choose and integrate yourself. Export registrant and attendance reports where Zoom allows it, and keep them under the same data handling rules as the rest of your personal data. Done means a written inventory exists for every registration and reporting function, with an owner and a replacement or a decision to retire it.
Build the server and certificates
Your infrastructure team provisions the servers for the chosen platform. Jitsi requires HTTPS with a proper domain certificate for working audio and video, and the handbook warns that self-signed certificates cause problems, especially on mobile. BigBlueButton 4.0 is installed on a clean Ubuntu 24.04 server, since direct upgrades from earlier versions are not supported, and its install docs list the memory, CPU, disk and bandwidth needed. Confirm the required TCP and UDP ports are reachable through your firewall and that a TURN server is planned for attendees behind restrictive networks. Done means the server answers on a valid hostname over HTTPS and a test call succeeds from outside your office network.
Configure rooms and authentication
Set up webinar rooms with the access model you have chosen. For Jitsi, the handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. For BigBlueButton, Greenlight can provide room management, and external login through OpenID Connect is configured with environment variables, with Keycloak suggested for additional sign-in methods. Test that presenters can start sessions, that moderators hold the right permissions, and that guests can join without an account where you intend them to. Done means each webinar type has a documented room, a tested moderator role and a tested guest path.
Run rehearsal webinars at target audience size
Hold rehearsals that approximate your largest expected audience, using test accounts or a volunteer group, and watch CPU, memory, bandwidth and video bridge load during the session. For Jitsi, the scalable setup guide says videobridges scale horizontally by adding more, and it suggests sizing for the central server and each bridge. For BigBlueButton, the install docs give a single-server baseline, and pooling more servers is a separate design, so ask your implementation partner what audience size one server supports in your environment. Test recording and streaming output, including Jibri capacity and storage for each recording. Done means the rehearsal produces a written load summary and a recording you have reviewed end to end.
Cut over registration links and train presenters
Replace registration links, calendar invitations and reminder emails with the new room addresses and the new registration tool, and retire the Zoom links after a published notice period that your communications team sets. Train presenters on starting sessions, sharing slides and screens, handling Q&A and running polls on the new platform, and give them a rehearsal slot before their first live event. Keep a fallback plan and a named contact for the first live webinars. Done means every scheduled webinar points to the new platform, each presenter has completed a rehearsal, and the Zoom links are no longer published.
What do buyers ask before replacing Zoom Webinars?
What does it cost to replace Zoom Webinars with self-hosted software?
The software license is not the main cost. Self-hosted Jitsi Meet and BigBlueButton are open source, so the recurring costs are servers, bandwidth, TURN relay capacity, recording storage, and the staff time to implement and operate the platform. Infrastructure costs scale with the number of concurrent viewers, the number of streams you run, and how many hours of recordings you keep. Implementation is usually a one-time cost, while hosting, monitoring, patching and upgrades recur. Ask any quote to split these components separately, state which cloud or data center costs are included, and name who pays for each line, including your own staff time.
How long does a webinar platform migration from Zoom take?
Duration depends on the scope you agree in writing, not on a fixed template. The main drivers are how many event formats you need (live streamed town halls, presenter-led webinars, or interactive sessions), whether registration and Q&A tools must be replaced or integrated, how many recordings must be archived from Zoom before the account closes, and how many users need training. Infrastructure provisioning and network testing, especially for UDP reachability and TLS certificates, often sets the pace for the first event. Ask the provider to break the timeline into phases with named deliverables and acceptance tests.
What does my team have to provide for the migration?
Expect to supply the people and access that only your organization holds. That means a named owner for the event calendar, an identity contact for single sign-on, a DNS and certificate process, network changes for firewall rules, and access to your cloud or data center accounts. You will also need staff who can answer for speaker onboarding, attendee communications and the approval of any recording that leaves the network. Ask the provider which of these tasks sit in their scope and which fall to your team, and write those responsibilities into the statement of work.
Can our own IT team run a self-hosted webinar platform without outside help?
Yes, if your team has Linux server administration, network and TLS experience, and the time to keep the platform patched. Jitsi publishes Docker and Debian or Ubuntu packages, and BigBlueButton installs with bbb-install.sh on Ubuntu 24.04, so a capable team can start alone. The harder parts are sizing for large audiences, configuring authentication, building recording and archiving, and testing live events under load. Many organizations split the work, keeping day-to-day operations in house and buying implementation or retained support for the first events. Confirm your skill gaps before deciding.
Which registration and Q&A tools should we pair with the platform?
BigBlueButton covers polling, chat and breakout rooms, but it does not provide a full webinar registration workflow, so most teams add a registration tool and a separate Q&A channel. For BigBlueButton room access, Greenlight is the room manager front end, and Greenlight v3 can use OpenID Connect, with Keycloak suggested for additional login methods. For Jitsi, access control is handled through its authentication options, including JWT tokens, which let your registration system issue meeting access. Before choosing, confirm with each vendor how registrant data is stored, whether it can stay on your servers, and how attendee emails and questions are exported.
How do large audiences change the server sizing?
Audience size drives the number of media servers, the bandwidth, and the way you distribute load. For Jitsi, the scalable setup guide says videobridges scale horizontally by adding more, and it suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. BigBlueButton 4.0 needs at least 16 GB RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth per server, and it recommends a clean install. Scaling out means more servers, a load balancer or pooling layer such as Scalelite, and a plan for TURN capacity. Ask your provider to test your expected peak concurrency, not average use.
What ongoing effort does a self-hosted webinar platform need after launch?
Plan for recurring work in patching, upgrades, monitoring, backup verification, certificate renewal and capacity review. Each new release of Jitsi or BigBlueButton needs testing before rollout, and BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so older installations need a clean server build. Recording storage grows with every event, and retention rules must be enforced. Ask for a written operations runbook, the response expectations your team needs, and whether upgrades and continuous testing are included in a retainer or quoted separately.
How DeployOpen scopes a webinar platform replacement
This sequence turns a Zoom Webinars renewal decision into a written, fixed-scope plan for a self-hosted Jitsi or BigBlueButton webinar environment that runs inside your own infrastructure. Each step ends with a document or check the client can review before any build work starts.
Inventory current webinar use and evidence
DeployOpen starts by listing how your organization uses Zoom Webinars today: audience sizes, registration flows, panelist roles, Q&A and polling, recording and captioning needs, and which Zoom reports, integrations and retention rules matter for audit. Your team supplies access to the admin console and sample event records, and DeployOpen returns a written inventory that marks each item as replace, complement or retire. The step is complete when your stakeholders have signed off the inventory.
Choose Jitsi, BigBlueButton or a split design
Using the inventory, DeployOpen compares the two self-hosted options against your webinar patterns. Jitsi Meet suits live streaming through Jibri, while BigBlueButton suits presenter-led sessions with slides, polling and breakout rooms, and some organizations need both. The output is a short decision memo listing gaps, such as registration, Q&A and audience-scale limits, and the third-party tools needed to close them. The step is done when you accept the platform choice in writing.
Size servers, bandwidth and recording storage
DeployOpen maps expected concurrent viewers and recording length to server counts, bandwidth and disk. For BigBlueButton 4.0 the supplied specification is at least 16 GB of memory, 8 CPU cores, 500 GB of disk for recordings and 250 Mbit/s symmetrical bandwidth per server, and Jitsi scales by adding videobridges. DeployOpen gives you a sizing worksheet with assumptions you can change, and you confirm the assumptions against your real event history before procurement. The step closes with an approved capacity plan.
Define the architecture and security controls
DeployOpen documents the target design: hostnames and HTTPS certificates, firewall rules for the required TCP and UDP ports, TURN for restrictive networks, the authentication model such as JWT tokens or an identity provider, and how the BigBlueButton API secret is kept out of web pages. Hardening baselines, logging and access roles are written into the same design. The deliverable is an architecture document and a control list that your security team reviews.
Implement, integrate and harden the platform
DeployOpen installs the chosen platform inside your cloud accounts, data center or network using the vendor-supported install path, then connects registration, single sign-on, streaming targets and the recording store specified in the design. Hardening follows the approved control list. Acceptance is a test event that proves registration, presenter roles, live streaming, recording capture and Q&A tooling work end to end, with results recorded in a test log.
Test security and webinar behavior
DeployOpen runs security testing against the web front end, the APIs and the infrastructure, and checks that the webinar workflows behave under the load profile from the sizing step. Findings are ranked, fixed or accepted by you in writing, and retested. The output is a test report and a retest record. Penetration testing and load testing are scoped separately so that you know exactly what each covers.
Document, back up and hand over operations
DeployOpen writes the runbooks your operations team needs: deployment, upgrades, backup and restore of recordings and configuration, certificate renewal, and a host of routine tasks for events. Your staff are trained on the platform, and a compliance evidence pack is assembled for your auditors, who issue any formal reports. Handover is complete when your team runs a live rehearsal without DeployOpen present.
Agree ongoing support in writing
After handover, you choose between a standalone support arrangement and a retainer covering upgrades, continuous testing and patch cycles. The retainer scope, response expectations and deliverables are written into the contract before work begins. Each engagement is fixed-scope, and a quote follows from the written scope, so ask for line items covering implementation, testing, documentation and support separately.
