How do you run Zoom classes from Moodle without managing two systems?
The supported way to run Zoom classes from inside Moodle courses is the community Zoom meeting plugin, mod_zoom, which is maintained by Jonathan Champ, Steve Bader and Alan McCoy. It requires a business or educational Zoom account, so confirm your Zoom licence tier before any teacher creates a session. The plugin covers meeting and webinar creation, synchronization with Zoom, grading, and backup and restore. DeployOpen plans and delivers this work inside your own Moodle and Zoom accounts, so the configuration stays in systems your organization already controls.
The two-systems problem appears when teachers create a meeting in Zoom, then separately add a link in Moodle, and nobody can say which record is authoritative. Before installing anything, decide who owns the Zoom account and which credentials Moodle uses to talk to it. Then decide how hosts are assigned. A single institutional account can host every course meeting, while per-teacher licensed hosts give individuals control of their own sessions and recordings. Host assignment determines who can start, edit and delete a meeting, so it should be settled with the academic and IT owners together.
Synchronization is where most drift starts. If a teacher edits a meeting directly in the Zoom web portal, the Moodle activity may no longer describe the same session. Set a written edit policy: meetings are changed only from Moodle, or only from Zoom, with the other side treated as read-only. For grading, confirm exactly what the plugin records and how that data reaches the gradebook, such as attendance or participation, and check it against your own grading rules using a sample course before any live term begins.
Backup and restore need their own test. Copying a course to another Moodle site or restoring it from a backup may create new Zoom meetings, point at old ones, or leave recordings behind in an account that no longer matches the course. Run a restore on a non-production copy and confirm three things: which meeting IDs the restored activities reference, whether recordings remain accessible, and who can see them. Align the recording retention settings in Zoom with your institution's records policy so that recordings are neither lost early nor kept longer than intended.
Keeping the integration current is a recurring task, not a one-time install. The plugin directory lists support for Moodle 3.4 to 5.2, and Moodle 5.3 is the next long-term support release. Before any Moodle upgrade, check the plugin's supported versions in the directory and rehearse the upgrade on a staging copy that includes a Zoom account test. Ask DeployOpen for a written scope that names the Zoom app setup, the test cases for synchronization, grading and restore, and the steps for each future upgrade.
What must be in place before the Zoom plugin is installed
Six prerequisites decide whether the Zoom plugin installs cleanly and keeps working. They cover the Moodle version and server stack, the Zoom account and administrator, the network path between Moodle and Zoom, and a staging copy for testing before production changes.
Plugin support for your Moodle version
The Zoom meeting plugin (mod_zoom) lists support for Moodle 3.4 to 5.2. Check that range against the version you run before installing. Treat any site on Moodle 5.3 or later as unconfirmed until the plugin's directory listing or its maintainers show support for that release. Moodle 5.3 is the next long-term support release, so many sites will reach it on their own schedule. Confirm plugin support before scheduling that upgrade, and read the plugin's release notes for each version you plan to cross.
Server requirements for your running version
Each Moodle release sets its own PHP and database minimums, and the plugin runs on the same stack as Moodle core. Moodle 5.1 requires 64-bit PHP 8.2 or later, and supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. From Moodle 5.1, the web server document root must point to the new public directory, or the site may show directory listings or errors. Check the web server configuration in the same change window, and compare your PHP and database versions against the release notes for your target version.
Zoom business or educational account
The plugin requires a Zoom business or educational account. Confirm the plan on the account that will host meetings and webinars before any installation work starts. Ask which Zoom features your plan includes, such as webinars and cloud recording, because meeting creation, recording and reporting depend on the plan level. Record the account owner and plan level in your implementation notes, so the choice stays traceable when Zoom changes its licensing terms.
Zoom administrator to authorize the app
A Zoom administrator must create and authorize the app that lets Moodle act on the account's behalf. Agree on that person before installation and confirm they will remain involved after go-live. Confirm the app setup steps in the plugin documentation for your Moodle version. Store the app credentials in your secrets manager and keep them out of shared documents. Name a second administrator as a fallback, so authorization can be renewed or reviewed if the first person leaves.
Network access from Moodle to Zoom
Moodle servers must reach Zoom's API endpoints over outbound HTTPS, because the plugin needs that path to create, update and delete meetings and webinars. Check the egress rules of firewalls, proxies and cloud security groups between your Moodle web and task servers and the internet. Confirm the domains and ports listed in the plugin documentation for your version. Test from the same host that runs Moodle cron, since scheduled synchronization runs there as well.
Staging copy of Moodle for testing
Install and test the plugin on a staging copy of the production site before changing production. The copy should match the production Moodle version, PHP version, database engine and web server configuration. Restore a recent copy of production data, and replace live Zoom credentials with test credentials. Use the staging site to check meeting creation, synchronization, grading, backup and restore, and the upgrade path to a later Moodle release.
How the mod_zoom plugin links Moodle activities to Zoom meetings
The mod_zoom plugin adds a Zoom activity type to Moodle courses, so a teacher places a Zoom session in a course the same way they add a quiz or an assignment. Each Zoom activity is a Moodle activity record that stores its settings and points to a meeting or webinar on the Zoom side. The plugin is maintained by Jonathan Champ, Steve Bader and Alan McCoy and is listed as supporting Moodle 3.4 through 5.2. Check that your target Moodle release falls inside that range before you plan an upgrade, and confirm the supported range on the plugin page, because a newer core release may need a newer plugin build.
Meetings and webinars are both created from Moodle, and the plugin's documented feature list covers both. Decide early which activities need a webinar and which need a meeting, because the Zoom licensing behind each may differ. Confirm with Zoom which plan features webinars on your account. Synchronization is the part that needs the closest review. Confirm which meeting fields stay aligned between the two systems, such as topic, start time, duration and recurrence, which direction changes flow, and what happens when someone edits a meeting directly in Zoom. Those edge cases shape the support load after go-live.
The plugin documents grading and backup and restore support for Zoom activities. Confirm how grading is recorded for a Zoom activity in your version, including whether it links to a gradebook item or to attendance, since that determines what reaches the gradebook. For backup and restore, run a course copy on a staging site before relying on it. Check whether the restored activity keeps its link to the original Zoom meeting or creates a new one, and what happens to recordings and registrations. Write the results into your runbook so course teams know what to expect after a restore.
The plugin requires a business or educational Zoom account, so a personal account will not meet the requirement. On the Zoom side, an account owner or administrator must provision the account and authorize the API access the plugin uses, and someone must hold the rights to create webinars if your courses use them. On the Moodle side, a site administrator installs the plugin and connects it to the Zoom account, and course editing teachers then need the capabilities to add activities. Confirm the exact connection steps, required Zoom permissions and settings screens in the plugin documentation for your Moodle version before assigning these roles.
Setting up the Zoom meeting plugin in order
This sequence takes a Moodle site from a staging installation to a verified Zoom activity that teachers can use in a pilot course. Each step ends with a check you can run, so problems surface before the plugin reaches live courses. Confirm the supported Moodle versions and your Zoom account type with your Zoom administrator before you begin.
Confirm Moodle version and server requirements
The Moodle administrator checks the Moodle version in production against the versions the Zoom meeting plugin supports, which the plugins directory lists as Moodle 3.4 to 5.2. If the target release is newer, such as 5.3, confirm with the plugin maintainers that a compatible release exists before you proceed. Then check the server against the requirements for that Moodle release, including PHP version, database engine and, from Moodle 5.1, a web server document root that points to the /public directory. Done means you have a written record of the Moodle version, PHP version, database version and web server configuration, and each one matches the release notes for the target version.
Install the plugin on a staging site
Install the Zoom meeting plugin on a staging copy of the production site, not on production itself. Download the package from the Moodle plugins directory, add it through the site's plugin installation screen or your deployment tooling, and complete the database upgrade that Moodle prompts for. Keep the staging site on the same Moodle version and server stack as production so the results carry over. Done means the Zoom activity module appears in the site's plugin overview with no installation errors, and the plugin's check screen reports no outstanding problems. Record the plugin version, because you will need it when you plan upgrades.
Connect the Zoom account and authorize the app
Confirm with your Zoom administrator that the account is a business or educational account, since the plugin requires one. The Moodle administrator then enters the Zoom connection details in the plugin settings, and the Zoom administrator authorizes the app in the Zoom account. Use an account owned by the organization, not a personal teacher login, so meetings survive staff changes. Done means the plugin's connection check succeeds and the staging site can list the users or meetings the account exposes. If authorization fails, check that the Zoom administrator has permission to approve third-party apps and that the connection settings match the app details exactly.
Set meeting and webinar defaults
Decide the defaults that new Zoom activities inherit before any teacher creates one. Typical decisions include whether meetings are created with a host, whether the waiting room is on, recording options, and whether webinar activities are enabled at all. Review each setting with the teaching team and your Zoom administrator, because Zoom's own account policies can override or restrict these choices. Save the settings on the staging site. Done means a new test activity in a test course opens with the defaults you chose, and the meeting it creates reflects the same options in the Zoom account. Note any setting that Zoom's account policy blocks, so you can explain it to teachers.
Enable the activity for a pilot course
Choose one course with a small group of teachers and students to pilot the activity. Confirm that the Zoom activity appears in the activity chooser for that course, which depends on the site's activity settings and course format. Ask a teacher to add the activity to a section and set its name and description. Limit the pilot to this course so any issue affects few learners. Done means the activity can be added to the pilot course by a teacher account, and it appears in the course page for students with the expected visibility. If it does not appear, check whether the Zoom activity is enabled site-wide and whether the teacher role has permission to add it.
Run a test meeting
From a teacher account in the pilot course, create a Zoom meeting activity and start or join it from Moodle. Use a second account to join from another browser, so you confirm that participants can reach the meeting from Moodle. Then check the Zoom account to see that the meeting exists with the expected host, time and settings. End the meeting and return to the Moodle activity to confirm the page reflects the session. Done means the meeting appears in the Zoom account when created from the test course, the join link opens the session, and the activity returns to Moodle after the meeting ends. Repeat this check after any change to the defaults.
Check grading and backup before going live
Run the grading path next. Confirm that the activity creates a gradebook item if you enable grading, then record a test grade or participation result and check that it appears in the course gradebook for the test student. Next, back up the pilot course and restore it to a separate course on the staging site. Check that the Zoom activity and its settings survive the restore, and that the restored activity still points to the correct Zoom meeting or is clearly marked for re-creation. Done means the gradebook shows the test result, and the restored course contains a working Zoom activity or a documented procedure to recreate it.
Which Moodle and Zoom fields must line up
This table pairs each Moodle object with its Zoom counterpart and states which side owns the value during synchronization. Read it before configuration to decide where course, user and meeting data should be edited, because a field edited on the wrong side is often overwritten on the next sync. Field names and sync direction differ between plugin versions, so confirm each row against the mod_zoom documentation for your release before you build.
| Object | Moodle side | Zoom side | Source of truth and what to confirm |
|---|---|---|---|
| Courses and enrolments | Course shell and enrolled users with their Moodle roles | No direct course object; relevant only through meeting host and invitee lists | Moodle is the source for enrolment. Confirm whether the plugin pushes participant lists or only uses them for access checks. |
| Teacher roles and host users | Teacher and editing teacher roles in the course | Licensed host user who owns the meeting | Map each Moodle teacher to a Zoom host account in the plugin settings. Confirm how the plugin handles a teacher without a matching Zoom licence. |
| Meeting objects | Zoom activity instance inside a course section | Meeting ID, topic, start time and settings | Moodle usually owns the activity name, section and visibility. Confirm which meeting settings Moodle pushes and which Zoom edits are overwritten. |
| Webinar objects | Zoom activity configured as a webinar type | Webinar registrants and panelists | Zoom owns registrant and panelist data. Confirm whether the plugin supports webinars for your Zoom account type and version. |
| Activity settings | Recurrence, join before host, waiting room and password options | Matching meeting settings on the Zoom object | Moodle is the source at creation. Confirm which edits made in Zoom are pulled back and which are reset on the next Moodle save. |
| Grade items | Grade item and gradebook entries for attendance or participation | Participant reports from past meetings | Moodle owns the grade. Confirm whether participant data is imported automatically or must be matched to users by email or Zoom ID. |
| Recordings | Activity links and access to recordings in the course | Cloud recordings and their storage location | Zoom owns the recording file. Confirm whether the plugin lists recordings in Moodle and how access rights are checked. |
| Backup contents | Course backup including the Zoom activity definition | Meeting object, which is not copied by a course backup | Moodle backup carries the activity settings. Confirm how a restored activity is re-linked to a meeting and whether a new Zoom object is created. |
How to secure the Zoom connection and the data it touches
The Zoom meeting plugin connects two systems that each hold their own permissions and stored data. The cards below cover the decisions to make before classes run, from the credentials Moodle holds to the recordings and attendance data kept in the Zoom account.
Zoom app credentials and storage
The plugin needs credentials for a Zoom app so Moodle can create and update meetings for the account. Identify the administration page where the plugin asks for them, confirm in the plugin documentation whether they are stored in the Moodle database or elsewhere and whether they are encrypted, and limit who can view or change them. Plan how credentials are rotated and revoked when the person who configured them leaves.
Least-privilege Zoom role for the plugin
The account the plugin uses should hold only the Zoom permissions that meeting and webinar work requires. Ask your Zoom administrator to create a dedicated user or role, document which account settings it can change, and confirm with the plugin documentation which permissions it needs. Use a dedicated account separate from any personal administrator login, and include it in each access review, since a broad role affects every course the plugin serves.
Who can create meetings and webinars
Creation rights exist in two places: the Zoom account, where licensed users can host and schedule sessions, and Moodle, where staff add Zoom activities to courses. Decide which Zoom users may host, and confirm whether webinars are enabled for your account, since webinars carry their own licensing and permission questions. Test that a teacher without the intended Zoom license cannot start a session before rollout.
Moodle capabilities for Zoom activities
Moodle roles decide who can add Zoom activities, see join links, and edit or delete them, and these checks apply alongside Zoom's own permissions. Review the capability list the plugin provides in the Moodle role settings and compare it against course roles such as teacher, non-editing teacher and student. Confirm that enrolled students can join sessions but cannot change meeting settings, and check how group and course visibility affects each activity.
Recordings and participant data in Zoom
Cloud recordings, chat logs, attendance reports and participant details are kept in the Zoom account, outside the Moodle database, and remain there until someone deletes them or a retention setting removes them. Agree with your data protection owner how long each data type is kept, who may download recordings, and how the Zoom settings match that policy. Confirm in the plugin documentation whether it copies any of this data into Moodle, including through backups.
Keeping the Zoom plugin current across Moodle upgrades
Before every Moodle upgrade, check the Zoom meeting plugin's supported Moodle range against the version you are moving to. The plugin (mod_zoom) is listed on the Moodle plugins directory as supporting Moodle 3.4 to 5.2, so any target outside that range needs a plugin release that explicitly supports it before you touch production. Do not assume the plugin you installed last year still matches the release you are planning. Moodle ships major releases every six months, in April and October, and minor point releases every two months in between, so the window between your planning and your upgrade can easily include a new plugin release. Make the compatibility check a standing step in your upgrade checklist, not a one-time review.
Rehearse every upgrade on a staging copy of the production site before you schedule the change. Restore a recent production database and code directory into staging, install the plugin release that matches the target Moodle version, and run the upgrade there. Then test the paths that matter for classes: creating a meeting from a course, joining from a student account, syncing recordings or meeting data if you use them, grading a Zoom-linked activity, and running a course backup and restore that includes a Zoom activity. Confirm with your Zoom administrator that the Zoom account type and API credentials still work with the plugin version you are testing. Record what you checked, because the staging log is the evidence you will need if something fails later.
Plan the web server change early for Moodle 5.1 and later. From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, otherwise the site may show directory listings or errors. This is a configuration change to your reverse proxy or web server virtual host, and it affects the whole site, not only the Zoom plugin. Decide who owns that change, add it to the staging rehearsal, and confirm that the plugin's web-facing endpoints, such as any callbacks used for meeting events, still resolve after the document root moves. Also check the Moodle 5.1 server requirements for PHP and database versions, since they can force a separate infrastructure step before the Zoom test even begins.
Keep a rollback plan and a current backup before each upgrade. The backup should cover the Moodle database, the moodledata directory and the code directory, and you should be able to restore all three to a known state within the change window. Write down the exact steps to revert the code, the plugin version and the web server configuration, and name who makes the call to roll back and by what time. Test the restore on staging as well, because an untested backup is not a rollback plan. Ask your upgrade partner or internal team to state how long a restore takes in your environment, and confirm the Zoom account and API credentials are stored in a way that survives the restore.
How we test Zoom classes before students use them
Functional tests confirm that the activity works from start to finish. A tester creates a meeting and a webinar from a test course, joins each one from a browser and the Zoom client, ends it, and confirms that Moodle shows the correct activity state. This covers the path a teacher uses every week, so it runs first after any configuration change.
- Pass condition: each meeting and webinar is created in Moodle and in the Zoom account, the join link opens the session for the host and for a participant, and ending the session changes the activity state in Moodle.
- Record for sign-off: the Moodle course ID, activity IDs, Zoom meeting and webinar IDs, timestamps for create, join and end, and a screenshot of the activity state after ending.
- Edge case: edit or delete a session directly in Zoom, then confirm how the plugin synchronizes the change back to Moodle.
- Confirm with your Zoom administrator: which webinar features your Zoom account includes, since webinar support depends on the account type.
The sign-off should show that a session created in Moodle can be started, joined and closed without manual repair in either system.
Grading tests check that Zoom-linked activities feed the Moodle gradebook accurately. Grades that are wrong or missing usually surface at the end of a term, when correcting them is slow and affects students directly, so this area needs its own test pass. The tester uses test students enrolled in the course and works through the grade path from entry to gradebook view.
- Pass condition: a grade entered for a test student appears in the gradebook for that student only, the maximum grade and category weighting match the activity settings, and hidden grades stay hidden until released.
- Record for sign-off: a gradebook export taken before and after the test, the grade item settings, the test student IDs and the grade entries with timestamps.
- Re-sync check: change a grade manually, trigger a re-synchronization, and confirm that the manual override is preserved.
- Confirm with the plugin documentation: which grading options your plugin version offers, and whether any participation or attendance data it records is available for grading in your Moodle version.
The sign-off should show that every test grade reaches the correct student and survives a re-sync without changes the teacher did not make.
Backup and restore tests check that a Zoom activity survives course copying, which teachers use for each new term. The main risk is that a restored activity points to the session of the source course, so the tester must confirm which Zoom objects the restored copy uses. The test restores the course into a second, empty course and compares the two.
- Pass condition: the restored course contains the activity with its settings intact, the restored copy does not reuse the source meeting or webinar ID, and the original course keeps its own sessions unchanged.
- Record for sign-off: the backup file name and size, the restore log, the source and target course IDs, and the Zoom meeting and webinar IDs before and after the restore.
- Recurring sessions: confirm how recurring meetings and scheduled dates appear after restore, and whether teachers must update them.
- Confirm with the plugin documentation: the restore behavior for webinars and for activities with registration or host settings in the plugin version you run.
The sign-off should show that a restored course is ready for teaching and that the source course is unaffected by the copy.
Role and permission tests confirm that each person can do what their role requires and nothing more. This area uses at least one teacher account and one student account, each enrolled in the test course, plus a check that access ends when enrolment ends. Permission errors are easy to miss in normal use, and a student who can start a session or see host controls is a visible problem in a live class.
- Pass condition: the teacher can create, edit and start a session, the student can join but cannot edit or start it, host-only controls are not visible to students, and a student who is unenrolled loses access to the join link.
- Record for sign-off: the list of test accounts with their Moodle roles, a log or screenshot of each attempted action with the result, and the timestamps of enrolment changes.
- Cross-course check: a student enrolled in one course must not join another course's session by using a link from the first course.
- Confirm with your Zoom administrator: the Zoom account type the plugin requires, which the plugin documentation states as a business or educational account, and the permissions granted to the account Moodle uses to create sessions.
The sign-off should show that each role can perform only its own actions and that enrolment changes take effect without manual cleanup in Zoom.
Upgrade regression runs the four areas above again on a staging copy after any Moodle upgrade or plugin update, before the change reaches production. Upgrades can change plugin behavior, and an upgrade can also move Moodle outside the range the plugin supports. The staging copy should match production in Moodle version, plugin version and configuration, and should use production-like data where your data policy allows.
- Version check: confirm the target Moodle version is within the range the plugin supports. The plugin documentation lists support for Moodle 3.4 to 5.2, so a target above that range needs a confirmed plugin release first.
- Server check: for Moodle 5.1 and later, confirm that the web server document root points to the public directory, as the Moodle 5.1 release notes require.
- Pass condition: all four earlier test areas pass on staging after the upgrade, and the Moodle logs show no errors from the Zoom plugin during the test run.
- Record for sign-off: the Moodle and plugin versions before and after, the upgrade log, the pass or fail result for each area, and the sign-off from the course owner.
The sign-off should show that the upgraded staging site passes every area before the same change is applied to production.
Why Zoom activities fail in Moodle and how to fix them
This table lists the failures most often seen when a Zoom activity stops working in Moodle, with the cause and the fix for each. Read each row against your own Moodle version, Zoom account and network before changing anything. The main takeaway is that most failures trace back to version compatibility, account type, or authorization, and each one should be checked before rebuilding activities.
| Failure | Likely cause | Fix and what to confirm |
|---|---|---|
| Zoom activities stop working after a Moodle upgrade | The Moodle version in use is outside the range the Zoom meeting plugin (mod_zoom) lists as supported, which the plugin directory gives as 3.4 to 5.2 | Check the plugin directory for a release that supports your target Moodle version before upgrading. Confirm the plugin version against your Moodle release notes and test on a staging copy first. |
| Zoom meetings cannot be created or used by teachers | The Zoom account is a basic or free account, but the plugin requires a business or educational Zoom account | Confirm the account type with your Zoom administrator and upgrade or change the account before configuring the plugin. Confirm which Zoom features your institution needs, such as webinars or cloud recording. |
| Zoom connection fails or meetings stop syncing | The Zoom app authorization or API credentials were revoked, rotated or expired | Reauthorize or update the Zoom app credentials in the plugin settings, then run a test meeting. Confirm who in your Zoom admin team owns the app and how credential rotation is scheduled. |
| Site shows directory listings or errors after upgrading to 5.1 | The web server document root still points to the main Moodle folder instead of the new /public directory, which Moodle 5.1 requires | Point the web server document root to the /public directory and restart the web server. Confirm this change in the web server configuration with your platform team before and after the upgrade. |
| Zoom meetings cannot be reached from the server or from users | Outbound network rules block the Moodle server or user networks from reaching Zoom endpoints | Ask your network team to allow the Zoom domains and ports that the plugin and Zoom clients need, and test from the Moodle server. Confirm the current endpoint list with Zoom's own documentation. |
| Meetings are missing or point to the wrong session after a restore | Restored courses keep activity records, but the linked Zoom meeting may not exist in the target Zoom account or may belong to another host | After restore, check each Zoom activity and recreate or resync meetings as the plugin documentation describes. Confirm backup and restore behavior in the plugin version you run. |
| Grades in Moodle do not match Zoom records or attendance | Grades and attendance are stored in different systems, and sync timing, host changes or edited Zoom reports can leave them out of step | Define which system is the record of truth for attendance and grades, then test a sample activity end to end. Confirm the grading and reporting options your plugin version supports. |
Questions buyers ask before hiring help with the Zoom integration
What drives the cost of a Moodle and Zoom integration project?
Cost follows the amount of configuration, testing and custom work in your environment. The main drivers are the number of courses and meeting types to configure, your Zoom account structure (a single account, several accounts, or sub-accounts that each need setup), the number of Moodle versions in play across production, staging and any other sites, the depth of testing you require, and any custom grading or reporting beyond what the plugin provides. The partner is paid for scoping, configuration, testing, documentation and handover. Zoom licenses are a separate cost you pay to Zoom directly, and they recur. Ask for a quote that itemizes each driver, separates one-time work from recurring support, and names the Moodle and Zoom versions it covers.
How long does a Zoom integration take to deliver?
Duration is set by the written scope, so ask for a plan built from that scope. A single Moodle site with one Zoom account and a modest course set takes less time than several sites, multiple Zoom accounts and custom reporting. Typical phases include discovery, staging setup, configuration, test rounds with teachers and students, cutover and handover. Ask for each phase with its entry and exit criteria, the point where testing sign-off happens, and the dependencies on your side such as access approvals, Zoom account changes and change windows. Scheduling risk often sits with access requests and the availability of your Zoom administrator, so confirm those early.
What must our team provide before the integration work starts?
Four inputs unblock most projects. Moodle administrator access lets the team install and configure the plugin on staging. A Zoom administrator can create or approve the app credentials and manage users and licenses. A staging site should mirror production closely enough to test your real course structures. Test users should cover each role that will use the integration, including teachers, students and an administrator who can review settings. Confirm who approves production changes and when cutover windows are available. Ask the partner to list these items in the written scope with a named owner for each, because missing access is a frequent source of delay.
Can our internal team build the Zoom integration without outside help?
Yes, if your team has Moodle administration experience, can install and configure a community plugin, and has a Zoom administrator available for the account side. The plugin is documented and maintained by a named group of developers, so the setup steps are within reach of a capable team. The harder parts are usually testing across roles, deciding how the Zoom account structure maps to courses, keeping the plugin aligned with each Moodle upgrade, and documenting the setup so someone else can maintain it. Before starting, decide who owns testing sign-off and who will run the next upgrade. If those owners are already committed, an internal build is a reasonable choice.
Which Moodle versions does the Zoom meeting plugin support?
The plugin directory lists support for Moodle 3.4 through 5.2, so check the exact compatibility of your target version before committing. Moodle 5.3 is the next long-term support release, released on 5 October 2026, so a site moving to it needs the plugin's release for that version checked and tested on staging first. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must run Moodle 4.4 or later to upgrade. Moodle 5.1 requires 64-bit PHP 8.2 or later and a web server document root that points to the new /public directory. Confirm each of these against the plugin's own release notes.
What happens to the Zoom integration after go-live?
Ongoing work covers keeping the plugin compatible with each Moodle release, verifying meetings, recordings and grading after upgrades, handling Zoom account and license changes, and confirming that backups restore correctly. Moodle ships minor point releases every two months in February, April, June, August, October and December, and major releases every six months in April and October, so a compatibility check is a recurring task. Decide who owns each item: your team, the partner under a support retainer, or a mix. Ask the partner what the handover includes, how upgrade testing is run on staging, and how changes to the Zoom account are logged. Support and upgrades are available as retainers, scoped separately from the build.
Does the Zoom meeting plugin require a specific type of Zoom account?
The plugin requires a business or educational Zoom account, according to its plugin directory listing. Confirm with your Zoom administrator which plan you hold, whether it includes the webinar features you plan to use, how many licensed users the integration will touch, and whether your organization uses sub-accounts or a single account owner. Those answers change the setup, the permissions model and the testing matrix. Also confirm how recordings are stored and retained in your Zoom account, since that determines what learners can access after a class. Put these account details in the written scope so the quote reflects your actual structure.
How DeployOpen scopes, delivers and supports the Zoom integration
DeployOpen treats the Zoom meeting plugin as one part of a Moodle implementation in infrastructure you control. We agree the scope in writing before work starts, build and test the connection against your own Zoom account and Moodle version, and hand over documentation your administrators can run without us.
How we scope
- Confirm your Moodle version and whether the Zoom meeting plugin supports it before any build starts.
- Record which Zoom account type you hold, since the plugin requires a business or educational account.
- Agree in writing which meeting, webinar, grading and backup features are in and out of scope.
How we build
- Configure the Zoom app credentials and account connection on a staging copy of your Moodle site first.
- Test meeting and webinar creation, synchronization and grade flow with teacher and student test accounts.
- Verify backup and restore of Zoom activities before anything is released to live courses.
How we hand over
- Document the Zoom account setup, credential handling and plugin settings your administrators will own.
- Record the upgrade check steps the plugin needs whenever your Moodle core version changes.
- Walk your Moodle and Zoom administrators through test results, known limits and the open items list.
How we support
- Offer ongoing support and plugin upgrade work as a retainer, agreed separately from the fixed-scope build.
- Re-test the Zoom integration against each Moodle upgrade before your live site moves to the new release.
- Keep a change log of plugin versions, Zoom account settings and configuration decisions for your team.
