Migrate from Google Meet to Jitsi Meet

What moving from Google Meet to Jitsi Meet involves

Migrating from Google Meet to Jitsi Meet means three things: standing up a self-hosted Jitsi deployment in your own infrastructure, changing how people join meetings, and moving existing recordings out of Google Drive. Most organizations arrive here because of a Workspace renewal, a change of edition, a data residency requirement or a wish to reduce lock-in. The work is usually carried out by an internal platform or infrastructure team, often with an implementation partner who handles the parts that are new to the team, such as the web front end, the XMPP and conference components, and hardening. Switching the meetings themselves is the easy part, because participants only see a different join link. The planning effort sits in identity, calendar links, recordings and day-to-day operations.

Meet is bundled into Google Workspace editions, so moving meetings to Jitsi may not remove a line item on its own. The Workspace license pays for far more than video, including mail, storage and administration, and those costs stay until you change edition or leave Workspace entirely. Before you commit, ask your Google account team which edition and which Meet features your organization actually uses, and confirm whether a cheaper edition is available. On the Jitsi side, costs are the servers, bandwidth, storage for recordings and the staff time to run them. Confirm with your own environment how many concurrent participants you need, since that determines how many videobridges to run. Plan a pilot group first, then roll out to teams in waves, keeping Meet available until recordings, calendar links and login are settled.

Which Google Meet capabilities map cleanly to Jitsi Meet

This table maps the Google Meet capabilities your teams use to their Jitsi Meet equivalents and marks each as clean, needs rework or gap. Use it to scope the migration before you commit, and confirm each setting against the Jitsi handbook rather than assuming parity. Most of the work sits in identity, recordings and dial-in, so plan those rows first.

Capability	Jitsi Meet equivalent	Status	Confirm before assuming parity
Join and scheduling from calendar invites	Jitsi Meet room URLs on your own domain, with invites generated by your calendar tool or a script	Needs rework	Calendar invites are not generated natively; confirm room naming and URL patterns in the Jitsi handbook
Google sign-in for hosts	JWT token authentication, or identity brokering through Keycloak to your existing directory	Needs rework	Confirm the supported token claims and the Keycloak client setup in the Jitsi token authentication guide
Guest access	Anonymous domain for guests, with JWT-gated rooms for hosts	Clean	Confirm how the anonymous domain behaves with your lobby and moderator settings
Recording to Drive	Jibri writes recordings to a local or mounted store that you control	Needs rework	Recordings do not go to Drive; plan storage and retention on your own infrastructure
Live streaming	Jibri streaming to a configured endpoint	Needs rework	Confirm Jibri requirements and the separate platform needed for large audiences in the Jibri documentation
Dial-in by phone	Jigasi SIP gateway with a SIP trunk you provide	Gap	Phone numbers and PSTN connectivity are not included; confirm trunk and numbering with your carrier
Room calendars and meeting rooms	No native room resource booking; use a separate scheduling layer	Gap	Room booking must be handled outside Jitsi; confirm integration options with your calendar system
End-to-end encryption	Optional end-to-end encryption in Jitsi Meet	Needs rework	Confirm supported clients, limits and key handling in the Jitsi security documentation
Admin controls and participant limits	Moderator controls, and scale by adding Jitsi Videobridges	Needs rework	Participant capacity depends on bridge count and sizing; confirm in the Jitsi scalable setup guide

How to stand up Jitsi with JWT or SSO login

A self-hosted Jitsi deployment is a set of cooperating services: the web front end serves the meeting app, *Prosody* acts as the XMPP server that holds signaling and accounts, *Jicofo* (the conference focus) creates and assigns conferences, and *Jitsi Videobridge* carries the audio and video media. *Jibri* (recording and streaming) and *Jigasi* (SIP gateway) are optional and should be added only if the migration needs them. The official Docker setup runs these as separate containers, configured through a .env file, while the Debian or Ubuntu quick start installs them as packages. Confirm the supported OS versions and the OpenJDK requirement against the current quick start before you choose an install path, and open 80/TCP, 443/TCP and 10000/UDP in the firewall. Plan for the videobridge count up front, because the scalable setup guide lets you add bridges horizontally later but the central server and each bridge need their own sizing.

HTTPS with a certificate issued for your real domain is not optional. The handbook states that audio and video do not work reliably without it, and self-signed certificates cause problems, particularly on mobile clients, so use your internal CA or a public certificate and test from a phone before you announce the service. Do not use the older secure domain method, which relies on username and password room creation. The handbook marks it as deprecated for new installations. Use JWT token authentication instead: your identity layer issues a signed token that Jitsi checks, and you configure a separate anonymous domain so guests can join without an account. Your JWT settings in .env must match the issuer, audience and signing key your identity provider uses, and this is the first thing to confirm in your chosen mode.

If corporate SSO must sign people into Jitsi, Keycloak can broker it. It is an Apache 2.0 identity server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can issue the JWTs Jitsi trusts after a user signs in with your directory. Keycloak supports PostgreSQL 14 to 18 and several other production databases, and its documented high availability designs both require a synchronously replicated database, so factor that into the design. Before go-live, confirm the Keycloak release you will run, the upgrade approach (automatic schema migration or manual SQL) and the operator update policy if you deploy on Kubernetes. Confirm which Jitsi authentication mode fits your policy: JWT alone, LDAP, Matrix verification or the hybrid modes described in the Docker guide.

What moves cleanly and what must be rebuilt

Some parts of a Google Meet move are mechanical, such as swapping meeting links, while others need new identity, recording and telephony work on the Jitsi side. Treat each card below as a separate workstream with its own owner and acceptance test before you set a cutover date.

User identities and group mapping

Jitsi needs a way to know who is allowed to create rooms and who joins as a guest. The supported path in the Jitsi handbook is JWT token authentication, with a separate anonymous domain for guests, and the older username and password secure domain is marked deprecated for new installations. Decide which Google Workspace groups map to moderator rights, and confirm with your identity team how the JWT claims will be issued. Use the JWT claims are your access rules as the checkpoint for every group you migrate.

Google Calendar invites and room calendars

Meet links are embedded in Calendar events and in Google Calendar room resources, so changing the link format is not enough on its own. Existing recurring series keep the old Meet URL, and room calendars need new location text that points to the Jitsi address. Plan a parallel period where both links work, and list which series owners must edit. Confirm that your calendar tooling and any scheduling add-ons can carry a custom conference URL.

Recordings in Drive

Meet recordings are saved to Google Drive, so they do not follow the meeting to a self-hosted server. Google's documented export paths are the Data Export tool and Takeout, and those are the routes to use for moving existing files. Jitsi recording depends on Jibri, which you deploy and size yourself, so new recordings need their own storage and retention policy. Confirm retention and access rules with the records owner before anyone deletes Drive copies.

Meeting history and chat

Meet does not hand over a meeting history or in-meeting chat transcript that Jitsi can read. Chat and attendance records from Google stay in Google's systems unless you export them through the documented paths, and Jitsi keeps no equivalent history by default. Decide which records regulated teams must keep, where they will live, and how they will be searched. Ask your compliance lead to define that list before the first pilot team moves.

Workspace add-ons and bots

Meetings often depend on Workspace add-ons, companion apps, transcription or note-taking bots and calendar automations. None of these have a direct Jitsi equivalent, and some may stop working once Meet is no longer the default. Inventory every add-on and script that touches Meet events, then mark each one as replaced, rebuilt or retired. Test each replacement with a pilot group before removing the original integration.

SIP and dial-in numbers

Dial-in phone numbers for Meet are a Google service, so they do not carry over. If users need phone access to Jitsi, the self-hosted route is Jigasi as a SIP gateway, connected to a telephony provider you choose and contract yourself. Confirm which phone numbers are still published in invites, what provider will carry them, and how calls will be routed and billed. Update the dial-in details in every template before cutover.

Migration sequence from inventory to decommission

This sequence moves meetings from Google Meet to a self-hosted Jitsi Meet deployment in controlled stages, so each team is verified before its invites change. It ends with Meet links retired, recordings archived outside Drive and old access removed.

Inventory meeting usage and recording needs
Pull the list of teams, shared calendars and room resources that create Meet links, and note how often each one records, streams or uses breakout-style workflows. Record where existing recordings sit in Drive, who owns them and which retention rules apply. Confirm with legal and records owners which recordings must be kept and for how long. The step is done when every meeting type has an owner, a recording requirement and a target cutover group.
Design identity and guest access
Decide how staff will sign in to Jitsi, using JWT tokens issued by your existing identity provider or a single sign-on bridge such as Keycloak, and how external guests will join through a separate anonymous domain. Map which Workspace groups become Jitsi roles and who may create rooms. Confirm the chosen login method with your security team before any hosting work starts. The output is a short written access design that names the identity source, token claims and guest rules.
Stand up Jitsi and run a pilot with one team
Deploy Jitsi Meet on your own infrastructure, using a proper domain certificate, since the Jitsi handbook states HTTPS is necessary for audio and video to work and warns against self-signed certificates. Configure JWT authentication, then give one team a test calendar domain or a dedicated test group so its invites use Jitsi links without touching production calendars. The pilot is complete when the team has held internal and external meetings on both desktop and mobile clients and the results are logged.
Build the recording archive path
Before wider rollout, decide where Jibri recordings will be stored and how they will be exported, indexed and access-controlled outside Google Drive. Test one recording from the pilot end to end, including playback by a user who is not the organizer. Confirm the storage location meets your data residency and retention requirements. The output is a tested recording workflow with a documented location and owner.
Run a parallel period in waves
Keep Google Meet available while Jitsi is offered alongside it. Move teams in waves, starting with the pilot team and then groups from the inventory, changing only new invites and room booking defaults for each wave. Collect feedback on join reliability, audio quality, screen sharing and sign-in friction, and fix issues before the next wave. Each wave is closed when its teams have stopped creating new Meet links and any blockers are recorded.
Cut over calendar links and room booking
Replace the conferencing details in Google Calendar templates, shared team calendars and room resource booking so new events carry Jitsi links by default. Update meeting room displays, add-ons and any integration that generates Meet links. Ask the Workspace administrator to confirm which calendar settings and room resources they can change. The step is done when a sample of new events across all waves shows Jitsi links and no new Meet links are generated for migrated teams.
Decommission Meet links and archive recordings
Once existing meetings have passed their dates, verify that remaining Meet links in open invites, shared documents and wikis are updated or noted as retired. Move the recording archive from Drive to the archive path tested earlier, and confirm the copy is complete before any deletion. Keep records of the retention decision for each category. The output is a verified archive and a list of retired links.
Retire old access and close the migration
Remove Meet-specific Workspace roles, administrator policies and calendar permissions that are no longer needed, and confirm with the identity owner that accounts and groups used only for Meet are retired. Disable any remaining Meet configuration, then record the final state in the access design. Ask your Workspace administrator to confirm which licences or edition features can be removed, since Meet is bundled in Workspace editions. The migration is closed when the access review is signed off and the decommission record is filed.

How the migration differs by organization size and starting point

A small team usually has a limited number of users, a few room calendars at most and no corporate identity system to integrate with. The migration centers on one host running the Jitsi stack, either with the Docker setup or the Debian and Ubuntu packages, plus a valid domain certificate, since the Jitsi handbook says HTTPS with a proper certificate is necessary for working audio and video. Accounts are often internal XMPP accounts, which keeps the first rollout small.

Host and network: One server with ports 80/TCP, 443/TCP and 10000/UDP open, on a supported operating system such as Ubuntu 24.04 or newer.
Authentication: Internal accounts are workable for a handful of users, but the handbook recommends JWT token authentication for new installations, so plan the switch early.
Calendar links: Replace Meet links in Google Calendar invites in one pass, since the user count is small.
Recordings: Decide whether recording is needed at all, because Jibri adds a separate component.
Scope limits: A single host has no redundancy, so an outage stops every meeting.

Confirm with your team whether a single host meets the availability expectations for meetings, and who holds the certificate renewal task.

What drives the cost and duration of this migration

This table lists the factors that move the cost and length of a Google Meet to Jitsi Meet migration, why each one moves it, and how to keep it under control. Read each row as a question to answer in your own environment before asking for a written scope or quote.

Driver	Why it changes cost or effort	How to keep it down
Users and concurrent meetings	Peak concurrent participants set how many Jitsi Videobridge instances you run. The scalable setup guide suggests 4 or 8 CPUs with 8 GB RAM per bridge and a 4 CPU, 8 GB central server, and scales horizontally by adding bridges.	Measure peak concurrency from Meet usage reports before sizing. Start with the suggested sizes, then add bridges only where load tests show need.
Identity integration	JWT token authentication, LDAP, Matrix or an identity provider such as Keycloak each add configuration, testing and user-mapping work. Moderators and guests need separate handling.	Choose one login model early. Use JWT with a separate anonymous domain for guests, and confirm which directory holds the users you need.
Calendar and room booking changes	Every Meet link in Google Calendar invites, templates, room calendars and shared documents must be replaced. Room resources and delegated calendars take the most manual checking.	Generate the new join URL pattern once, update templates and room resources in waves, and keep old Meet links working until the cutover ends.
Recording volume and retention	Jibri needs disk and compute per recording, and years of Drive recordings must be exported and stored. Retention rules decide how much storage and review work recurs.	Inventory recordings by age and owner, archive what policy requires, and set a retention rule before the first Jibri recording is made.
Dial-in and SIP needs	Phone dial-in through Jigasi needs a SIP trunk, dial plan and numbers. If Meet dial-in is used today, this adds telephony work that is separate from the video stack.	List which meetings use dial-in. If usage is low, confirm whether a fallback option is acceptable before building a SIP path.
HTTPS certificate work	Jitsi requires HTTPS with a proper domain certificate for audio and video to work, and self-signed certificates cause problems, especially on mobile. Certificate issuance and renewal become an ongoing task.	Request a domain and certificate plan early, automate renewal, and avoid self-signed certificates for any user-facing endpoint.
Staff training and support	Users need new join habits, moderator controls and recording locations. Help desk volume usually peaks in the first weeks of each wave.	Train team champions in each wave, publish short guides, and track support tickets to decide when the next wave starts.
Who pays for the work	Costs fall on the platform team's time, infrastructure, bandwidth and support. A partner, if used, is paid against the written fixed scope, so unclear scope tends to add change requests.	Ask any provider for a line-item quote covering build, testing, cutover, training and handover, and confirm which items recur after go-live.

What usually goes wrong and how to prevent it

Most failed Jitsi migrations trace back to a few predictable gaps: certificates, links that already left the building, recordings and identity settings. Each card names one risk, what it looks like in your environment and the check that prevents it before users notice.

Certificates break mobile clients

Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially with mobile clients. A pilot that works on desktop browsers can still fail for phone users. Before the first wave, test the public domain from iOS and Android, confirm the full certificate chain is served, and set a renewal alert so an expired certificate does not silently end meetings.

Lost Meet links in external invites

Google Calendar invites, email signatures, recurring series and shared documents carry old meet.google.com links that keep working until someone removes them. When those links stop resolving, partners and candidates arrive at dead ends. Export a list of recurring events that contain Meet links from your largest calendars, decide which series move, and keep a short redirect or announcement period before retiring the old links.

Recordings left in Drive

Meet recordings are saved to Drive by default, so the migration can leave a second copy behind under retention rules nobody reviewed. Set a written policy for where Jibri recordings go, who can download them and how long they are kept, then move existing recordings only after the owner and retention period of each folder are confirmed. Check that Drive retention or Vault holds do not block deletion when the policy requires it.

SSO misconfiguration locks users out

Jitsi's handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. A wrong audience, issuer, or room claim in the token can block every signed-in user at once. Test with a small group of accounts, verify both moderator and guest paths, and keep an administrator path that does not depend on the new login flow.

Underestimated peak capacity

Video load grows with the number of participants and the number of simultaneous meetings, not with the number of accounts. A plan sized for average calls can fail during an all-hands. 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, and says videobridges scale by adding more. Measure peak concurrent participants from your Meet usage reports, test a full-size meeting, and confirm the uplink bandwidth at each site.

Unplanned Jitsi upgrades

Jitsi Meet publishes stable releases tagged by build number, and a container or package update can change behavior that your login setup or recording pipeline depends on. Pin the image or package version, record which build each environment runs, and upgrade staging first. Ask your Docker or package owner to confirm the rollback steps before any production update, and schedule upgrades outside working hours for the first few cycles.

Questions teams ask before moving off Google Meet

How much does moving off Google Meet to Jitsi Meet cost?

The cost is mostly people time and server infrastructure, not a license fee, because Jitsi Meet is Apache 2.0 licensed software. Expect one-time costs for design, installation, identity integration, certificates, testing and rollout, plus recurring costs for servers, bandwidth, monitoring, backups and upgrades. The main drivers are how many concurrent participants you need, whether you record, whether you bridge to SIP phones, and how many environments you run. Ask any implementation partner for a fixed-scope quote built from a written list of deliverables, and ask your cloud or data center team to price the compute, egress and storage for your peak meeting load. Jitsi Meet itself is free to download, while hosted Jitsi as a Service from 8x8 is a separate commercial option you can compare against.

How long does a Google Meet to Jitsi Meet migration take?

The timeline depends on scope, not on Jitsi itself, and it is set by four things: the number of identity sources you must integrate, the depth of recording and calendar changes, your change approval process, and how many teams move in each wave. A basic pilot with internal login and a single domain is usually much shorter than a rollout that adds JWT-based single sign-on, guest access, Jibri recording and room calendar updates across regions. Your timeline should be written into the fixed-scope agreement before work starts, with a pilot exit criteria and a go or no-go gate for each wave. Ask for milestones, named dependencies, and the staff you need from identity, network and workplace teams.

Can our internal IT team run the migration without outside help?

Yes, many teams can, provided they have engineers who already operate Linux servers, reverse proxies, DNS, TLS certificates and an identity provider. The Jitsi self-hosting guide covers both Docker and Debian or Ubuntu packages, and it states that HTTPS with a proper domain certificate is necessary for audio and video to work. The gaps usually appear in JWT token authentication, identity provider integration, load testing and recording storage. Assess your team against that list honestly. If you use outside help, DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own infrastructure, typically under a written scope, and you can keep knowledge and runbooks in-house.

What skills and staff time does a Jitsi deployment need?

Plan for staff who can operate a set of separate services: a web front end, the Prosody XMPP server, Jicofo, one or more Jitsi Videobridge media routers, and optionally Jibri and Jigasi. The Jitsi Docker guide runs each as its own container with configuration in an .env file, which means your team needs container operations skills, log review and a patching routine. 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, so network and capacity planning matter. Ongoing effort is mostly upgrades, monitoring of media quality and on-call coverage during meeting hours. Ask whoever you hire to document the upgrade path and the staff you need on the rota.

Are the savings from leaving Google Meet real, given Workspace bundling?

Often not on their own, because Meet is bundled into Google Workspace editions, so removing Meet alone rarely removes a line item from your invoice. Savings appear only if you move to a cheaper edition or leave Workspace entirely, and then the comparison must include Jitsi servers, bandwidth, operations and migration effort. Check your current Workspace contract, which edition you hold, whether Meet features such as recording or live streaming are tied to a higher tier, and what email, storage and identity services depend on the same contract. A sound business case compares the full before and after cost, including staff time, and it should be reviewed by finance before any renewal decision.

How do Meet recordings move out of Google Drive into a self-hosted setup?

Meet recordings are stored in Drive, so you must export or copy them before they are deleted from your Workspace account, and you must confirm the retention and export rules that apply to your edition. In a self-hosted setup, Jitsi recordings are produced by Jibri, which you configure to write files to storage you control, so you need a plan for where those files sit, how long they are kept and who can access them. Migration of old recordings is a separate task: inventory the files, check their owners and sharing settings, and move them to your own object or file storage with checksums and an access log. Compare this with how other conferencing vendors expose files, for example Zoom saves MP4, M4A, TXT, VTT and CC.VTT files that you download, so confirm the formats you need before you start.

Can Jitsi match Google Meet's identity, guest and access controls?

Jitsi can cover the core needs, but it works differently and some controls are configured rather than built in. The Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix verification and a hybrid Matrix plus JWT mode, and the handbook recommends JWT token authentication over the deprecated secure domain method, with a separate anonymous domain for guests. Single sign-on can be handled through an identity provider such as Keycloak, which is Apache 2.0 licensed and supports OpenID Connect and SAML 2.0. Confirm each Meet control you rely on, including lobby behavior, host moderation, domain restrictions and audit logging, against Jitsi's configuration and your own tests before you set a rollout gate. Jitsi's security and privacy page is the place to review its published position.

What to confirm with your team before scoping

Start by confirming which Google Workspace edition your organization runs and how many users actually schedule or join Meet meetings, because that determines what you are replacing. Ask the Google administrator to export the current user count, the number of groups and shared calendars that hold Meet rooms, and whether live streaming or cloud recording is switched on today. Those answers shape the number of Jitsi videobridges, the Jibri capacity and the training load. Also confirm which calendar domains receive invites, including any secondary or subsidiary domains, so the replacement links cover every mailbox that sends them.

Next, settle the identity and access model with the internal security team. Confirm which identity provider holds the accounts (Google Workspace itself, or an external IdP federated to it), whether guests join without accounts, and whether any meetings must be restricted to a named group. Decide whether Jitsi will use JWT tokens issued by your own login service, which the Jitsi handbook recommends over the deprecated secure domain method, and whether an anonymous domain for guests is required. Record the retention rules for recordings that currently sit in Drive, the legal hold obligations that apply to them, and who may download or delete them.

Finally, confirm where the servers may run and how large the biggest meetings get. Ask the security team whether the hosting location must stay inside a specific country or data center, and whether the Jitsi self-hosting guide's HTTPS requirement with a proper domain certificate can be met in that location. Measure peak meeting size from the Google admin reports or from the organizer's experience, since the largest meeting sets the bridge capacity you need. Ask your implementation partner for a written scope that lists each of these answers, so the migration waves and the sizing decisions rest on confirmed inputs.

How DeployOpen works on this

DeployOpen plans and implements self-hosted Jitsi Meet inside your own cloud accounts, data centers or air-gapped networks, then documents and supports it. The migration covers the Jitsi deployment, login, calendar and room changes, recording moves and a staged rollout to teams.

How we scope

Written scope listing the Jitsi components, login method, calendar and room changes, and recording moves to be delivered
Inventory of Google Calendar invites, room calendars and Drive recording locations agreed before any work starts
Engagements are fixed-scope, with deliverables and timelines confirmed in writing; a quote follows from that scope

How we build

Deploy Jitsi Meet on your infrastructure using Docker or Debian and Ubuntu packages, with HTTPS on a proper domain certificate
Configure JWT token authentication with a separate anonymous domain for guests, or the identity source you choose, and test each path
Set up recording with Jibri where needed, then test video, audio and firewall ports before any team is moved

How we hand over

Documentation of the deployed architecture, configuration keys, .env settings, login flow and runbooks for your operations staff
Rollout plan in waves covering calendar template changes, room calendar updates and user communication for each team
Backup and upgrade procedures, plus a record of testing and configuration evidence for your compliance assessors to review

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Review of Jitsi releases and dependency changes so upgrades are planned against your scope rather than applied blindly
Confirm with your team what remains in-house after handover, including on-call ownership and who approves production changes