Migrate from Zoom to Jitsi Meet: what the move involves
Jitsi Meet replaces the meeting service, but recordings, Zoom-specific settings and integrations need separate work. Most teams arrive here because of a Zoom renewal, a licensing change, a data residency rule or a wish to end lock-in, and the decision that matters first is which of those Zoom functions your users depend on day to day. Scheduled meetings, screen sharing and browser-based joining move across with little change for participants. Cloud recordings, transcripts, Zoom Marketplace apps, calendar plug-ins, single sign-on settings, room hardware and account reports do not move on their own, and each needs an owner and a plan before cutover. The migration is usually run by the platform or IT team that will operate the Jitsi servers, with a security or compliance lead signing off on certificates, authentication and where recordings are stored. Jitsi itself is an Apache-2.0 project, so there is no license fee, but the work is in the deployment: a web front end, Prosody, Jicofo and Jitsi Videobridge, plus Jibri and Jigasi if you need recording or SIP dial-in. The core meeting service is the easy part. The harder parts are HTTPS with a proper domain certificate, which the Jitsi handbook describes as necessary for audio and video to work, and choosing an authentication model. Plan for the recording and transcript export before anything else, because Zoom will not keep those files for you indefinitely. For effort and risk, expect a short pilot with a small group of hosts to surface the settings your users actually rely on, followed by a phased rollout. The main risks are missed recordings, meetings that fail on unmanaged networks without a TURN path, and users who rely on Zoom-only features. Ask any implementation partner for a written scope that lists each Zoom feature in use, who owns it after cutover, and what is tested before the Zoom contract ends. Confirm current server sizing against the Jitsi scalable setup guide rather than relying on figures from older articles.
Which Zoom capabilities map cleanly to Jitsi Meet
This table maps the Zoom capabilities most teams depend on to the Jitsi Meet components that provide them, and marks each as clean, needs rework or gap. Read the status as a starting point: confirm each feature against the Jitsi release you plan to deploy before you commit, because add-ons such as Jibri and Jigasi are configured separately from the core meeting stack.
| Zoom capability | Jitsi Meet components | Status and what to confirm |
|---|---|---|
| Meetings and screen sharing | Web front end, Prosody, Jicofo, Jitsi Videobridge | Clean. Core meetings and screen sharing run in the browser. Test sharing from each browser and OS your staff use. |
| Waiting room and lobby | Prosody and Jicofo with moderator controls | Needs rework. Lobby behavior depends on the Jitsi version and room settings. Confirm lobby options in your release and in the handbook before promising them to users. |
| Host controls (mute, remove, roles) | Web front end with Jicofo and Prosody moderation | Needs rework. Basic moderator actions exist, but Zoom's admin-wide policies have no direct equivalent. Plan to set them through configuration and test each control. |
| Cloud recording | Jibri with its own recording storage | Needs rework. Recording needs a Jibri instance, and each Jibri handles one recording at a time. Storage, retention and transcript generation must be built and sized by your team. |
| Local recording | Browser or client capture, outside Jibri | Needs rework. Participants can record on their own device, but consent, file handling and naming must be defined in your policy. |
| Live streaming | Jibri streaming mode | Needs rework. Streaming uses Jibri and needs a reachable streaming target and bandwidth planning. Confirm the streaming setup in your version. |
| SIP dial-in and room dial-out | Jigasi as the SIP gateway | Needs rework. Jigasi requires a SIP trunk or PBX integration and its own testing. Confirm supported call flows and codecs with your telephony team. |
| Authentication and SSO | Prosody with JWT tokens, LDAP or Matrix verification via the .env file | Needs rework. Options include internal accounts, JWT, LDAP and Matrix. The older secure domain method is deprecated for new installs, so plan JWT and confirm your identity provider integration. |
| Webinars with large audiences | Jitsi Videobridge scaling, Jibri streaming | Gap. Jitsi has no built-in registration, panelist roles or attendee Q&A equivalent to Zoom Webinars. Confirm capacity and source these features from other tools. |
Migration sequence from Zoom to Jitsi Meet
This sequence moves Zoom meetings to a self-hosted Jitsi Meet deployment in your own infrastructure, starting with preserving existing recordings and transcripts so nothing is lost at cutover. Each step ends with a named output that gates the next one.
Inventory meetings, recordings and integrations
Your IT lead and a Zoom administrator list every account, meeting type, recurring meeting, webinar, recording, and integration that depends on Zoom, including calendar plugins, single sign-on settings, and any Zoom Node or Zoom Phone usage. Record which teams rely on features that need extra Jitsi components, such as recording through Jibri or dial-in through Jigasi. The output is a written inventory with an owner and a go or no-go note for each item, reviewed by the business owners of the meetings.
Export recordings and transcripts from Zoom
Before any Zoom license changes, an administrator downloads cloud recordings from the recordings page. Zoom saves MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, so keep every file type for each meeting and store them in a controlled archive with the meeting ID, date and host recorded alongside. Check a sample of files by opening them and confirming the transcript matches the recording. The output is a verified archive with a file count reconciled against the recordings list.
Build a pilot on a domain with HTTPS
Your platform engineers deploy Jitsi Meet on a test host using the Docker or Debian and Ubuntu packages, with a proper domain name and a valid certificate, since Jitsi's handbook states HTTPS is necessary for audio and video to work and warns that self-signed certificates cause problems, especially on mobile. Confirm the required ports are open, including 10000/UDP for media. Choose the authentication method early: the handbook marks the older secure domain method as deprecated for new installations and recommends JWT tokens. The output is a working test meeting joined from a desktop browser, a phone and a network outside the office.
Size videobridges for your peak load
Load test the pilot with realistic meeting sizes and concurrency drawn from your inventory, and watch CPU and bandwidth on each Jitsi Videobridge. 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 the default install is already set up for horizontal scaling, so you add bridges rather than enlarging one. Ask your hardware or cloud team to confirm the figures against your own measurements. The output is a documented capacity table with the number of bridges needed for peak concurrency.
Configure recording and SIP add-ons
If your inventory requires cloud-style recording, deploy Jibri, which records one meeting per Jibri instance, so plan one instance for each concurrent recording and size storage accordingly. If you need dial-in, configure Jigasi as the SIP gateway and test with your telephony provider. Confirm how recordings are stored, who can download them, and how retention is applied. The output is a tested recording and dial-in path, with a note of any Zoom feature you could not reproduce.
Run a parallel period with pilot groups
Move a limited set of teams to Jitsi while Zoom stays active for everyone else. Give pilot users a short guide covering joining, screen sharing, and the features that changed, and collect issues in one tracker. Keep Zoom meetings open for participants who cannot yet use Jitsi, and log which meetings still run on Zoom. The output is a defect list with each item triaged and a sign-off from each pilot group that its regular meetings work on Jitsi.
Cut over and retire Zoom
Update calendar invitations, bookmarks, and room links to the Jitsi address, and point any integrations at the new service. Set a cutover date agreed with the business owners, then stop scheduling new Zoom meetings. Keep the archived recordings and transcripts accessible through the migration archive. The output is a change record showing every calendar template and integration repointed, with the Zoom account status confirmed by the administrator.
Decommission Zoom and document the platform
After the cutover is stable, remove Zoom licenses, disable the integrations that were repointed, and confirm the archive is backed up to a location you control. Document the Jitsi architecture, the authentication configuration, the scaling procedure, and the upgrade process, and assign owners for patching. Your auditors or compliance team should receive the evidence, since DeployOpen prepares the controls and records but independent assessors issue any attestation. The output is a decommission record and a runbook that a new administrator can follow.
What data and integrations to move or rebuild
Leaving Zoom means moving four kinds of material: recordings and transcripts, user accounts, calendar invitations and room links, and the integrations and reports built around meetings. Only the recordings and transcripts have a documented export path, so the other items need an inventory and a rebuild plan before the Zoom tenant is closed.
Recording and transcript archives
Zoom saves cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, which can be downloaded from the recordings page. Download them before any Zoom license ends, then store them in an archive your records policy covers, with a folder layout that maps each file to its meeting date and host. Check that the chat and caption files travel with their video, because a recording without its transcript loses searchable content. Confirm your retention obligations before deleting anything from Zoom.
User accounts and identity source
Zoom accounts, groups and roles define who could host and who could join. Jitsi Meet does not inherit these, so decide the identity source first: internal XMPP accounts, JWT tokens, LDAP, or Matrix user verification, all set through the .env file in the Docker setup. Export your current user list from the Zoom admin console and map each person to a role on the new platform. Confirm which accounts need host rights before rollout.
Calendar invitations and room links
Recurring Zoom invitations carry meeting IDs, dial-in details and passcodes that people have saved in calendars and bookmarks. Jitsi rooms are named by you, so there is no automatic mapping from old Zoom links. Publish a new room naming scheme, update recurring calendar series for each team, and set a redirect or notice for the old links for a period you agree with business owners. Check which external partners and LMS pages also embed Zoom links.
Integrations that need rebuilding
Calendar plug-ins, LMS and CRM connectors, Slack or chat apps, and single sign-on connections configured in Zoom do not carry over to a self-hosted Jitsi deployment. Inventory every app connected to your Zoom account and record what each one does and who owns it. Then decide per integration whether Jitsi supports it through JWT-based room creation or whether a different tool replaces it. Document each rebuild as a separate work item.
Reports, settings and policies
Zoom admin settings such as waiting rooms, recording permissions, meeting length rules and external sharing policies must be written down and re-created by hand on the self-hosted stack. Export or screenshot the current settings, list the reports your managers rely on for usage and compliance, and decide which reports you will replace with logs from your own servers. Record who approved each policy so the new configuration can be traced to a decision.
Recording storage and access records
Jibri recordings are written to storage you run, so the migration creates a new retention and access-control scope. Decide where recordings from the new system will be kept, who can open them, and how long they stay. Keep an access log of the archived Zoom material as well, so that auditors can see who retrieved sensitive recordings after the move. Ask your security team to confirm the storage encryption and backup approach before go-live.
How the Jitsi Meet components fit together
A basic Jitsi Meet deployment is a small set of cooperating services, and knowing which one does what makes the firewall, certificate and sizing decisions much easier. A web server (nginx or Apache) serves the web app that users load in their browser. Prosody, an XMPP server, handles signaling and accounts. Jicofo, the conference focus, creates conferences and decides which Jitsi Videobridge (JVB) instance hosts each participant's media. The videobridge is the component that actually routes audio and video, and it is the one you scale by adding machines. Jibri (recording and streaming) and Jigasi (SIP gateway) are optional and join the conference as extra participants: Jibri records or streams a meeting from a browser session, and Jigasi bridges SIP endpoints into it. Each one is a separate service you enable only if you need it, which is why the Docker setup runs them as their own containers.
Ports are the first thing your network team will ask about. Plan for 80/TCP and 443/TCP for the web app and certificate issuance, and 10000/UDP for media through the videobridge. The Debian and Ubuntu quick start also lists 5349/TCP as a TCP fallback for clients that cannot reach UDP, and 3478/UDP for STUN, both optional. Confirm with your network team whether these are reachable from the outside and from internal segments where users sit, because a blocked UDP path is the most common reason calls fall back to poor quality. Check the current port list in the self-hosting guide before you open firewall rules, since the handbook is the authority on what each release expects.
HTTPS is not optional. The Jitsi handbook states that HTTPS is necessary for multimedia to work, and it calls for a certificate issued for your real domain. Self-signed certificates cause trouble in practice, especially on mobile clients, which often refuse to trust them. The result is a meeting that loads in a desktop browser but fails to connect audio or video on a phone. Decide early how certificates will be issued and renewed, for example through an internal certificate authority that your mobile fleet already trusts, and test a call from a managed phone before rollout. Treat certificate renewal as an ongoing operational task with an owner, not a one-time setup step.
How the migration differs by size and starting point
A small team usually starts with the official Docker setup, which runs separate containers for the web front end, Prosody, Jicofo, Jitsi Videobridge, and optionally Jigasi and Jibri. This path keeps the install small and repeatable, and it suits a single host that serves a modest number of staff meetings. Because the containers are configured through an .env file, most of the work is choosing a domain, certificates and an authentication method, then testing from outside your network.
- Domain and HTTPS: You need a proper domain certificate before anything else, since the Jitsi handbook says HTTPS is necessary for working audio and video and warns against self-signed certificates.
- Authentication: Pick internal XMPP accounts, JWT tokens, LDAP or Matrix verification in
.env, and plan token authentication for anything customer-facing. - Network ports: Open 80/TCP, 443/TCP and 10000/UDP, and test whether your firewall passes media for users on restricted networks.
- Scaling limits: One host is a single point of failure, so plan to add videobridges as usage grows.
- Updates: You will pull new images yourself, so assign an owner for patching.
Confirm with your team how many concurrent meetings you expect, and whether your current meeting traffic relies on features the single-host setup does not cover.
Larger organizations often prefer the Debian or Ubuntu packages, which fit existing configuration management and patching routines. The quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and it requires OpenJDK 17. This path also makes it easier to separate the central server from one or more videobridges, which is the basis for horizontal scaling.
- Supported operating systems: Confirm your hosts run Debian 12 or newer, or Ubuntu 24.04 or newer, before you build them.
- Central server and bridges: 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, as a starting point to test against your load.
- Horizontal scaling: The default install is already configured for adding bridges, so new capacity is mostly new hosts.
- Configuration management: Capture settings in Ansible, Puppet or a similar tool so rebuilds match production.
- Change control: Schedule upgrades through your normal change process, since each component can be patched separately.
Confirm your hosting platform, your OS standard and who owns the configuration management tooling before you choose this path.
Organizations that record meetings or dial in from phones need Jibri and Jigasi, which add components and infrastructure beyond the core meeting service. Jibri records and streams, and the Jitsi Docker guide describes it as a separate container. Jigasi acts as the SIP gateway. Each adds server work and, for recording, a storage plan. Recording is also where existing Zoom habits, such as cloud recordings and transcripts, need the most attention.
- Jibri capacity: Plan one recording per Jibri instance, so concurrent recordings drive how many instances you run.
- Storage: Recordings accumulate quickly, so size disk and retention before the first session is recorded.
- Consent and policy: Document who is told when a meeting is recorded and where recordings are kept.
- SIP trunk: Jigasi needs a SIP provider or PBX, which you must arrange and test separately.
- Transcription: Speech-to-text tools such as Whisper or Vosk are separate projects that you would integrate yourself.
Confirm how many simultaneous recordings and dial-in calls you expect, and whether your legal or records team accepts a self-managed recording store.
Webinars and town halls put different load on a meeting platform than internal calls do. Jitsi can live stream a meeting through Jibri, but large audiences, registration and question handling are not part of the core meeting service. Teams that rely on Zoom webinars should decide early whether Jitsi covers their format or whether another platform is a better fit for presenter-led sessions.
- Audience size: Test with the largest audience you expect, since bridge and streaming capacity drive the design.
- Registration and Q&A: These usually come from other tools, which you must select and integrate.
- Live streaming: Streaming relies on Jibri, so the same single-recording-per-instance limit applies.
- Presenter roles: Confirm the moderation and presenter controls your speakers need.
- Fallback plan: Keep a second meeting route ready for critical events.
Confirm your largest audience size, your registration workflow and whether your webinar format fits a Jitsi live stream before you commit to this path.
What drives cost and duration in a Jitsi Meet migration
This table breaks a Jitsi Meet migration from Zoom into the components that carry cost and effort, marking which are one-time and which recur. Use it to see what raises or lowers each line and what to request in a written quote before comparing proposals.
| Component | Who is paid or what it covers | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Videobridge capacity | Servers or cloud instances for Jitsi Videobridge; the scalable guide suggests 4 or 8 CPUs with 8 GB RAM per bridge | Mostly recurring (hosting), plus one-time sizing | Peak concurrent participants, video versus audio use, and whether you add bridges horizontally |
| Central server | Prosody, Jicofo and the web front end; the scalable guide suggests a 4 CPU, 8 GB machine | Recurring hosting | Number of bridges and concurrent conferences; a separate central host keeps scaling simpler |
| Recording storage and Jibri | Storage for recordings and the Jibri hosts that capture them; each Jibri instance records one meeting at a time | Recurring storage; one-time Jibri host setup | Hours recorded, retention rules, and the number of Jibri instances needed for simultaneous recordings |
| SIP integration with Jigasi | Telephony trunk from your carrier and the Jigasi host | Recurring carrier charges plus one-time configuration | Dial-in volume, number of concurrent phone participants, and whether you already own a SIP trunk |
| Authentication choice | Internal XMPP accounts, JWT tokens, LDAP or Matrix verification, configured in the .env file | One-time integration; ongoing directory maintenance | Whether you already run a directory; JWT needs an application that issues tokens |
| Certificates and HTTPS | Domain name and a publicly trusted certificate, which the handbook says is necessary for working audio and video | Recurring renewal; one-time DNS and firewall work | Whether you already have certificate automation; self-signed certificates cause problems, especially on mobile |
| User rollout and training | Internal staff or your implementation partner for guides, pilots and support scripts | One-time, with some recurring help desk time | Number of users, number of meeting rooms and integrations, and how many Zoom habits you must change |
| Operations staff | Internal platform or IT staff for updates, monitoring, backups and incident response | Recurring | Release cadence, uptime expectations, and whether ongoing support is contracted |
Questions buyers ask before moving from Zoom to Jitsi Meet
What does it cost to move from Zoom to self-hosted Jitsi Meet?
Jitsi Meet itself is licensed under Apache 2.0, so the license line is zero, and the cost sits in the components around it. Budget for servers or cloud instances for the web front end, Prosody, Jicofo and videobridges, bandwidth and TURN capacity for users behind strict firewalls, storage for any recordings, and the people who deploy and run it. Infrastructure is recurring, while design, integration and rollout are largely one-time. Costs rise with concurrent participants, recording volume and the number of networks you must traverse. Ask any provider for a quote that lists each of these components separately, plus the Zoom licenses you will keep running during the overlap period.
How long does a Jitsi Meet migration take?
No timeline figure is supplied here, so treat any duration as a planning assumption to confirm. The main drivers are how many meeting types you have, whether you need recording with Jibri, SIP dial-in through Jigasi, and single sign-on or JWT integration with your identity provider, and how many users must be trained. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask for a schedule that separates infrastructure, authentication, recording and user rollout, and that includes a parallel run with Zoom.
Can our internal team migrate Zoom to Jitsi Meet without outside help?
Yes, a team with Linux, DNS, certificate and network skills can deploy Jitsi Meet with the Docker setup or the Debian and Ubuntu packages, since both are documented by the Jitsi handbook. The harder parts are sizing videobridges, configuring TURN and firewall rules, building JWT authentication into your applications, and operating recording. Ask yourself who will patch the stack, respond to incidents and own the upgrade cycle after go-live. If that ownership is not staffed, an implementation partner can plan, implement and document the system, and offer ongoing support as a retainer.
What does the migration need from IT and end users?
From IT, you need a public DNS name, a valid certificate from a trusted authority, and open ports: 80/TCP and 443/TCP for the web app, 10000/UDP for media, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. The Jitsi handbook warns that self-signed certificates cause problems, especially on mobile clients. From users, the change is mostly a new meeting link and, for organizations using SIP or recording, new dial-in and retrieval steps. Plan a pilot group, short guides for joining from browsers and mobile apps, and a date after which Zoom links stop being issued.
How should authentication be set up for Jitsi Meet?
Use JWT token authentication rather than the older secure domain method. The Jitsi handbook marks the secure domain, which relies on username and password room creation, as deprecated for new installations, and it recommends JWT tokens with a separate anonymous domain for guests. The Jitsi Docker guide also lists internal XMPP accounts, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, configured through the .env file. Decide early which identity source issues tokens, because your meeting application or portal must sign those tokens. Confirm the chosen options against the current handbook before you build.
What happens to our existing Zoom recordings and transcripts?
Download them from Zoom before you cancel the account, because Zoom does not move them to Jitsi for you. Zoom saves cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, which you can fetch from the recordings page. Store them in a retention system you control, with an index that maps each file to its meeting, owner and retention class. Jibri records new Jitsi meetings, and one recording runs per Jibri instance, so size recording capacity for your peak concurrent recordings. Ask any provider to confirm how they will handle archives and transcription before work starts.
How do we size the videobridges for our meeting load?
Videobridges scale horizontally, so you add more as concurrent use grows. 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. Use those figures as a starting point, then load test with your real meeting sizes, camera use and screen sharing, and add recording and SIP traffic on top. Ask for a load test report as a deliverable in any quote.
What usually goes wrong and how to prevent it
Most failed Jitsi migrations fail in the same few places: certificates, server capacity, network ports, lost data, and users who cannot find their meetings. Each card below names one of these risks, why it matters for a Zoom exit, and the check to run before users are moved.
Self-signed or expired certificates
Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile clients. Use a publicly trusted certificate on the Jitsi domain and test it on iOS and Android before launch. Set a renewal reminder or automate renewal, because an expired certificate stops meetings for everyone at once.
Undersized videobridges under peak load
Zoom users often join many meetings at the start of the hour, so a single videobridge can saturate in the middle of a busy day. The Jitsi scalable setup guide suggests a 4 or 8 CPU machine with 8 GB RAM for each videobridge and a central server, and says the default install is configured for horizontal scaling. Size for your peak concurrent participants, not your average, and add bridges before you need them. Ask your team to load test with realistic meeting sizes.
Missing UDP media ports
Jitsi's Debian and Ubuntu quick start needs port 10000 over UDP open for media, with 443/TCP for TCP fallback, and 5349/TCP and 3478/UDP are optional fallbacks. A firewall that allows only web traffic will let users load the page but fail to hear or see anyone. Open the media ports on both the host firewall and the cloud security group, then test from a network that blocks UDP. Remote and home users behind restrictive networks are the first to report the fault.
Recordings lost before export
Zoom cloud recordings, transcripts and chat files are not carried over by a Jitsi install, and they can disappear when the Zoom account is closed or downgraded. Download MP4 video, M4A audio, TXT chat, VTT transcripts and CC.VTT captions for every account before you cancel. Make the export a signed-off step in the cutover checklist and confirm the file count against the Zoom recordings list. Store the archive in a location with its own retention rules.
Users cannot find new room links
Zoom users know meetings by their numeric IDs and personal links, and those stop working when Zoom is switched off. Calendar invitations, bookmarks and LMS links keep pointing at the old service. Publish a naming convention for Jitsi rooms, update calendar templates, and set a dated redirect message on the old Zoom links for the cutover window. Give each team a short internal guide with the new link pattern and a contact for help.
Unmanaged room creation
On a default Jitsi install, anyone who knows or guesses a room name can join it and can create one. The older secure domain method is deprecated for new installations, and the Jitsi handbook recommends JWT token authentication with a separate anonymous domain for guests. Choose the authentication model in the Docker `.env` file before go-live, and decide who may host meetings. Confirm which identity source you will connect, such as LDAP or your SSO, and document the rules for external guests.
How DeployOpen runs the Jitsi Meet migration
DeployOpen works from a written scope agreed before any work starts. For a Zoom to Jitsi Meet migration, that scope names the components to be built in your own infrastructure: the web front end, Prosody, Jicofo, Jitsi Videobridge and, where you need them, Jibri for recording and Jigasi for SIP. It also records the decisions that shape the build, such as which authentication mode the .env file will enable, how TLS certificates are issued for your domain, which videobridge hosts sit behind the front end, and who in your organization signs off each phase. Deliverables are listed alongside those decisions, so you can see what you receive at the end of each phase. Most engagements are fixed-scope, and ongoing upgrades and support can be covered by a separate retainer once the platform is live. Because DeployOpen implements inside your cloud accounts, data centers or air-gapped network, the servers, DNS records and recordings stay under your control throughout the work.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move the price are the ones you should settle first: the number of users and concurrent meetings, whether recording and SIP dial-in are required, how many authentication modes you need to support, whether the Zoom export and archive work is in the same engagement, and what hardening, backup and documentation standards your internal policies require. Ask for the quote to separate one-time build work from recurring retainer work, and to state which items you own after handover, including configuration, runbooks and evidence for your compliance team. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification, so ask your auditor early which artifacts they expect to see.
