What a Jitsi migration involves
The free meet.jit.si service and 8x8's JaaS are operated by others. Moving to a self-hosted Jitsi Meet means rebuilding the parts that the hosted service handled for you: the web hosting, the domain, the TLS certificates, the authentication model and the integrations with calendars, portals and apps. All of it runs on infrastructure you control, so each of those pieces becomes a decision and an owned service with its own failure modes.
Organizations usually trigger this work for a small set of reasons: data residency requirements for where media and logs are processed, a wish for cost predictability instead of usage-based pricing, tighter control over who can create or enter rooms, branding that matches the organization, and network policy that requires traffic to stay within approved paths. Each trigger shapes the design. A residency requirement, for example, affects where videobridges and any recording storage are placed.
Meeting content is live media, not stored data, so the migration is not about moving recordings or transcripts from one system to another. It is about the things that let people join: room links and how they are generated, user identities and who may start a meeting, calendar and app integrations that embed or link to rooms, and the people who must learn the new links and sign-in path. Confirm with your team which of these your current meetings depend on before the design starts, because hidden dependencies usually surface at cutover.
Teams with Linux and network operations skills can carry out this migration in-house. Many choose to outsource the design, a pilot with real users and the cutover itself, since these are the steps where a wrong choice about certificates, authentication or firewall rules is most visible. Ask any partner to confirm in writing which of these phases are included in the scope, what the pilot must prove before cutover, and who is responsible for rollback.
What the work includes
The migration is delivered as a set of documented outputs, each checked before the next starts. Jibri, SIP dial-in and high availability are scoped separately when your requirements call for them.
Current-state usage inventory
We map how people reach meetings today: ad hoc meet.jit.si links, calendar invites, iframes embedded in internal tools, mobile apps and any JaaS tenant or app integrations. Each path is recorded with its owner, so nothing still pointing at the hosted service is missed at cutover. Confirm with your team which integrations and tenants exist before the inventory is closed.
Target design and domain plan
This deliverable fixes the public domain, the TLS certificate approach, the authentication model and the separate anonymous domain for guests, following the Jitsi handbook. It also records port and public addressing decisions, including the UDP media port and the TCP fallback. Review it with your network and security teams before any server is built, since changes later affect certificates, firewall rules and client links.
Self-hosted deployment build
The platform is installed either on Debian 12 or Ubuntu 24.04 using the quick start, or with the official Docker setup, pinned to a tagged stable build. Both options need a valid certificate, since self-signed certificates cause problems with audio, video and mobile clients. Confirm which build tag is current on the day of installation and record it in the handover pack.
Calendar and application link reconfiguration
Calendar templates, room naming conventions, embedded iframe code and any JaaS app integrations are updated to point at your domain. Each changed link is tested from inside and outside your network. Keep a list of old and new URLs so that existing invitations can be explained to users and retired on a known date.
User communication materials
Staff, guests and external partners receive short guides covering the new meeting address, how to join from browsers and mobile apps, and what changes for recurring meetings. Materials are drafted with your communications or IT service desk owner and reviewed before release. Agree the sending channel, the date of the first notice and who answers questions during the transition.
Pilot group and acceptance criteria
A named pilot group uses the new deployment for real meetings before cutover. Acceptance criteria are written in advance and cover join success from the main browsers and mobile apps, audio and video quality, guest access through the anonymous domain and any calendar or iframe paths. Pilot results decide whether cutover proceeds, so agree who signs off on them.
Cutover runbook and rollback
The runbook sequences DNS changes, certificate checks, link switches and communication send-outs, with a named owner for each step. A rollback path is defined before cutover, including how links revert and how long the hosted service remains available as a fallback. Test the rollback steps during the pilot, not for the first time during an incident.
Handover and documentation
Your operations team receives the architecture record, configuration files with secrets handled separately, the upgrade and backup procedures, the link inventory and the runbook. Handover includes a walkthrough with the people who will run the platform. Confirm which documentation formats and repositories your team uses so the handover fits your existing practice.
What drives effort and duration
This table lists the inventory and readiness factors that most change migration effort, why each one matters, and how to keep it manageable before cutover.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Hosted entry points | Every meet.jit.si link, JaaS tenant reference, embedded iframe and app shortcut must be found and repointed or retired, and each one can hide a different owner. | Build a written inventory of every entry point before scoping, assign an owner to each, and retire links that no longer have a user. |
| Calendar and chat integrations | Calendar plugins and chat bots that generate meeting links keep producing JaaS or public links until their configuration is changed, so each integration adds a test and a rollback step. | List each integration with its admin owner, change them in groups, and confirm link generation in a test calendar before cutover. |
| JaaS features in use | Recordings, transcripts and custom branding tied to JaaS must be rebuilt on your deployment or formally retired, which can change scope more than any other single item. | Check the JaaS console for enabled features, decide keep or retire for each one in writing, and treat rebuilt features as separate scope items. |
| Authentication model | Moving from anonymous or public access to JWT tokens, internal XMPP accounts, LDAP or Matrix-based options changes how users sign in and how rooms are created. The Jitsi Docker guide lists these options and they are configured through the .env file. | Choose the model during planning, match it to the identity system you already run, and confirm the handbook recommendation for JWT with a separate anonymous domain for guests. |
| Certificate and DNS readiness | The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile clients. Certificate issuance and DNS changes often wait on other teams. | Request the domain certificate and DNS records early, confirm they work on mobile test devices, and start the change request before the build phase. |
| User groups and time zones | Each user group needs its own notice, guidance and sometimes a training session, and spreading sessions across time zones multiplies coordination work. | Group users by function and region, reuse one set of guides, and schedule short sessions in overlapping windows instead of one per group. |
| Pilot required by change process | If your change process requires a pilot, it adds a test group, a feedback cycle and a go or no-go decision before cutover, which lengthens the schedule. | Agree the pilot exit criteria in writing at scoping, keep the pilot group small and representative, and ask your change board which evidence it needs. |
Migration phases and outputs
Seven phases move meetings from a hosted Jitsi service to your own deployment, with a named output at each step so nothing reaches users before it has been tested.
Inventory current meetings and integrations
Record every room link in circulation, every calendar and app integration, the user groups who host meetings, and the features they rely on, such as screen sharing, dial-in or recording. Owner: the migration lead with input from each team. Done when the inventory is reviewed and signed off by the business owners.
Decide the target design and pin the release
Record decisions on the domain, trusted TLS certificate, authentication model, guest path, and firewall rules (80 and 443 over TCP, 10000 over UDP). Pin the release to stable/jitsi-meet_11248, the current tagged stable build in the jitsi-meet repository, and confirm the pin on the day the build starts. Done when the design is approved by security and IT operations.
Build and test in non-production
Install the web server, Prosody, Jicofo and videobridge on the pinned release in a non-production environment, then apply the chosen authentication and guest settings. Run integration tests with a test room: join from desktop and mobile browsers, check audio and video through the bridge, and open links from calendar invites and apps. Done when the test report shows every case passed or has a logged fix.
Run a pilot with a defined group
Select a named user group, such as one team or one business unit, and move its recurring meetings and links to the new deployment. Collect feedback through a shared channel and a survey, log each issue with an owner, and fix blockers before widening access. Done when the group has held its usual meeting types on the new service and open blockers are closed or accepted in writing.
Communicate and train before cutover
Publish a notice that gives the cutover date, the new link pattern, supported browsers, and where to get help. Run training sessions for hosts, moderators and help desk staff, covering room creation, guest joining and what to do when audio does not work. Done when the notice has gone out, attendance is recorded and the help desk has a written escalation path.
Cut over with a dated runbook
Execute a dated runbook that switches DNS and calendar or app integrations to the new domain, and sets a redirect or notice plan for old hosted links. Include a rollback path that reverts DNS and integration settings, names who can trigger it, and states what to tell users. Done when the cutover is signed off and the first live meetings are checked end to end.
Decommission the hosted service in stages
Remove the hosted service from calendar invitations, app settings and integrations you control, then keep a read-only period for old links so people can still find meeting information. Confirm with the provider, 8x8 for JaaS, which account data and billing items you must export or close. Done when integrations are removed, exports are archived, and the old account is closed or confirmed inactive.
What teams keep in-house and what they outsource
This table compares, for each part of a move from meet.jit.si or JaaS to a self-hosted Jitsi Meet, whether the work usually stays with your team or goes to a partner, and which skills each part needs.
| Work area | Usually in-house | Usually outsourced | Skills needed |
|---|---|---|---|
| Inventory of links and integrations | Yes: your team lists the room links, calendar invites, bookmarks and apps in use, since only users know their habits | Rarely: a partner can review the list but cannot reconstruct habits from outside | Knowledge of how staff meet, calendar administration, and access to usage patterns |
| Server build and Linux administration | Possible if your team already runs Debian or Ubuntu servers and the Jitsi stack | Possible if your team lacks Jitsi or Linux operations experience; the Jitsi scalable setup guide warns this is not a task for beginners | Linux administration, Docker or Debian packaging, XMPP and media server basics |
| DNS, certificate and firewall changes | Yes, with partner review of the design before changes go live | Partner review is recommended, since HTTPS with a valid domain certificate is required for working audio and video | DNS administration, certificate management, firewall rule design for ports 80, 443 and 10000/UDP |
| Authentication design | Partner or identity team; decide whether rooms stay open or need JWT tokens from your identity system | Often outsourced when the chosen method is JWT or LDAP, because the design touches identity systems | Identity provider administration, JWT token issuance, LDAP or Matrix options as applicable |
| Integration reconfiguration in calendar and apps | Yes: the owners of each calendar, app or intranet page update their own links and settings | Partner can supply link patterns and scripts, but not change systems they do not administer | Calendar and app administration for each system in the inventory |
| Pilot planning and user communication | Yes: an internal sponsor sets the pilot group, dates and messages | Partner can supply draft materials and a test script for the pilot | Project sponsorship, change communication, and support triage for early users |
| Cutover runbook and rollback test | Joint: your team approves the steps and the rollback decision | Often partner-led, with a rehearsal of the switch and the return to the previous service | Operations runbook writing, change management, and test environment management |
| Post-cutover operations | Yes, if your team has staff trained on upgrades, monitoring and browser compatibility | A support retainer can cover monitoring, upgrades and incident response, if agreed in writing | Monitoring, patching, upgrade testing, and on-call coverage for meetings |
What usually goes wrong
Most Jitsi migrations stall on the same few issues, and nearly all of them trace back to the inventory of links, integrations and features or to a pilot that did not reflect the real user base. Each card names the check that prevents it.
Old links keep routing to the hosted service
Meeting links already sent to partners, customers, calendars and bookmarks still point to meet.jit.si or a JaaS tenant after cutover, so users keep joining there without knowing it. During the inventory, search wiki pages, email templates, calendar tools and shared documents for those hostnames, and list each owner who can change them before the pilot starts.
Missing trusted certificate on the new domain
The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile clients. Confirm that a publicly trusted certificate covers the exact hostname users will open, and test audio and video on desktop browsers, Android and iOS during the pilot rather than after cutover.
Pilot group does not represent real users
A pilot run by the platform team usually uses managed laptops, a single office network and people who already know the product, so failures appear only when the wider organization moves over. Select pilot participants from the inventory of teams, devices, locations and remote workers, including people on guest networks and home connections, and record which groups were never tested.
Calendar and app integrations point to the wrong domain
Calendar plugins, room-creation scripts, embedded meeting pages and chat integrations often hold the old domain or the old authentication mode, so new meetings are created on the hosted service or fail to open for some users. List every integration from the inventory, record its domain and authentication setting, and retest each one from a clean account before the pilot ends.
JaaS-only features left without an owner
Features that teams relied on in the hosted service, such as particular recording, transcription, branding or dial-in options, may not exist in your deployment or may need separate components. Compare the feature list in use against what your Docker or Debian deployment provides, and assign each gap a decision (replace, drop or defer) with a named owner and date.
Users not told when old links stop working
If the hosted links simply stop working on cutover day, people lose meetings with no warning and open support tickets that the platform team is not staffed to handle. Plan a dated notice that names the new address, states the date the old one ends, and reaches the same audiences identified in the inventory, with a short contact point for failed joins.
Rollback path never rehearsed
Cutover plans often describe how to move forward but not how to return users to the hosted service if the self-hosted deployment fails under real load. Write the rollback steps for DNS, links and integrations, rehearse them once on the pilot setup, and agree in advance who decides to roll back and how long users stay on the previous service.
How the work changes by starting point
The free public instance at meet.jit.si is operated by 8x8, and it usually holds no tenant data your organization can export. Most of the work is changing links, habits and the places where meeting links were shared.
- Collect every place a meet.jit.si link appears: calendars, intranet pages, email signatures, support articles and customer-facing materials.
- Decide how room names will be formed on your domain, so that links remain predictable for staff.
- Confirm with 8x8 whether any account-level data or recordings exist for your organization before assuming there is nothing to keep.
- Plan a message to users explaining the new address, the sign-in method and what happens to links that still point to the public service.
- Test that browsers and mobile clients used by staff connect to the new domain with a valid certificate.
JaaS is 8x8's hosted Jitsi service, and it carries a tenant, app integrations, recording settings and any custom configuration that your team has built. These must be inventoried before cutover, and the contract and data terms must be confirmed with 8x8.
- Inventory the tenant, app IDs, signing keys, JWT claims and any webhooks or integrations that depend on them.
- List custom interface settings, branding and recording or transcription use, since each needs a self-hosted equivalent.
- Ask 8x8 which tenant data, recordings and logs can be exported, in what format, and within what notice period. Do not assume an export feature exists.
- Review the contract for termination, notice and data return terms, and confirm them in writing before setting a cutover date.
- Plan a parallel run so that existing JaaS meetings can finish while new meetings start on your deployment.
An existing in-house Jitsi test install already runs the software, so the work is usually hardening and migrating users, not rebuilding the platform. The main risks are configuration that was never meant for production.
- Review the current configuration against the production concerns in your security and identity plans, including room creation rules and authentication.
- Check whether the test install uses a self-signed or non-production certificate, since the Jitsi handbook warns this causes problems, especially on mobile.
- Confirm the software versions and align Jitsi Meet, Prosody, Jicofo and videobridges to matching stable releases before go-live.
- Move users, shared links and any saved settings to the hardened deployment, and document what changes for them.
- Decide what happens to rooms and recordings created on the test install, and whether they must be kept.
When meetings run inside a product through the IFrame API, code changes and release coordination dominate the work. The product team, not only the infrastructure team, controls the cutover.
- Identify every page, product module and customer integration that embeds a Jitsi meeting, and the URL or configuration each one uses.
- Plan code changes that point the embed to your domain, handle any new authentication requirement and test the embed in every supported browser.
- Coordinate the release with product owners, customer success and any customers who host their own integrations.
- Confirm with 8x8 how the current embed is licensed and billed, and whether any hosted features it uses have a self-hosted equivalent.
- Schedule a rollback path in the product release, since an embed fault affects end users directly.
In an air-gapped or restricted network, package sources, certificates and update paths must be planned before installation. Meeting links and public services that the environment cannot reach also need replacing.
- Plan how Debian or Ubuntu packages, Docker images and their updates will reach the isolated network, and who approves each transfer.
- Arrange a certificate for the Jitsi domain from a trust chain your users accept, since self-signed certificates cause audio and video failures.
- Confirm the required ports, including 10000/UDP for media, and check whether firewall rules allow them between internal clients and the servers.
- Verify with your vendor or internal team which optional services, such as external dial-in or cloud transcription, can and cannot run in the environment.
- Set a procedure for applying Jitsi releases from the internal mirror, and test it on a non-production copy first.
What you need to provide
Before any migration work starts, the client provides a set of inputs that determine scope, sequencing and the quote. The most important are a named executive sponsor who can settle conflicts between teams, and a migration owner who makes day-to-day decisions and signs off the cutover date. Without both in place, the room link changeover tends to stall between IT, facilities and business units.
Access comes next. DeployOpen needs administrative access to the current hosted service so the team can document existing room naming, moderator settings, lobby and password rules and any custom branding. If you use JaaS, provide the console access or the tenant contacts at 8x8 who can answer questions about your tenant. Also provide an inventory of every place Jitsi links live: calendar templates, Outlook or Google invitation text, chat tool bots and integrations, intranet pages, help desk articles and mobile apps. Each one is a cutover task and a source of broken links if missed.
The infrastructure inputs are the longest lead items. Provide the DNS zone where the new hostname will be created, the authority to create that record, and the chosen hosting location, whether that is your cloud account, a data center or an isolated network. Confirm access to those accounts or facilities in writing. Agree the firewall change process and its lead time with your network team now, because the ports Jitsi uses must be opened before the pilot can run.
Decide the authentication model and who may start meetings, since this changes how the new deployment is configured from the first day. Also name a pilot group with its availability, approve the channels you will use to tell users about the change, and decide what happens to recordings and chat history held by the old service. Retention, export and deletion decisions for that data sit with your legal and records owners, and they should be documented before the quote is finalized.
Frequently asked questions
Can our own team migrate from meet.jit.si or JaaS to a self-hosted Jitsi Meet?
Yes, if your team has Linux, DNS, TLS certificate and network skills and can run the service after cutover. The work covers a web server, Prosody, Jicofo and videobridges, firewall ports, HTTPS with a proper domain certificate, an authentication choice, and updates to calendar invitations, app links and user guidance. The Jitsi scalable setup guide notes that building scalable infrastructure is not a task for beginning administrators, so teams new to Jitsi often bring in a partner for design and cutover while keeping daily operations in-house. DeployOpen plans and implements the deployment inside your infrastructure under a written scope.
What drives the cost and effort of a Jitsi migration?
The main drivers are the number of concurrent participants, which sets how many videobridges you need, whether you add recording or SIP dial-in, how many calendar, app and embedded integrations must change, the state of your certificates, network and firewall, and the internal IT time your team commits. The effort-driver table on this page shows how each factor moves the work. Prices are not published. DeployOpen issues a quote from a written scope that lists deliverables, your responsibilities and exclusions. Ask which costs are one-time and which recur, such as hosting, bandwidth, monitoring and upgrades.
How long does a Jitsi migration take from start to cutover?
Duration depends mainly on the size of your meeting inventory, meaning the links, rooms, integrations and apps that point to the current service, and on the change-approval lead times in your organization. Those approvals can add time before a cutover window opens. A quote states the timeline for the agreed scope, including the pilot period. Confirm with your change board how far ahead production changes must be submitted, and ask for the approval steps to appear in the plan so schedule risk is visible before work starts.
Can live meetings, recordings and chat history move to our Jitsi?
Live meetings do not carry over, so users must join through the new deployment at cutover. What you migrate are scheduled invitations, room names and the links that refer to them. Stored items such as recordings stay with the provider that created them, so check with that provider how to export them and in what format before cutover. Chat in Jitsi Meet is outside the end-to-end encryption scope, and any chat history from a hosted service must be confirmed with that provider. Plan retention for anything you export, because it becomes your data to store.
Will our existing meet.jit.si or JaaS links keep working after cutover?
Not automatically. Old links point to the hosted domain, and a self-hosted Jitsi Meet deployment does not redirect them to your domain. Redirects must be planned and their feasibility confirmed with the hosted service provider. In practice, you replace links in calendars, bookmarks, embedded pages and apps. Build an inventory of every place a link appears, set a date when old links end, and tell users what to do. Confirm with the provider what happens to its own links after you leave.
What do we provide, and is a pilot part of the migration before cutover?
Your team provides the infrastructure in your cloud accounts, data centers or air-gapped network, control of DNS and the domain certificate, the link and integration inventory, named approvers for change windows, and staff who will run the service. The pilot is part of the written scope and runs before production cutover, so users, calendars and apps are tested with real meetings. After cutover, the handover covers documentation and monitoring. Ongoing support, upgrades and continuous testing are available as retainers.
How DeployOpen runs a Jitsi migration
DeployOpen moves meetings from meet.jit.si or JaaS onto a Jitsi Meet deployment that runs in infrastructure you control, under a written, fixed scope. The work covers the platform, the room links and integrations your people depend on, and a pilot before any cutover.
How we scope
- The written scope lists which hosted services, room links, calendar and app integrations are moving to your deployment.
- We inventory how current meetings are created and joined, including any JaaS app IDs or embedded meeting pages.
- The scope names the pilot group, the cutover approach and who approves each stage before work starts.
How we build
- We deploy the web server, Prosody, Jicofo and videobridges on the Debian or Ubuntu or Docker layout agreed in scope.
- We configure HTTPS with a proper domain certificate, since self-signed certificates cause audio and video problems on mobile clients.
- We set up the authentication model chosen in scope, such as JWT tokens, and test room creation and guest access before the pilot.
How we hand over
- You receive the configured deployment, the firewall and port settings, and a record of certificates, domains and authentication settings.
- Users receive the communication, updated room link guidance and pilot feedback steps agreed with your team.
- Runbooks cover the cutover, rollback steps for the meeting links and the known gaps you accepted in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the written scope.
- Support can cover keeping Jitsi components on matching stable releases and testing upgrades before they reach users.
- Confirm with DeployOpen during quoting exactly which post-cutover tasks a retainer covers and how incidents are handled.
