Migrate from Cisco Meeting Server to Jitsi Meet: what the move involves
Moving from Cisco Meeting Server to Jitsi Meet is an architecture change, not a file copy. Meeting Server has no export path that carries spaces, users, call policies or registered endpoints into a Jitsi deployment, so the work is to design the replacement and rebuild each function on it. The usual pattern is an internal platform or unified communications team doing the design, operations and cutover, with an implementation partner supplying deployment, integration and hardening where the team lacks capacity. Jitsi Meet is licensed under Apache 2.0 and has no license server, so there is no Smart Licensing registration to carry across. What you pay for is the infrastructure, the people who run it and any support contract you choose to buy. The effort concentrates in four areas. First, authentication: the older secure domain method is deprecated for new installations, so plan for JWT token authentication with a separate anonymous domain for guests, and confirm which identity source your users will sign in through. Second, room naming: Meeting Server spaces become persistent Jitsi room names, so decide the naming convention, who may create rooms, and how existing meeting links will be redirected or retired. Third, SIP: dial-in through Jigasi is a separate component with its own dial plan and interoperability testing against your call control. Fourth, endpoints: video systems registered to CUCM need a defined path, either re-registration to a different SIP target, a migration to a browser or app client, or retirement, and each choice changes user experience and support load. Plan the timeline around these four workstreams rather than a single cutover date. Ask any implementation partner for a written scope that names the authentication design, the room and naming model, the SIP test matrix, the endpoint inventory and the rollback plan, and confirm each against your own environment before work starts. Confirm also how Cisco renewal dates and any run-in period constrain your schedule, since those dates are set by your contract and Cisco, not by this page.
Which Meeting Server capabilities map cleanly to Jitsi and which need rework
This table maps the main Cisco Meeting Server functions to their Jitsi counterparts and marks each as clean, needs rework or gap. Use it to decide which workflows can move as they are and which need design work or confirmation in your own environment before you commit to a cutover plan.
| Capability | Meeting Server behavior | Jitsi equivalent and status |
|---|---|---|
| Call Bridge and media capacity | Call Bridge hosts calls and media on CMS hardware or VMware hosts, scaled by adding nodes | Videobridges scale horizontally by adding more. Needs rework: size central server and bridges for your peak load and confirm with a test. |
| Meeting Management and control | Meeting Management provides administration, call control and reporting for CMS | Prosody and Jicofo handle signaling and conference focus, with no direct console equal to Meeting Management. Gap: reporting and admin workflows must be rebuilt. |
| Spaces and persistent rooms | Spaces hold a fixed URI, PIN and access settings for recurring meetings | Persistent room names on your domain. Needs rework: recreate each space as a room name and communicate new links to users. |
| User authentication | Users sign in through configured directory or CMS accounts | JWT tokens from your application or internal XMPP accounts, LDAP or Matrix options. Needs rework: confirm the chosen method against your identity provider. |
| Guest access | Guests join spaces with a URI and optional passcode | Separate anonymous domain for guests when JWT is used. Needs rework: confirm guest join, lobby and passcode behavior in a pilot. |
| SIP dial-in | CMS accepts SIP endpoints and interoperates with CUCM and other SIP systems | Jigasi acts as a SIP gateway. Needs rework: test dial-in numbers, codecs and SIP trunk configuration with your CUCM. |
| Recording and streaming | CMS recording is provided through its recording components and licensing | Jibri handles recording and streaming as an optional container. Needs rework: plan storage, retention and consent workflows. |
| CUCM-registered video endpoints | Room systems register to CUCM and dial CMS spaces | No native CUCM registration to Jitsi. Gap: endpoints need a SIP path through Jigasi or a replacement client, so confirm each device model. |
How Jitsi's components take over the Meeting Server roles
A self-hosted Jitsi Meet deployment splits the work that Cisco Meeting Server concentrates in a few appliances or VMs across separate components. The web front end (nginx or Apache) serves the browser app, Prosody acts as the XMPP server that holds signaling and accounts, Jicofo is the conference focus that creates and manages conferences, and one or more Jitsi Videobridge (JVB) instances carry the audio and video media. The closest match to Meeting Server's Call Bridge is the videobridge pool, while Jicofo and Prosody take on the call control that Call Bridge and Meeting Management share. Confirm with your Cisco design team which CMS functions your users actually depend on before you map them one to one, because Jitsi does not provide a direct equivalent of Meeting Management's administration console.
Jigasi and Jibri are optional. Jigasi is the SIP gateway that lets room participants dial in from telephones or SIP endpoints, so it is the component to scope if your users rely on SIP dial-in today. Jibri handles recording and streaming and is a separate component that you add only if you need it. The official Docker setup runs the web, prosody, jicofo, jvb, jigasi and jibri pieces as separate containers, which lets you scale the videobridge containers independently of the rest. In a Docker deployment, the environment file .env controls how these containers talk to each other and to your domain, so review it as part of your configuration baseline.
Plan the sizing around the videobridges, since they are the component that scales horizontally. The Jitsi 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, and notes that the default install is already configured for horizontal scaling. Those are starting points from the vendor documentation, not a capacity estimate for your meeting load. Ask your team to measure concurrent participants and peak hours on the current Meeting Server, then test a single videobridge under realistic traffic before you commit to a count. Also confirm that the UDP media ports (10000/UDP for the videobridge in the quick start) are open between the bridges and your endpoints.
What data and integrations move, and what must be rebuilt
Moving off Cisco Meeting Server is less a file transfer than four separate work streams: user identity, room inventory, SIP dial-in and CUCM-registered endpoints. Each one has a different owner and a different point where it can break, so plan and test them separately. Confirm every Meeting Server export step against Cisco documentation for the version you run, because this page does not assume a bulk space export format.
User identities and sign-in
Jitsi does not read Meeting Server accounts, so identities must be re-established in the target. In the Docker .env file, choose between internal XMPP accounts, JWT tokens, LDAP, Matrix user verification or a hybrid Matrix plus JWT mode. Map each Meeting Server user group to one of these, then test moderator rights and guest access before any cutover. JWT is the option the Jitsi handbook recommends for new installations, with a separate anonymous domain for guests.
Spaces rebuilt as persistent room names
Meeting Server spaces carry URIs, owners and access settings that have no direct equivalent in Jitsi. Jitsi rooms exist when someone joins them, so each space you keep becomes a persistent room name agreed with its owner. Build an inventory of active spaces, their owners and their recurring use, then decide which names move and which are retired. Any naming convention should be set before users receive new links.
SIP dial-in routing through Jigasi
Legacy SIP callers reach Jitsi through Jigasi, the optional SIP gateway container in the Docker setup. Confirm which dial-in numbers and SIP URIs your organization publishes today, then decide how each one routes in the new platform. Test audio quality and call join behavior with the same handsets and gateways your users rely on. Dial-in plans are often the least documented part of a Meeting Server estate, so review them with telephony staff early.
CUCM-registered video endpoints
Room systems and desk phones registered to Cisco Unified Communications Manager reach Meeting Server through SIP trunks and dial plans. Jitsi does not replace CUCM registration, so these endpoints need either a separate path into Jitsi through SIP or a planned retirement for that group. Inventory each endpoint, its dial plan entry and the meetings it joins. Ask your Cisco and telephony teams to confirm the change to the endpoint configuration before you schedule any hardware work.
Recordings and historical content
Meeting Server does not define a bulk export for spaces or recordings that this page relies on, so confirm with Cisco documentation for your version what can be retrieved. Decide which recordings must be kept for legal or records purposes and where they will live in the new platform, since Jibri is optional. Keep the retention rule in writing so the archive does not depend on a single administrator's knowledge.
Certificates and network prerequisites
Jitsi needs HTTPS with a proper domain certificate for audio and video to work, and self-signed certificates cause problems, especially on mobile clients. The quick start also requires ports 80/TCP, 443/TCP and 10000/UDP open. Check these against your firewall and endpoint policy before testing, because a missing UDP path often looks like a client fault. Verify the certificate chain on every entry point, including the SIP path.
Migration sequence from inventory to decommission
This sequence moves meetings from Cisco Meeting Server to self-hosted Jitsi Meet in controlled stages, so each group of users, spaces and endpoints is proven on Jitsi before CMS is switched off. Each step ends with a written output and a go or no-go decision.
Inventory spaces, users, endpoints and dial plans
Start by listing every CMS space, its owner, its access method (web app, Outlook or Lync add-in, SIP endpoint or dial-in number) and how often it is used. Export the user and group membership from your identity source and record which people join from CUCM-registered video endpoints, along with the SIP URIs, dial patterns and gateways that route calls to CMS. Ask your CMS administrator to confirm the Call Bridge and Meeting Management configuration so nothing is missed. Output: a single inventory sheet with one row per space and one row per endpoint. Decision gate: the business owner signs off the list, and every endpoint is tagged as move, keep on CUCM or retire.
Build a pilot on a separate Jitsi domain
Deploy Jitsi Meet on a dedicated test domain with a valid certificate, since the Jitsi handbook states that HTTPS is necessary for audio and video and that self-signed certificates cause problems, especially on mobile. Size the videobridges with the scalable setup guidance, then configure JWT token authentication through the .env file and use the separate anonymous domain for guests. Your team, or a qualified implementation partner under a written scope, performs the build and the load test. Output: a working pilot with a tested token issuer and a load test report. Decision gate: pilot users complete calls from browsers and mobile clients with no certificate warnings, and the team agrees the bridge capacity is adequate for the pilot group.
Recreate spaces as persistent room names
Map each approved CMS space to a Jitsi room name that follows a naming convention, and generate the room links or tokens that the token issuer will sign. Decide which rooms are persistent and which are created per meeting, and document how a room is named when a user creates it from a calendar invitation. Confirm that the calendar integration reflects the new links and remove the old CMS links from templates in the same change. Output: a room register that lists each room name, owner and access rule. Decision gate: the owners of the top-priority spaces have reviewed and accepted their new room names.
Test SIP dial-in through Jigasi
If endpoints or dial-in participants must join by SIP, deploy Jigasi and test each dial pattern from your inventory against a real gateway or SIP trunk. Confirm that the signalling and media paths your CUCM and gateways use are supported by your chosen configuration, since SIP interoperability is one area where the CMS integration may be more involved and Jitsi may need extra work or a different endpoint path. Keep endpoints that cannot be moved on CUCM until a working path exists. Output: a dial-in test matrix with pass or fail for each pattern. Decision gate: every pattern marked for migration passes, and any failing pattern has a documented workaround or stays on CMS.
Run a parallel period with a defined group
Choose a defined group of users and rooms that will use Jitsi and CMS side by side for a set period agreed in advance. Collect feedback on audio quality, screen sharing, join reliability and the calendar experience, and record any incidents in a shared log. Compare bridge utilization against the pilot figures and adjust videobridge capacity if the group grows. Output: a parallel-run report with incident counts, user feedback and any changes made. Decision gate: the group confirms that its meetings can run on Jitsi without CMS, and the operations team has run its runbook at least once.
Cut over users and endpoints
Move the remaining users and rooms in planned waves, updating calendar templates, endpoint directories and CUCM dial plans as each wave goes live. Confirm the production certificate on the proper domain, check that the rate of failed joins stays within the threshold set in the runbook, and keep a rollback path to CMS for each wave. Tell users which links have changed and provide a short help page. Output: a cutover log per wave and an updated dial plan. Decision gate: no wave is considered complete until its last meeting in the log completes without a rollback.
Decommission CMS and release licenses
After the final wave is stable, export the CMS configuration and recordings you need to keep, then remove CMS spaces, endpoint registrations and CUCM trunks that pointed to it. Ask your Cisco account team to confirm the steps for releasing Smart Licensing entitlements and deregistering Meeting Management, and cancel support renewals that no longer apply. Keep the backups for the retention period set by your records policy. Output: a decommission record listing removed components, released licenses and archived data. Decision gate: the CISO and the service owner sign off the record and confirm that no production dependency on CMS remains.
How the migration differs for enterprises, universities and air-gapped sites
Enterprises usually run Cisco Meeting Server alongside Cisco Unified Communications Manager, SIP trunks and a registered fleet of room and desk endpoints. The migration scope therefore covers call routing and dial plans as well as meetings. Jitsi Meet has no native equivalent of CMS Call Bridge or the CUCM integration, so the SIP side is handled by Jigasi and the trunk configuration must be rebuilt and tested.
- Dial plan rebuild: Map every CUCM route pattern that currently reaches CMS to a Jigasi entry point, and confirm the trunk codecs and SIP signaling with your carrier or CUCM administrator.
- Bridge scaling: The scalable setup guide says videobridges scale horizontally by adding more. Start with the suggested 4 CPU, 8 GB central server and 4 or 8 CPU, 8 GB bridges, then size from measured peak concurrency.
- Endpoint transition: Endpoints registered to CUCM keep working on their current path until you reroute them, so plan a phased move by site or department.
- Identity: Choose JWT or the Matrix and JWT hybrid mode, using the directory integration your identity team already runs.
- Network: Open 10000/UDP for media and confirm firewall rules for each bridge.
Before cutover, run a parallel pilot with real dial-in and room endpoint calls, and confirm with your security team how call metadata is logged.
Universities and training teams often use CMS spaces for lectures, office hours and cohort sessions, and connect meetings to a learning management system. The scope is mostly web and browser access, with fewer SIP endpoints. The key question is whether the LMS can link to Jitsi rooms with JWT-signed access, since room creation and attendance tracking will depend on that integration.
- Room naming: Replace CMS spaces with persistent room names that follow a course or department convention, and document who may create them.
- Authentication: Use JWT tokens issued by the LMS or single sign-on provider, with a separate anonymous domain for guests such as external examiners.
- Recording: If lectures must be recorded, Jibri adds its own host requirements, so size those hosts separately from the bridges.
- Dial-in: Confirm whether students need phone access. Jigasi provides SIP gateway functions, but test every number and PIN flow before the term starts.
- Scale peaks: Map timetables to peak concurrency, since a full lecture hall can exceed a typical small deployment.
Verify the LMS plugin or custom integration against your current CMS workflows, and confirm accessibility requirements for captions and screen sharing with the teaching staff.
Air-gapped and disconnected networks change the migration more than the feature set. Jitsi needs no license server, but every component, package and container image must arrive through an approved transfer path, and HTTPS needs a certificate that the internal trust chain accepts. The Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients, so the internal certificate authority must be planned early.
- Artifact transfer: Stage Docker images or Debian and Ubuntu packages, including OpenJDK 17, through your media transfer process, and record checksums for each release.
- Certificates: Issue a certificate from your internal CA that clients trust, and test it on the device types your users actually run.
- Updates: Define how new stable builds are reviewed and imported, because the network cannot pull updates directly.
- Scope of licensing: CMS licensing through Smart Licensing and Meeting Management registration must be understood separately, since it is not part of the Jitsi path.
- Operating system support: Confirm that your approved operating system version is one the Jitsi quick start supports.
Before approval, have your accreditation or security authority review the transfer procedure, the certificate design and the update process.
What drives migration cost and duration, and how to keep each down
This table lists the main factors that move the cost and length of a move from Cisco Meeting Server to self-hosted Jitsi Meet, with why each one matters and how to reduce it. Use it to shape the scope you send for a written quote, since the largest drivers are usually the number of spaces, identity integration and the SIP path from CUCM.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Spaces and persistent room names | Each CMS space must be inventoried, mapped to a Jitsi room name and tested with its users. Large space counts add review and communication work. | Export and review the space list, retire unused spaces, and agree a naming convention before build starts. Ask the quote to state whether room creation is scripted or manual. |
| Identity integration | Choosing between JWT token authentication, LDAP, Matrix verification or internal accounts changes the build. Each identity source adds testing against real user accounts. | Pick one authentication model early, and document which users can create rooms. Ask the quote to name the identity provider and the test accounts it will use. |
| SIP dial plan and CUCM endpoint count | Jigasi adds a SIP gateway, so dial-in numbers, routing and the endpoints registered to CUCM all need to be mapped. Endpoint count drives test time and cutover planning. | Group endpoints by function and move them in waves. Confirm which dial plan entries still need to exist after the change. Ask the quote to list how each endpoint group is tested. |
| Recording and retention needs | Recording requires the optional Jibri component and storage sized for retained files. Retention rules and legal holds add policy and storage work. | Confirm which meetings must be recorded and for how long before sizing storage. Ask the quote to separate recording setup from retention policy work. |
| Bandwidth and bridge sizing | Videobridge count, CPU, memory and network capacity set the hardware or cloud spend. Under-sizing causes call quality problems after cutover. | Measure peak concurrent participants on CMS today, then size bridges from the Jitsi scalable setup guidance. Ask the quote to state the sizing assumptions and load test method. |
| HTTPS and certificates | Jitsi needs HTTPS with a proper domain certificate for audio and video to work, and self-signed certificates cause trouble on mobile clients. | Plan the domain and certificate process before installation. Ask the quote whether certificate issuance and renewal are in scope. |
| Internal skills | Teams that already run Linux, Docker and SIP infrastructure need less outside help. Teams new to XMPP and Jitsi components need more training and support time. | Assess skills on the team early. Ask the quote whether knowledge transfer, runbooks and operator training are included, and whether ongoing support is a separate retainer. |
Questions buyers ask before moving from Cisco Meeting Server to Jitsi
What does a move from Cisco Meeting Server to Jitsi Meet cost?
The software itself has no license fee, so the cost is the infrastructure, the people who build and run it, and any paid support you choose. Jitsi Meet is Apache 2.0 licensed, so there is no per-host or per-port license to replace, but you still pay for the servers that run the central components and one or more videobridges, the bandwidth they consume, and the engineering time to integrate authentication, SIP and monitoring. Ask any implementation partner for a quote that separates one-time work (design, integration, migration, testing) from recurring work (patching, upgrades, monitoring, on-call and support retainers). Compare that against your current Meeting Server hardware or VMware hosts, Smart Licensing renewals and Meeting Management support.
How long does a migration from Cisco Meeting Server to Jitsi take?
The timeline is set by scope, not by the software, and no fixed duration is established for this move. The main drivers are how many spaces and users you must recreate, whether you need SSO or JWT authentication, how many SIP dial-in paths go through Jigasi, how much capacity planning and load testing you require, and how many video endpoints need to be reconfigured. Running both platforms in parallel for a period is common, which lengthens the calendar but reduces cutover risk. Ask for a written scope with deliverables and milestones before work starts, since most engagements are fixed-scope and agreed in writing before work begins.
What must our internal team provide before the project starts?
Your team needs to supply the inventory and the decisions that only you can make. Gather a list of active spaces and who owns them, your identity provider details if you want SSO, the naming scheme for persistent room names, the SIP dial plan and any gateways that reach Jigasi, the hosting target for the servers, DNS control for a proper domain, and the certificate process you already use. You also need someone who can approve network changes, including the Jitsi ports (80/TCP, 443/TCP, 10000/UDP, with optional 5349/TCP and 3478/UDP) and the firewall rules for your videobridges. Early agreement on these inputs shortens the design phase and keeps the quote tied to a clear scope.
Can our own engineers migrate from Cisco Meeting Server to Jitsi Meet without a partner?
Yes, a capable engineering team can deploy Jitsi Meet, since the project publishes Docker containers and Debian or Ubuntu packages and documents both paths. The harder parts are the ones that touch your existing estate: authentication through JWT or your identity provider, SIP interoperability with your call control, capacity planning for videobridges, HTTPS certificate handling and ongoing patching. Be honest about who will carry the pager after go-live. If nobody on the team has run real-time media services before, a fixed-scope engagement for design, integration and hardening, followed by a support retainer, may cost less than the learning curve. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and you can choose which of those stages to buy.
Will Jitsi keep video endpoints registered to CUCM working?
Not automatically. Jitsi Meet is a browser and client based meeting platform, and it is not a drop-in replacement for the registration and call control that CUCM provides to room systems and desk phones. Endpoints registered to CUCM keep working with CUCM, but they do not join Jitsi rooms unless you connect them through a SIP path. Jigasi is the Jitsi component for SIP, so dial-in and some SIP interoperability go through it, and you should confirm with your own test plan which endpoint models, codecs and call flows work. Treat CUCM endpoint behavior as a scope item to validate early, not an assumption carried over from Cisco Meeting Server.
How do HTTPS and certificates affect a Jitsi rollout?
HTTPS is required for multimedia to work, so certificates are on the critical path. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Plan the DNS names for the web front end and the videobridges, decide how certificates are issued and renewed in your environment, and test with browsers and mobile apps your users actually run. Certificate issuance is often a small task in isolation but can block cutover if the internal certificate authority or DNS process is slow.
What happens to recordings made on Cisco Meeting Server?
Recordings do not move automatically, so plan an explicit export and retention decision. Jitsi recording runs through Jibri, which is optional and deployed as its own component, so a recording capability must be designed and sized rather than inherited. Identify which recordings must be kept for legal, records or training reasons, confirm where they are stored and in what format, and decide whether they are archived in your own object or file storage. Ask any implementation partner to include recording retention and access controls in the written scope, because those decisions affect storage sizing and compliance evidence.
Does Jitsi need a license server or operate differently from Meeting Server in air-gapped networks?
Jitsi does not require a license server, so there is no Smart Licensing registration to maintain on a disconnected network. Its components are deployed as Docker containers or Debian and Ubuntu packages, and updates reach an air-gapped estate through whatever offline media and internal repository process you run. Confirm the package sources, container images and build versions you will mirror, and test the upgrade path in a staging environment before relying on it. The Jitsi self-hosting guide and repository are the starting points for those checks.
What usually goes wrong in a Meeting Server to Jitsi move
Most failed Meeting Server to Jitsi cutovers trace back to a few predictable gaps: certificates, routing, authentication, capacity, network ports and CUCM-registered endpoints. Each card names one risk, what it breaks during the move, and the check to run before users are switched over.
Certificates that break media
Jitsi's handbook states that HTTPS with a proper domain certificate is necessary for audio and video to work, and warns that self-signed certificates cause problems, especially on mobile clients. Browsers may load the meeting page yet fail to start media, which looks like a bridge fault. Before cutover, test a meeting from a phone and a managed laptop using the production certificate chain, and confirm that internal clients trust the issuing authority.
Unmapped SIP routes after cutover
Meeting Server dial plans and SIP trunks map numbers to spaces and call routes that do not carry over automatically. Jigasi handles SIP dial-in in a Jitsi deployment, so each inbound number and its meeting mapping must be rebuilt and tested. Build a table that lists every dial-in number, its former space, and its new room name, then place a test call to each number from outside the network.
Guest access on the secure domain
The secure domain method, which uses usernames and passwords to create rooms, is marked deprecated for new installations in the Jitsi handbook. Teams that copy an old configuration may keep it running and end up with a model that the handbook does not recommend. Use JWT token authentication for hosts and a separate anonymous domain for guests, and confirm with a test that an unauthenticated user cannot create a room on the host domain.
Undersized videobridges
Jitsi scales by adding Videobridge instances, and the scalable setup guide suggests 4 or 8 CPUs with 8 GB of RAM for each bridge. Meeting Server sizing does not transfer one to one, so capacity planned from current CMS call counts can be wrong. Run a load test with the expected peak number of participants per conference and watch CPU and bandwidth on each bridge before retiring any CMS capacity.
Blocked UDP port 10000
The Debian and Ubuntu quick start needs 10000/UDP open for media, with 5349/TCP as a TCP fallback. Firewalls and NAT devices that were tuned for Meeting Server ports often block the new media port, so calls connect but audio or video stays dark for remote participants. Ask the network team to confirm the rules for 10000/UDP, 5349/TCP and 443/TCP on every path, including the VPN and the campus edge, and test from outside the corporate network.
CUCM endpoints with no tested path
Video endpoints registered to Cisco Unified Communications Manager do not become Jitsi clients when the Meeting Server is retired, and Jitsi does not replace CUCM registration. Each room system needs a defined route, such as a SIP join through Jigasi or a browser-based join, and a test on each model. Inventory every endpoint, record its current join method, and test one call per model before the old meeting numbers are withdrawn.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Jitsi Meet inside your own infrastructure, including the Cisco Meeting Server to Jitsi Meet migration. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which CMS spaces, call legs, SIP trunks and CUCM-registered endpoints are in use today.
- Agree in writing which meetings move to Jitsi, which stay on CMS, and which remain unsupported.
- Define the authentication model (JWT or LDAP), the room naming scheme and the videobridge sizing before build.
How we build
- Deploy the Jitsi web, Prosody, Jicofo and Jitsi Videobridge components in your cloud, data center or air-gapped network.
- Configure HTTPS with a certificate from your own domain, since self-signed certificates cause problems for clients.
- Integrate SSO or JWT tokens, set up SIP dial-in through Jigasi if it is in scope, and test each path before cutover.
How we hand over
- Document the architecture, firewall ports, configuration files and runbooks for your operations team.
- Deliver a tested cutover plan with rollback steps and a list of endpoints that need reconfiguration.
- Train administrators on room management, scaling videobridges and checking logs after the migration.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Jitsi version upgrades and test them in a staging environment before production rollout.
- Agree response expectations and service levels in the written contract, not in general terms.
