Migrate from Webex to Jitsi Meet

Migrate from Webex to Jitsi Meet: what moves and what does not

A Jitsi migration from Webex is mainly a meeting platform build, identity and room-system work, and recording archiving. The platform itself is the easy part to describe: a self-hosted Jitsi deployment is a set of components you run in your own infrastructure, and the open questions are how users sign in, how existing Webex room devices and dial-in habits are handled, and what happens to years of recordings before the contract ends. Teams usually arrive here because of a Webex renewal, an EU data residency requirement or concern about lock-in, and the work is typically shared by platform engineering, network and security teams working with the existing Webex administrator, who knows which meetings, rooms and users matter.

Jitsi Meet is licensed under Apache 2.0 and maintained by 8x8, Inc., which also sells hosted Jitsi as a Service, so the code can be run without a subscription to 8x8. The software is not the main cost driver. The effort depends on three things: how many SIP room systems must still dial in (handled by Jigasi), how users authenticate (internal XMPP accounts, JWT tokens, LDAP or Matrix verification, all set in the .env file of the Docker setup), and how many concurrent meetings you expect, which determines how many videobridges you run. Ask Webex to confirm, before scoping, which recording formats and download paths your site provides and whether chat history can be exported, because those answers decide how much archiving work the migration contains.

Which Webex capabilities map to Jitsi Meet and which need rework

This table compares common Webex meeting capabilities with their Jitsi Meet equivalents and marks each as clean, needs rework or a gap. Read the status column first, then the notes, and confirm every in-meeting feature against the Jitsi handbook before you commit to a cutover date.

Webex capability	Jitsi equivalent	Migration notes
Scheduled and instant meetings	Jitsi Meet rooms created on demand, with JWT or account-based room creation (needs rework)	Rooms have no native calendar invite. Plan a scheduling process or calendar integration, and confirm the room creation model you choose in the handbook.
Join by link	Clean: room URLs on your own domain	Users join from a browser or the mobile app. Train staff on the new URL pattern and confirm guest access rules on your anonymous domain.
In-meeting features (chat, screen share, reactions, breakouts)	Partial (confirm in handbook)	Core chat and screen sharing are available. Confirm each feature you rely on, including breakout rooms and polling, against the Jitsi handbook before promising parity.
Recordings	Needs rework: Jibri records to local storage	Jibri is optional and runs as its own container. Plan storage capacity, export and retention, and export existing Webex recordings before the contract ends.
Webinars and live streaming	Needs rework: Jibri live streaming	Live streaming is possible through Jibri, but registration, Q&A and attendee management are not included. Plan those separately.
SIP and room systems	Needs rework: Jigasi SIP gateway	Jigasi bridges SIP calls into Jitsi rooms. Test every room system model with your own dial plan before retiring Webex devices.
On-premises media	Clean: Jitsi Videobridge on your servers	Videobridges run on your hardware and scale horizontally. Size them from the scalable setup guide, and plan for HTTPS and UDP 10000 reachability.
Sign-in: SSO and directory	Needs rework: JWT, LDAP or internal accounts	Choose JWT, LDAP, Matrix verification or internal XMPP accounts through the .env file. Map Webex SSO groups to the method you pick.
Administration and deployment	Needs rework: .env file and Docker setup	Admin tasks are configuration changes, not a Control Hub console. Assign owners for upgrades, certificates and container updates.
Device ecosystem and Control Hub analytics	Gap	Webex room devices and Control Hub policies, usage analytics and tenant controls have no direct Jitsi equivalent. Confirm device compatibility and reporting needs with the vendor and your own environment.

The migration sequence from inventory to decommissioning Webex

This sequence moves Webex meetings to a self-hosted Jitsi Meet deployment in controlled stages, so each step produces a record that justifies the next one and nothing is switched off before recordings and contract duties are settled.

Inventory meetings, rooms and recordings
Start by listing how Webex is actually used: meeting types such as recurring team stand-ups, external calls and webinars, the room systems and dial-in devices in each site, and the recording volume and retention by owner. Record the identity source that signs users in, and every integration that touches Webex, such as calendar plug-ins, LMS links or scheduling tools. Ask Cisco or your account team which data can be exported and in what format. The output is an inventory register that names each meeting type, room system, integration and recording set, with an owner for each line.
Pilot Jitsi Meet on a dedicated host
Build a Jitsi Meet test environment on its own host, using the Debian or Ubuntu quick start or the Docker setup, with the operating system versions the Jitsi handbook lists. Obtain a proper domain certificate and serve the site over HTTPS, because Jitsi's documentation states that HTTPS is necessary for audio and video to work, and self-signed certificates cause problems, especially on mobile clients. Open the required ports, including 10000/UDP for media, and test desktop, browser and mobile joins across the networks your users actually use. Choose an authentication method before the pilot ends, since the handbook recommends JWT token authentication over the deprecated secure domain method. The output is a pilot acceptance record listing test cases, results, known defects and the approved authentication setup.
Run Jitsi and Webex in parallel
Let users keep Webex for meetings already scheduled with external parties, while new internal rooms are created on Jitsi. Publish a short guide covering how to start a Jitsi room, how to share links and how to report problems, and watch support tickets, join failures and audio or video quality during this period. Size videobridges against observed load using the scalable setup guide as a starting point, and add bridges if the monitoring shows strain. Keep the room systems on Webex during this step. The output is a parallel-run log with incident records and a list of capacity changes made.
Cut over by department or room system
Move groups in planned waves, either by department or by room system, so that a single group's failure does not affect the whole organization. For each wave, write a cutover runbook that lists the scheduling changes, calendar updates, client rollout, SIP gateway configuration through Jigasi for any room devices that dial in, and the rollback steps. Confirm each wave with its owner before moving the next. Where a room device cannot yet reach Jitsi, record it as an exception with an owner and a decision date. The output is a signed-off cutover runbook per wave and a register of open exceptions.
Archive recordings and confirm obligations before decommissioning
Export Webex recordings and any transcripts or chat files you need to keep, and store them in your own archive with checksums and metadata that tie each file to its meeting, owner and retention class. Record what cannot move, such as data tied to Webex-only features, so that the archive gap is known. Before turning off Webex, have legal and procurement confirm the contract terms that govern data return, notice periods and final invoicing. Remove Webex users, integrations and room device registrations only after those checks pass. The output is an archive manifest with verification results and a written confirmation of contract obligations, followed by a decommissioning record.

Which data and integrations you need to move or rebuild

Moving from Webex to Jitsi Meet is less about the meeting itself and more about what surrounds it: recordings, identities, invitations, room systems, certificates and storage. Each item below has a different owner, and each needs confirmation from Webex or your own IT team before cutover planning starts.

Archived Webex recordings

Recordings and transcripts are the one item Webex does not move for you. Decide which recordings must be kept, then confirm with Webex which export paths, batch options and file formats your site supports before you plan storage. Ask whether transcripts and chat are included, and whether the export runs per user or per site. Records owners, such as legal or compliance, should approve what is retained and for how long, because Jitsi Meet does not inherit Webex retention settings.

User and host identities

Webex hosts are tied to Webex accounts, but Jitsi Meet needs its own identity model. Choose between internal XMPP accounts, JWT tokens, or LDAP through the .env configuration, and map each current Webex host to an account or claim. Your identity team owns the directory and decides who may create rooms. Confirm with your IT team which directory is the source of truth and whether group membership can drive room creation rights.

Calendar invitations and scheduling links

Every calendar invitation, bookmark and scheduling page that points to a Webex personal room must be updated to the new Jitsi room URLs. Plan the cutover so old Webex links redirect users to a holding message or are removed on a set date. Your collaboration or calendar administrator owns the calendar templates. Confirm with Webex how many recurring meetings and personal room links are active, so you can estimate the update workload.

SIP and room system dial plans

Room systems that dial into Webex by SIP or by meeting number need a new dial plan. Jitsi Meet reaches SIP endpoints through Jigasi, which is an optional container you must deploy and configure. Your network or unified communications team owns the gateway, dial plan and firewall rules. Inventory every room device, its current dial string and its firmware, and confirm which devices can dial a SIP address at all, because some Webex room ecosystem devices have no direct Jitsi equivalent.

TLS certificate and DNS records

Jitsi requires HTTPS with a proper domain certificate for working audio and video, and self-signed certificates cause problems, especially on mobile clients. Your security or PKI team owns the certificate, its renewal process and the DNS records that point the meeting hostname at the server. Confirm the public hostname, the internal name used by staff on managed devices, and the ports your firewall must open, including 443/TCP and 10000/UDP for media.

Jibri recording storage

If you record meetings with Jibri, recordings are written to storage you own, so capacity planning and backup become your responsibility. Your infrastructure team owns the volume, its retention policy and the backup schedule. Ask the team to size storage for the recording volume reported by your Webex export, and to confirm how recordings are copied off the Jibri host. Records owners should confirm that backups follow the same retention rules applied to Webex recordings.

Why HTTPS and token authentication come before the first user

Before any pilot user joins a call, the platform needs a valid certificate and a decision on how rooms are protected. The Jitsi self-hosting guide states that HTTPS is necessary for multimedia to work, and the Jitsi handbook says a proper domain certificate is required for working audio and video. It warns that self-signed certificates cause problems, especially with mobile clients, which many Webex users will use on the go. Plan for a public DNS name and a certificate from a trusted authority or your internal CA chain that mobile devices already accept, and test with a phone on a cellular connection, not only with laptops on the office network. The handbook is the primary reference for these requirements, which you can review in the Jitsi self-hosting guide.

Room access is the second decision. The older secure domain method, where users create rooms with a username and password, is marked as deprecated for new installations. The handbook recommends JWT token authentication instead, with a separate anonymous domain for guests so that invited external participants do not need an account on your identity system. The Docker setup offers internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all configured through the .env file. Decide which mode matches your directory and who should be able to create rooms before you write the configuration, because changing the model after users have bookmarked links is disruptive.

Confirm the network requirements with your firewall team before the pilot. The Debian and Ubuntu quick start lists 80/TCP and 443/TCP for web access and 10000/UDP for media, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. Ask whether these paths are open between the internet, your reverse proxy and the videobridge, and whether your proxies or inspection devices interfere with WebRTC media. Verify the exact list against the version you deploy, since the quick start is the source of truth for your build.

How the migration changes by organization size and starting point

A small team on Webex Meetings usually schedules few formal meetings and relies on quick calls, with little use of room devices, recordings or SIP dialing. For this group, the migration is mostly about replacing a browser-based join experience with a single self-hosted Jitsi Meet instance, which can be run as Docker containers or from Debian and Ubuntu packages. The Jitsi handbook states that HTTPS is necessary for multimedia to work, so a proper domain and certificate are the first technical prerequisite.

Main risk: the team underestimates the server and certificate work, and the service is treated as a desktop tool that can be set up in an afternoon.
Recording needs: confirm whether anyone has stored Webex recordings that must be kept, and export them before the contract ends.
Hosting choice: decide whether a small team will run one node in its own infrastructure or use the public instance, which is not a fit where meeting data must stay in-house.
Support model: identify who applies operating system updates and certificate renewals after go-live.

Before committing, check that the team's sign-in and meeting-link habits can work with the chosen authentication method.

What drives the cost and duration of a Webex to Jitsi migration

This table lists the main cost and effort drivers for moving Webex meetings to self-hosted Jitsi Meet, with why each one matters and how to keep it down. Read the one-time and recurring drivers separately, since implementation and hardening are paid once while hosting, bandwidth and upgrades continue after cutover. DeployOpen does not publish prices, and a quote follows from the written scope.

Cost or effort driver	Why it matters	How to keep it down
Concurrent meetings and participants	Peak simultaneous participants set the media capacity and bandwidth the bridges must carry. Confirm peak load from your Webex usage reports before sizing.	Measure real peaks by department and time zone, and avoid sizing for theoretical maximums.
Videobridge count and hardware	The Jitsi scalable setup guide suggests 4 CPU with 8 GB RAM for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Bridges scale horizontally by adding more.	Start with the suggested baseline, load test, then add bridges only where measured load requires them.
SIP room system count	Jigasi handles SIP gateway traffic for legacy room systems. Each room system dialing in adds gateway load and integration testing, and Webex room devices have no direct Jitsi equivalent.	Inventory every room device first, and retire or keep only those with a confirmed SIP path.
Recording and Jibri volume	Jibri recording needs its own capacity, and recordings consume storage that must be archived from Webex before the contract ends. Confirm your total recording hours and retention rules.	Record only meetings that need it, set retention periods, and archive existing Webex recordings in batches.
Identity integration	Choosing internal XMPP accounts, JWT tokens, LDAP or Matrix verification changes how users sign in and how rooms are created. Each choice adds configuration and testing.	Pick one authentication model early, and align it with your existing identity provider where possible.
Number of integrations to rebuild	Calendar plug-ins, room booking, LMS or helpdesk links and scheduling bots built around Webex must be rebuilt or replaced.	List every integration in use and remove those no longer needed before migration starts.
Staff time and network changes	Operations staff run and patch the servers, and firewall and DNS changes are needed for ports 80, 443 and 10000 UDP. Network teams must approve the opened ports.	Involve network and security teams in week one, and document firewall requests in one change record.
Parallel run duration	Running Webex and Jitsi side by side keeps both licenses and infrastructure active during the overlap, and user training takes time.	Agree the parallel run length and cutover criteria in the written scope so the overlap is not open-ended.
HTTPS certificate and domain setup	Jitsi requires HTTPS with a proper domain certificate for working audio and video, so certificate procurement and renewal are needed.	Plan the domain and certificate process early and automate renewal where your environment allows.

What usually goes wrong in a Jitsi migration and how to prevent it

Most Jitsi migration problems show up in the first week of use, not during installation. The six failures below cover certificates, authentication, capacity, firewall rules, recordings and SIP rooms, and each card names a check you can run in a pilot before cutover.

Self-signed or expired certificate

Jitsi's handbook states that HTTPS is necessary for multimedia to work and warns that self-signed certificates cause problems, especially on mobile clients. A certificate from a trusted authority for your own domain should be issued and renewed before any user joins. In the pilot, open a meeting from a phone on cellular data and a browser on a guest network, and confirm that camera and microphone work without warnings.

Deprecated secure domain method kept

The older secure domain setup, which uses a username and password to create rooms, is marked deprecated for new installations in the Jitsi handbook. Teams that copy an old configuration keep a login model that the handbook no longer recommends. Plan JWT token authentication from the start, with a separate anonymous domain for guests, and test that a token-less guest cannot create or lock a room.

Videobridge capacity underestimated

Jitsi Videobridge handles the media, so peak load falls on the bridges, not on the central server. The scalable setup guide suggests 4 or 8 CPUs with 8 GB RAM for each videobridge and states that bridges scale horizontally by adding more. Measure the largest meeting you expect, plus the number of concurrent meetings in your busiest hour, and run that load in the pilot before you retire Webex capacity.

UDP 10000 blocked at the firewall

The Debian and Ubuntu quick start requires port 10000 over UDP for media. Many corporate firewalls and load balancers forward only TCP, so meetings connect, then audio and video fail for users behind them. Open 10000/UDP toward the videobridges, keep 443/TCP for the fallback path, and confirm with the network team that the rule covers every site and VPN exit, not only the data center.

Recordings lost before archiving

Webex recordings stay in the Webex site until someone downloads them, and a Jitsi server has no copy of them. Export the full Webex recording library before the contract ends and store it in your own archive with its meeting dates and hosts. On the Jitsi side, decide early whether Jibri recording is needed, and if so, check where its files land and how long they are kept, since they remain on your storage.

SIP room systems left to last

Jigasi is the SIP gateway that lets callers from SIP-based room systems and dial-in numbers join Jitsi meetings. Teams often treat conference room hardware as a final step, then find that the Webex device ecosystem has no direct Jitsi equivalent and that Jigasi needs its own sizing and registration. Inventory every room system and dial-in path in week one, then test one room end to end in the pilot, including audio quality and join time.

Questions buyers ask before they move from Webex to Jitsi Meet

How much effort does a Webex to Jitsi Meet migration take, and what drives it?

The effort depends mostly on how many SIP room systems, recording archives and sign-in integrations you must keep, and on how many users need to join from outside your network. A Jitsi Meet deployment is made of several components (web front end, Prosody, Jicofo, Jitsi Videobridge, and optionally Jibri and Jigasi), so the work is in designing, installing, securing and testing each of them. The effort table on this page breaks these components down so you can compare them with your own inventory. Ask any implementation partner to price each component separately so you can see what changes if one scope item moves.

How long does the migration take, and what sets the duration?

The duration is set by the size of your estate, the number of integrations that must work on day one, and how many change windows your network and security teams allow. Teams that already run Linux servers, a reverse proxy and certificate automation usually move faster than teams that start from scratch. Confirm the timeline in writing with any partner, because a fixed-scope engagement sets scope, deliverables and dates before work begins. Plan for a parallel period in which Webex and Jitsi both run, since recordings and user habits rarely move in a single cutover.

Can our own team do the migration without outside help?

Yes, if your team has Linux administration, DNS and certificate management, and network skills, and can take ownership of the servers after go-live. The Jitsi Debian and Ubuntu quick start and the Docker guide cover installation, but the handbook's own guidance on HTTPS, token authentication and scaling still requires design decisions. Skills most often missing are reverse proxy and firewall tuning for UDP media, identity integration, and load testing before users depend on the service. Outside help can cover one of these gaps or the whole build, depending on your written scope.

What do Webex administrators and network teams need to provide?

Webex administrators need to export the list of users, rooms, recurring meeting schedules and any SIP addresses that devices use, and to confirm which of these people still need. Network teams need to confirm that ports 80/TCP, 443/TCP and 10000/UDP can be opened to the Jitsi servers, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. They also need a DNS name and a valid certificate, because the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video. Ask the network team early, since firewall change approvals often take the longest.

Can Jitsi replace Webex Control Hub and Video Mesh?

Jitsi Meet covers the meeting function, but it does not provide a direct equivalent of Control Hub or Video Mesh. Control Hub manages users, licenses, devices and analytics in the Webex cloud, while a self-hosted Jitsi deployment relies on your own identity setup, for example internal XMPP accounts, JWT tokens, LDAP or Matrix user verification, configured through the .env file. Video Mesh keeps media on premises while staying registered to the Webex cloud, whereas Jitsi videobridges run entirely in your infrastructure and scale horizontally by adding more. Confirm which Control Hub functions your administrators use today before you accept any gap.

Can we move existing Webex recordings to Jitsi, and what should we confirm first?

Jitsi does not import Webex recordings, so the realistic approach is to download them from Webex and store them in your own archive, such as object storage or a document system. Before the contract ends, confirm with Webex which recording formats, metadata and download methods your site provides, and whether any recordings are subject to retention or legal hold rules. Also confirm who in your organization owns each archive and how long it must be kept. Recording storage on a Jitsi server is limited to what Jibri writes locally, so plan storage separately if you use it.

How do we run Webex and Jitsi in parallel during cutover?

Run both platforms for a defined period, move a pilot group first, and keep Webex available for meetings that depend on devices or external partners. Publish the Jitsi room links and sign-in method early, and set a date after which new meetings are no longer created in Webex. Test the Jitsi servers with realistic meeting sizes and both browser and mobile clients before you move anyone, because self-signed certificates cause problems, especially with mobile clients. Keep Webex licenses until the archive and device questions are closed.

What does a fixed-scope DeployOpen engagement cover for this migration?

A fixed-scope DeployOpen engagement covers the agreed scope, deliverables and timeline for the parts you choose, such as planning, installing and hardening the Jitsi components, configuring authentication and HTTPS, integrating SIP or recording where in scope, and preparing documentation and handover. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares is for an independent assessor to review. Ongoing support, upgrades and continuous testing are available as retainers.

How DeployOpen scopes, runs and supports a Jitsi migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from Webex to Jitsi Meet, that means agreeing the written scope first, then building and documenting the deployment in your own cloud accounts, data centers or air-gapped networks.

How we scope

Inventory which Webex meetings, room systems and recordings are in use before any work is priced
Agree in writing which Jitsi components, SIP gateway needs and authentication model are in scope
Confirm with your own team the hosting location, HTTPS domain and network ports before work starts

How we build

Deploy the web, Prosody, Jicofo and Jitsi Videobridge components in your environment using the chosen method
Configure HTTPS with a proper domain certificate, since the Jitsi handbook says self-signed certificates cause problems
Test audio, video and screen sharing from desktop and mobile clients before users are moved over

How we hand over

Document the deployment, configuration, authentication settings and recording archive steps for your administrators
Walk your operations staff through upgrades, backups and the videobridge scaling model in the handover sessions
Deliver the written record of what was built and tested so your auditors or assessors can review it

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Keep the platform current with Jitsi releases and retest after each upgrade in your environment
Agree the support boundaries, response expectations and testing cadence in the written scope

Migrate from Webex to Jitsi Meet