Cisco Meeting Server 2000 replacement: which option keeps meetings on-premises
No direct replacement exists for the Cisco Meeting Server 2000 M6, so the choice turns on where media and recordings must live. If meetings and recordings must stay inside your own data centers or network, the candidates are Cisco's own on-premises paths and a self-hosted open-source stack. If a cloud service is acceptable for some traffic, Webex with Webex Video Mesh keeps media local where capacity allows and overflows to the cloud when it runs out, with the service registered to the Webex cloud and managed in Control Hub. The self-hosted options are Jitsi Meet and BigBlueButton, both of which run entirely in your infrastructure with no meeting traffic leaving it. The timeline is set by Cisco's dates, which this page does not supply. Before you plan, confirm with your Cisco account team the end-of-sale date, the last date for hardware and software support, and whether the Medium series or CMS on VMware is offered for your existing licensing and call flows. Ask in writing what support covers after each date, because the answer determines how long you can run the current M6 safely. Also confirm whether your organization's data residency rules cover recordings, logs and transcripts as well as live media, since that scope narrows the cloud options quickly.
Jitsi Meet is the closer functional match for ad hoc and scheduled meetings, with media routed through Jitsi Videobridge and SIP dial-in through Jigasi. It requires HTTPS with a valid domain certificate, so plan certificate issuance and renewal before go-live. BigBlueButton is better suited to training and classroom use, and it is heavier to host: its 4.0 release calls for at least 16 GB of memory, 8 CPU cores, 500 GB of disk if you record, and 250 Mbit/s symmetrical bandwidth, and it requires a clean server install rather than an upgrade from earlier branches. The practical next step is to inventory what the M6 does for you today: the spaces and call flows in use, SIP and CUCM integration, recording needs and the endpoints registered to the platform. Each item maps to a different answer. Live meetings and SIP dial-in point toward Jitsi, classroom tools point toward BigBlueButton, and any requirement that video room systems register to the same platform may keep part of the decision with Cisco. Note which of these needs you cannot confirm yet, and resolve those with Cisco and your security team before choosing.
What an on-premises video constraint requires
Staying on premises fixes where media, recordings and traffic must live, and it sets the hardware and network floor for any replacement. The cards below cover the requirements an open-source stack must meet before a Meeting Server 2000 successor is sized, tested and approved.
Recordings stay on your storage
Recording files are often the largest data set a video platform creates, and they carry the same residency rules as the meetings themselves. Plan a dedicated volume for them from the start. BigBlueButton 4.0 expects 500 GB of disk for recordings on a server that records, and 50 GB without recording. Ask each candidate where recording files are written, how long they are kept, and who can retrieve them.
HTTPS with a valid certificate
Browsers and mobile clients need HTTPS with a certificate for a proper domain before audio and video work reliably. The Jitsi handbook warns that self-signed certificates cause problems, especially on mobile clients. Your internal certificate authority must be trusted on every device that joins, and certificate renewal needs an owner before go-live. Confirm this with your PKI team early, since it affects guest access from outside the network.
Open UDP media ports
Video and audio travel over UDP, so firewall policy matters as much as the application. Jitsi needs 10000/UDP for media, plus 80/TCP and 443/TCP for the web app, with 5349/TCP as a TCP fallback and 3478/UDP for STUN as optional. BigBlueButton needs UDP ports 16384 to 32768. Ask your network team to confirm these paths through segmentation and any SIP or perimeter devices before the pilot.
Bandwidth and server capacity
Media load is set by the number of concurrent participants and the bandwidth each site can carry. BigBlueButton 4.0 asks for at least 16 GB of memory, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth per server. Jitsi recommends separate videobridges that scale horizontally. Measure peak concurrent meetings from your Meeting Server logs and compare them with these requirements before sizing.
Trusted TURN for restrictive networks
Some users sit behind firewalls that block direct media paths, and they will fail to connect without a relay. BigBlueButton's install guidance recommends a TURN server for these users. Decide whether your environment needs a self-hosted TURN service, where it sits, and how it is monitored. Confirm the approach with the candidate vendor or community, since the relay design changes the port and bandwidth plan.
Ownership of the support model
On premises, your team owns patching, backups, monitoring and upgrades, because no vendor cloud absorbs them. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so an older deployment needs a clean installation. Name the operator, the on-call path and the upgrade calendar in writing. Paid support from a vendor or implementation partner is an option to price separately.
Which replacement fits which environment
Cisco's Medium series is the hardware route most owners of the Meeting Server 2000 M6 will ask about first. The material available here does not describe its form factor, supported software, licensing model or lifecycle, so treat every answer as an open question for your Cisco account team until it is confirmed in writing.
- On-premises fit: If the platform is deployed in your own data center, media and call control stay on your premises. Confirm the deployment model and any cloud component in writing.
- Licensing: Ask whether Smart Licensing and Meeting Management carry over unchanged, and whether licenses are tied to specific hardware.
- Lifecycle dates: Ask for the end-of-sale and end-of-support dates for the Medium series and for the software release it runs.
- Migration path: Ask whether spaces, dial plans and CUCM integrations move over, or must be rebuilt by your team or a partner.
- Costs: Ask for the hardware purchase, the recurring support contract and any licensing fees as separate line items.
Before you commit to another Cisco platform, check these answers against your room system inventory and your regulatory requirements for where media is processed.
Cisco Meeting Server is offered on Cisco hardware or on VMware, so running it as virtual machines keeps the same product and administration model while changing the host. For an owner who must keep meetings in the organization's own data center, this is the option that stays closest to the current setup. Moving to VMware changes the host, not the platform's support dates, so confirm those dates separately.
- Same product, new host: Call Bridge and Meeting Management workflows stay familiar, which reduces retraining. Confirm the supported VMware versions and the CMS release with Cisco.
- Capacity: Media load depends on the host CPU, memory and network. Ask Cisco for sizing guidance for your expected concurrent participants before you buy hosts.
- Licensing: Confirm whether moving to VMware changes license counts or the way PMP and SMP licenses are assigned.
- Support boundary: Ask who supports the hypervisor, the guest operating system and the CMS application when a single incident spans all three.
- Recurring cost: Expect hypervisor licensing and support, if you do not already hold them, to be a recurring cost alongside Cisco support.
Check the hypervisor support matrix and the support boundary in writing before your virtualization team starts work.
Webex Video Mesh is a hybrid model. It is software installed on an on-premises Cisco UCS server and registered to the Webex cloud, and it is managed in Control Hub. Meetings stay local while on-premises capacity lasts, and they overflow to the cloud when that capacity runs out. This meets part of the on-premises constraint, but the management plane and any overflow traffic depend on the cloud, so it needs review against your residency rules. The Video Mesh deployment guide sets out the supported setup.
- Local media: Meetings that fit on-premises capacity are kept local, which is the main on-premises benefit.
- Cloud dependency: The server must register to the Webex cloud and is administered in Control Hub, so a cloud outage or sign-in problem affects administration.
- Overflow policy: Ask how overflow is configured, whether it can be restricted for regulated meetings, and who approves that setting.
- Hardware: It runs on an on-premises Cisco UCS server, so confirm the supported models and specifications in the deployment guide.
- Recurring cost: Webex licensing and Video Mesh costs recur, so ask for per-user and per-server pricing in writing.
Before you choose this option, confirm with Cisco and your compliance team whether overflow traffic and cloud management are acceptable for the data you handle.
Self-hosted Jitsi Meet and BigBlueButton run entirely inside your own data center, private cloud or air-gapped network. Media and administration do not depend on a vendor cloud, so this option meets the on-premises constraint most fully. The trade-off is that your team, or the implementation partner you choose, runs the servers, networking and updates. The Jitsi self-hosting guide describes the components and their requirements.
- Jitsi requirements: Debian 12 or Ubuntu 24.04 or newer, OpenJDK 17, and ports 80 and 443 over TCP plus 10000 over UDP. HTTPS with a proper domain certificate is necessary for audio and video to work.
- BigBlueButton requirements: At least 16 GB of memory with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings, 250 Mbit/s symmetrical bandwidth, and UDP ports 16384 to 32768. Ubuntu 24.04 is the supported platform for version 4.0.
- Integration gaps: Video endpoints registered to CUCM are not a drop-in fit. Jitsi reaches SIP through its Jigasi gateway, and BigBlueButton does not try to replace room systems. Confirm which endpoints and SIP flows you must keep.
- Cost components: There is no license fee for the open-source software. Servers, bandwidth, operations staff and any paid support are the costs to quote.
- Recurring work: Plan for recurring patching, certificate renewal and capacity review, whichever platform you choose.
Before you choose, confirm the endpoint types, SIP needs and bandwidth at each site, since these decide whether the open-source platform can carry your current meetings.
How to deploy under the constraint
This sequence turns a Meeting Server 2000 retirement into a working self-hosted meeting platform, with sized hosts, a trusted certificate, a chosen package path, proper authentication and room for growth. Each step ends with a check you can verify before moving on.
Size the hosts before ordering anything
Your infrastructure or platform team sizes the servers against the vendor requirements for the platform you pick, and confirms the network can carry the load. 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 RAM for each videobridge. For BigBlueButton 4.0, plan for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if you record (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Done when the host list, sizing and bandwidth figures are signed off against your expected concurrent meetings, and you have asked your platform team to confirm them in your own environment.
Obtain a proper domain certificate
Your network or security team requests a publicly trusted certificate for a hostname that resolves to the front end, and confirms that ports 80/TCP and 443/TCP are reachable where the platform needs them. Jitsi's handbook states that HTTPS is necessary for audio and video to work, and warns that self-signed certificates cause problems, especially with mobile clients. BigBlueButton also needs a valid hostname for SSL. Done when the hostname resolves correctly from inside and outside the network and a browser on a phone loads the front end without warnings.
Choose the package path for the platform
Your platform engineers pick how the services are installed. Jitsi offers Debian and Ubuntu packages, which its quick start supports on Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer with OpenJDK 17, or the official Docker setup, which runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers. Docker suits teams that already operate container hosts and want rootless, read-only containers, which the project has run since stable-11146. Confirm that UDP port 10000 and the other optional ports are open before the first test. Done when a single test meeting connects with audio and video between two browsers on separate networks.
Set JWT authentication and retire secure domain
Your identity and application teams configure how users join rooms. The Jitsi handbook marks the older secure domain method, with username and password room creation, as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. Settings are made through the environment file for Docker deployments, and the Docker guide also lists LDAP and Matrix-based options if your directory or chat system requires them. Map each CMS user group to the token claims your application issues. Done when an authorized user joins a room through your application, an unauthenticated request to a restricted room is refused, and guests land on the anonymous domain.
Scale videobridges horizontally
Your platform engineers add videobridge nodes as concurrent meeting load grows. The scalable setup guide notes that videobridges scale horizontally by adding more, and that the default install is already configured for this, so the work is to deploy additional bridge hosts and register them with the central components. Run a load test with the number of simultaneous participants your Meeting Server 2000 handled at peak, using test accounts and scripted clients. Done when the load test completes with each bridge carrying a share of participants and no bridge exceeding its CPU and memory budget.
Build BigBlueButton on a clean Ubuntu 24.04 server
If you choose BigBlueButton instead, your platform engineers install version 4.0 on a new Ubuntu 24.04 64-bit server using the bbb-install.sh script. In-place upgrades from 2.6, 2.7 or 3.0 are not supported, so do not attempt to upgrade an older server; build a fresh one and migrate content and room configuration by hand. Open TCP ports 80 and 443 and UDP ports 16384 to 32768, install Docker for sandboxed document conversion, and add a TURN server for users behind restrictive firewalls. Done when a test room runs slides, audio, video and screen sharing from inside and outside the network.
Confirm the platform works against your checklist
Your service owner runs a written acceptance test covering join from managed and unmanaged devices, SIP dial-in if your room systems need it, recording storage, certificate renewal and the restart behavior of each service. Record each result so the evidence can go to your auditors. Done when every item on the list passes, the results are filed with the change record, and the team confirms in writing that the Meeting Server 2000 can be switched off without losing a required meeting path.
The dates that set the timeline and what to confirm
Build the migration schedule backward from Cisco's dates, not forward from the release calendar of the replacement. Ask your Cisco account team or reseller to confirm in writing the end-of-sale date for the Meeting Server 2000 M6, the last date for software updates and security fixes, the end of Cisco support for the platform, and the expiry of any PMP Plus or SMP Plus licence terms you hold. Also confirm when your hardware support contract ends. The earliest of these dates, usually the end of security fixes, sets the cutover deadline. Record each date, who confirmed it and when, so the schedule can be checked against the source later.
The open-source releases give you fixed points to plan around, but they do not set the deadline. Jitsi Meet stable/jitsi-meet_11248 was published on September 14, 2026, and BigBlueButton 4.0.0 was released on October 14, 2026. Note that BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a test environment should start from a clean Ubuntu 24.04 server with the bbb-install.sh script, not from an existing BigBlueButton install. Confirm the current minimum hardware and bandwidth in the installation documentation before you order anything, since requirements change between releases.
Once the Cisco dates are confirmed, work backward through the phases: hardware or cloud procurement, a pilot with a small group, a parallel run with CMS, cutover and finally decommissioning. Lead times for hardware, change approvals and user training are set by your own organization and your vendors, so ask each of them for their figures rather than assuming them. If the schedule shows a gap between the confirmed Cisco dates and your readiness, decide early whether to extend support, keep a smaller CMS footprint for specific users or accept a temporary overlap. Put that decision in front of the steering group before the gap becomes urgent.
Evidence auditors and regulators ask for
Auditors and regulators rarely accept a video platform on its feature list alone. They ask where media and recordings sit, how traffic is protected and who can reach the system, and they want those answers in records that exist before the assessment starts. The cards below cover the records to build and keep for whichever platform you choose.
Architecture and data flow
Draw where each component runs, including the web front end, the signaling server, the media servers and any recording host, and mark which network zone each one sits in. Show the path of audio, video, chat and recording files from the browser to storage and back out. For a Jitsi deployment this means naming the web, Prosody, Jicofo, Jitsi Videobridge and, if you use it, Jibri hosts. Ask the vendor or integrator to confirm which of these components keep data on disk and for how long.
Certificate and TLS configuration
Record the certificate authority, the domain names it covers, expiry dates and the renewal method. Jitsi's handbook states that HTTPS is necessary for multimedia to work and warns that self-signed certificates cause problems, especially with mobile clients, so keep the certificate chain as evidence that the production setup uses a domain certificate. Document the TLS versions and cipher settings your reverse proxy enforces.
Firewall and port documentation
Keep a table of every inbound and outbound port, its protocol, its source and its destination. The Jitsi quick start lists 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP and 3478/UDP optional. BigBlueButton 4.0 needs TCP 80 and 443 and UDP 16384 to 32768. Tie each rule to a stated business need so a reviewer can see why it exists and who approved it.
Access and authentication settings
Record which login method each room type uses, who administers the server and how admin accounts are protected. For Jitsi, the handbook recommends JWT token authentication over the deprecated secure domain method and a separate anonymous domain for guests. Capture the .env settings for the chosen authentication mode, the list of administrators and the review cadence for that list. Remember that Greenlight also needs its own sign-in configuration.
Backup and update records
Keep a dated log of every platform update, the version applied, the test result and the rollback plan. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a migration record should show a clean installation and the data moved into it. Record backup schedules, restore tests and where backup copies are stored, because an auditor will ask for a restore test, not only a backup job.
Retention settings for recordings and transcripts
Write down how long recordings, chat logs and transcripts are kept, where they are stored and who can download them. Compare this with the file formats your current Cisco Meeting Server recordings and any cloud recordings produce, since each format may need its own handling. Confirm the deletion method and keep a record of each deletion run, so retention can be shown as enforced rather than assumed.
Questions buyers ask before choosing a replacement
What does a self-hosted video replacement cost to run?
Jitsi Meet is Apache 2.0 licensed, so the software itself carries no license fee, and the cost sits in the components around it. Budget for servers or VMware hosts, bandwidth, staff time to build and operate the stack, and paid support if you want it. Hardware is usually a one-time purchase or a recurring rental, depending on whether you own or rent capacity. Staff time, bandwidth and support recur every year. Costs rise with concurrent participants, recording volume and the number of sites that need media capacity. Ask for a quote that separates build work, hardening, integrations, backups and any retainer, and ask which lines recur.
How long does moving off our current video server take?
The timeline depends on how many spaces, SIP and room endpoints, integrations and recordings you have, and on how many sites need media capacity. Your Cisco end-of-sale and support dates set the deadline, so confirm them in writing with Cisco or your reseller before you commit to a plan. A typical sequence is to size the target platform, run a pilot with a small group of spaces, then move users in waves. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a fixed-scope plan with milestones and a clear list of what is out of scope.
Can our own team run Jitsi or BigBlueButton?
Yes, if your team already manages Linux servers, DNS, certificates, firewalls and UDP traffic. Jitsi's Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer, requires OpenJDK 17, and needs 80/TCP, 443/TCP and 10000/UDP open. BigBlueButton 4.0 installs on a clean Ubuntu 24.04 server with bbb-install.sh. The larger ongoing effort is usually operations: upgrades, monitoring, backups and incident response. DeployOpen can plan, implement, customize, harden, back up and document the platform, then support it under a retainer, so you can keep some work in-house and buy the rest.
What hardware and bandwidth does self-hosted video need?
BigBlueButton 4.0 needs at least 16 GB of memory 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. Jitsi's scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Plan for UDP 16384 to 32768 on BigBlueButton and 10000/UDP on Jitsi. Recording and streaming add storage and CPU load. Capacity depends on concurrent participants and media quality, so test with your own meeting profile before you size hardware or contract bandwidth.
Do Jitsi Meet deployments need HTTPS and certificates?
Yes. Jitsi's handbook states that HTTPS is necessary for multimedia to work, and it recommends a certificate issued for a proper domain. Self-signed certificates cause problems, especially with mobile clients, so confirm that every device trusts your certificate authority before go-live. Authentication also needs a decision. The older secure domain method is marked deprecated for new installations, and the handbook recommends JWT token authentication with a separate anonymous domain for guests. Docker deployments set options such as LDAP, Matrix verification or JWT in the .env file. Review these settings with your security team before users arrive.
Who supports a self-hosted video platform after go-live?
Your team, a paid provider, or both. Jitsi is open source, and 8x8 offers hosted Jitsi as a Service, but a self-hosted deployment remains yours to operate. BigBlueButton Inc. offers hosting and commercial support. DeployOpen supports self-hosted platforms through retainers that cover ongoing support, upgrades and continuous testing. Support fees and staff time for patching and upgrades recur, so include them in your annual budget. Ask any provider which versions it covers, its response expectations in writing, and whether upgrades are included. Existing BigBlueButton installations on 2.6, 2.7 or 3.0 cannot upgrade directly to 4.0, so ask how the move will be handled.
Will DeployOpen certify our video platform for compliance?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work. For a video platform, evidence often includes access control settings, encryption in transit, backup records and change logs. Ask your auditor which evidence it expects before implementation starts, then write those items into the scope so they are configured, collected and documented from the beginning. This keeps the assessment preparation traceable to the written deliverables.
What changes for users and endpoints during the switch
The first thing to settle is how people will get into meetings after the switch, because that drives most of the user-facing work. On Cisco Meeting Server, a space is a named meeting object with its own URI and access settings, and users typically reach it by dialing that address or opening a link. Jitsi Meet has no equivalent object. A meeting exists when someone opens a room name on the server, so the migration replaces each space with a persistent room name that is agreed, documented and published to the people who used the old URI. Confirm with the owners of the most-used spaces which names they want to keep, and whether those names should be protected by JWT token authentication so that only authorized users can create or enter them. Expect a period where old space addresses and new room links both work, and plan a date for retiring the old ones.
SIP and CUCM-registered endpoints need a separate decision. Room systems and desk phones registered to Cisco Unified Communications Manager reach Meeting Server through SIP trunks and call routing that your team configured, and none of that moves automatically. Jitsi can accept SIP dial-in through Jigasi, which is an option to confirm in your own environment rather than a drop-in substitute: check which dial patterns, call control signaling and video codecs your endpoints use, and test them against a Jigasi build before committing. BigBlueButton does not try to replace room-system features such as CUCM registration, SIP call control or hardware codec management, so endpoints that depend on those features will need a different route or continue to run on a platform that supports them. Map every endpoint to one of three outcomes (retire, re-home or keep), and write the list before the first cutover.
How DeployOpen deploys Jitsi or BigBlueButton under an on-premises constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including data centers and air-gapped networks. For Cisco Meeting Server 2000 end of sale, we start by confirming which platform fits your meeting, SIP and network requirements, then write the scope before any work begins.
How we scope
- Inventory current CMS 2000 spaces, SIP endpoints, dial-in numbers and recording needs before choosing Jitsi Meet or BigBlueButton.
- Confirm hosting location, network paths, firewall rules and whether the environment is connected or air-gapped.
- Agree deliverables, timelines and acceptance criteria in writing, as engagements are fixed-scope and quoted from that scope.
How we build
- Size the servers against the vendor requirements for the chosen platform, including BigBlueButton 4.0 memory, CPU, disk and bandwidth needs.
- Configure HTTPS with a proper domain certificate, required for working audio and video, and open the documented ports.
- Set up authentication, such as JWT tokens or OpenID Connect, and test call quality, recording and firewall traversal before cutover.
How we hand over
- Document the architecture, configuration, runbooks, backup procedures and upgrade steps for your operations team.
- Provide evidence of controls and settings that your internal or external auditors can review, without issuing any audit opinion.
- Walk your team through day-to-day operations and the parts of the stack you will own after handover.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan upgrades on a schedule your change process approves, including clean reinstalls where a platform release requires them.
- Ask any support provider to confirm response scope, environment coverage and what sits outside the retainer before signing.
