Why Moodle for corporate training starts with HR data
Moodle fits corporate training when enrolment, completion and payment are designed around the HR and finance systems that already hold the facts. If staff must finish mandatory courses by a set date, the platform has to know who those staff are, what role they hold, and when they joined or changed roles. If customers or partners pay for courses, the platform has to match each payment to an account and an enrolment without manual copying. Start by mapping those three flows before anyone builds a course. Moodle is licensed under GPL-3.0 and can be self-hosted in infrastructure your company controls, which matters when training records describe employees and customers. The build is mostly configuration, identity and data flow. Course content is one part of it. Expect work on user creation and suspension, cohort or enrolment rules driven by job codes, role assignments for managers who need team reports, and a clear rule for what happens to records when someone leaves the company.
Ask HR and finance to name the source of truth for each attribute before the project starts. For example, the HRIS may own employee status, department and manager, while the finance system owns invoices and payment status for external learners. Decide which system creates accounts, which one removes access, and how often the sync runs. Moodle core includes several authentication options, including external database and LDAP, so the identity design should be settled before the first pilot cohort is loaded.
Write down the completion rules as a specification, not a course outline. For each mandatory course, record the completion criteria (for example, passing a quiz at a stated score or finishing an activity), the due date rule, the renewal interval, and who receives the overdue notice. Confirm these with the compliance owner. A course that completes correctly but records the wrong date will create evidence problems later, so test the reporting view with a manager account and an HR export before go-live.
Paid courses add a second data flow. Confirm with finance which payment gateway or invoicing process applies, how refunds and cancellations reverse an enrolment, and where tax and receipt data is kept. Moodle's payment and enrolment options vary by plugin, so check the specific plugins against your gateway and your current Moodle release. Also confirm which Moodle version your hosting plan targets, since the server requirements for each release differ and the upgrade path should be planned before the first production users arrive.
Which requirements shape a corporate Moodle build
This table maps the main corporate training requirements to the build decisions they create and the source behind each one. Read each row as a question to settle before the build starts: which release and database stack to standardize on, what staff and customer data the platform holds, and what completion evidence managers, customers and auditors will ask for. The main takeaway is that enrolment, reporting and data protection choices are far cheaper to make early than to retrofit after go-live.
| Requirement | What it means for the build | Source |
|---|---|---|
| Release line and server stack | Match PHP and database versions to the chosen release; from Moodle 5.1, point the web root at /public | Moodle 5.1 and 5.3 release notes |
| Mandatory staff training | Enrolments driven by HR role data, with recurring cohorts and deadline reminders set per course | Moodle core enrolment and completion settings, confirmed against the chosen release |
| Audit evidence of completion | Completion records, certificates and grade exports kept with timestamps, under a written retention rule | GDPR Article 32 on security of processing; AICPA 2017 Trust Services Criteria |
| Customer or partner sales | Paid courses need a payment gateway, a separate category or tenant, and customer accounts kept apart from staff | Moodle core authentication plugins, including email self-registration |
| Manager visibility | Manager reports scoped to direct reports through role-based access, so each manager sees only their team | GDPR Article 32 on access control and confidentiality |
| Data protection for staff and customer data | Any hosting provider or partner acts as processor under a contract with documented instructions and security measures | GDPR Article 28(3) and Article 32 |
| Customer assurance questions | Map each control to evidence you can produce; confirm with your auditor which parts of the stack are in scope | AICPA 2017 Trust Services Criteria, security common criteria CC1 to CC9 |
Moodle for corporate training: the settings and integrations that matter
Corporate Moodle sites succeed or fail on a small set of settings: how people get enrolled, how completion is recorded, who can see what, and how results reach managers and finance. Each card below names one component, what it configures, and the decision the company should settle before build starts.
Enrolment methods and identity sync
Enrolment methods decide how employees and customers join courses: manual enrolment, cohort sync, enrolment through an external database or LDAP directory, or enrolment pushed in through web services. For HR-driven training, decide which system is the source of truth for joiners, movers and leavers, and whether course access follows that feed automatically. Confirm which enrolment and authentication plugins your chosen Moodle version supports before fixing the design.
Cohorts for group enrolment
Cohorts are site-level groups of users that can be enrolled into many courses at once, which suits training defined by job family, region or contract type. Decide who owns cohort membership, whether it is maintained by hand, by a rule, or by a sync from HR, and how often it is reviewed. Cohort changes affect every course the cohort is linked to, so a mistake spreads quickly. Test the sync with leavers as well as new starters.
Course completion and certificates
Completion tracking defines when a learner has finished a course, using activity completion, grades or dates. Certificates, usually added through a certificate activity, become the record that a person completed mandatory training. Decide which criteria count as completion for each course, who may reissue a certificate, and how long records are kept. Confirm that the certificate plugin you choose supports your Moodle version and your evidence requirements.
Role assignments for managers and administrators
Moodle roles control what each person can do, and role assignments can be made at site, category or course level. Managers usually need to view their team's progress without editing content, while training administrators need to enrol users and manage completion. Decide which roles are custom, who approves a new assignment, and how the assignments are reviewed each quarter. Overly broad administrator roles are a common source of access findings, so test each role with a real account before rollout.
Categories for business units
Course categories organize the catalogue and can carry role assignments and enrolment settings for a whole division. Decide whether the structure follows business units, regions or product lines, because the choice shapes who can manage which courses and how reports are filtered. Keep the depth shallow and document the naming rules, since categories are costly to restructure once courses and certificates depend on them.
Reporting and scheduled exports
Built-in reports show completion, activity and grades, and custom reports can be built for managers and compliance teams. Scheduled exports send data to finance, HR or a learning record system on a fixed cadence. Decide which fields leave Moodle, who receives them, and how personal data in exports is protected under your privacy obligations. Confirm which reporting and export plugins are maintained for your Moodle version before you promise a dashboard.
Payment gateways for paid customer courses
Paid courses for customers or partners use payment gateway plugins connected to a payment provider, with enrolment triggered after a successful payment. Decide which provider and currencies you need, how refunds and invoices are handled, and whether card data stays entirely with the provider. Confirm the gateway plugin's support for your Moodle version and PHP release, and test failed and delayed payments before launch.
How HR-driven enrolment and single sign-on work in Moodle
Moodle separates two data paths that corporate teams often merge in their heads. The first is identity, which decides who can log in and which account they use. The second is enrolment, which decides who is on which course and with what role. An HR-driven setup works only when both paths are fed from the same employee record, because a person who can still log in after leaving the company, or who keeps a course role from a previous job, has an access problem even when the course design is sound.
Moodle core ships several authentication plugins that cover these identity needs. The external database plugin can read user records from a table your HR or directory export maintains. The LDAP plugin can authenticate against a directory such as Active Directory. The OAuth 2 plugin connects to an external identity provider, the LTI plugin accepts launches from other tools, and the web services layer lets your HR middleware create and update accounts through an API. Core also includes manual accounts, email self-registration and Shibboleth. For SAML 2.0 single sign-on, most sites use the auth_saml2 plugin maintained by Catalyst IT. It creates users on first login and maps identity provider attributes to Moodle profile fields, so the field mapping you configure is part of the access design, not an afterthought.
Leavers and role changes need an explicit path. The HR system should be the source of truth for employment status, and that status must reach Moodle in a way that suspends the account, removes or changes the relevant cohort or enrolment, and updates profile fields used for course assignment. Decide which events trigger suspension, which trigger a change of cohort, and how long a suspended account is kept before deletion. Test each case with a sample of real staff movements in a staging site, and check that a suspended user can no longer sign in through SAML, LDAP or the external database method, since a successful directory login does not by itself block a Moodle account that is still active.
In most projects the field mapping, not the course design, decides whether this works. If the identity provider sends an employee number in one attribute and the HR export uses another, or if the mapping leaves the username field empty for some users, enrolment rules will match the wrong people or none at all. Document every mapped field, its source system, its owner and what happens when it is blank or changed. Ask your plugin provider and your Moodle partner to confirm which auth and enrolment plugins support your exact Moodle version, including PHP and database requirements, before you commit to a design. Support status for third-party plugins changes between releases, so confirm it against the version you will run.
How paid courses for customers and partners are set up
This sequence settles who pays, which accounts they use, how the gateway is chosen and tested, and how fees, invoices and data terms are agreed before any paid course opens. The output is a tested, signed-off paid enrolment path that finance, security and legal have each approved.
Decide which audiences pay
Work with the training owner and finance to list every course group and mark it as paid or internal. Paid groups usually include external customers and partners, while staff courses stay free and are assigned through HR-driven enrolment. Record which courses or categories are paid, who can buy them, and whether any staff member can purchase a course for someone outside the company. Done when the list is signed by the training owner and finance, and every course in the catalog has one label.
Separate customer and partner accounts from staff accounts
Decide how external learners sign in before anything else is configured. Options include a separate authentication method, a separate user pool, or manual accounts that are kept apart from the staff directory, and the choice depends on how your identity provider and HR feeds are set up. Confirm that staff roles, manager reporting and HR sync cannot accidentally reach customer or partner accounts. Done when a test customer account and a test staff account show different sign-in routes and neither can see the other's course records.
Choose a payment gateway plugin for your Moodle version
Shortlist gateway plugins from the Moodle plugins directory and check each one's listed Moodle version support against the release you run or plan to run. Confirm that the plugin is maintained, which currencies and countries it covers, and which gateway accounts it needs. Ask your payment provider whether it supports the chosen plugin and whether its settlement reports match your finance process. Done when one plugin is selected in writing, with its version compatibility and maintainer confirmed.
Test the gateway on a staging copy
Install the chosen plugin on a staging copy of the site that matches production's Moodle version, PHP version and database. Run test purchases with the gateway's sandbox credentials, including successful payments, declined cards, refunds and a cancelled checkout. Check that each successful payment creates the right enrolment, that failed payments do not, and that the gateway's callbacks reach the site through your firewall and proxy. Done when every test case has a recorded result and the staging log shows no unhandled payment errors.
Configure enrolment fees and access periods
For each paid course, set the fee, currency, and the access period, such as an enrolment that lasts a fixed time or until a set date. Decide what happens at expiry: whether learners lose access, keep their completion records, or can renew. Confirm how enrolment is removed when a payment is refunded or disputed, and whether managers can grant free access for approved cases. Done when a test learner's enrolment ends on schedule and a refunded test purchase removes access without deleting the completion history.
Agree invoicing and tax handling with finance
Ask finance to define which documents must be issued for each sale, who issues them, and whether Moodle or the gateway produces the receipt. Confirm how sales tax or VAT is calculated, which tax rates apply to customers in each country, and how refunds and credit notes are recorded. Ask for a written list of what the quote from your implementation partner includes, such as configuration of tax rules and reconciliation reports, and which items finance will maintain itself. Done when finance signs off a sample receipt, a sample refund and a monthly reconciliation method.
Confirm card data stays with the gateway
Ask the gateway to show how card entry is handled, usually through a hosted payment page or an embedded form that sends card data directly to the provider. Review the plugin's code and network traffic in staging to confirm that card numbers, expiry dates and security codes never reach the Moodle server, its logs or its database. Confirm with your security team whether this setup keeps the Moodle server outside the scope of payment card data requirements, and record that answer for your PCI DSS assessor. Done when the security team signs off the staging traffic capture and the gateway's responsibility split in writing.
Check data processing terms with customers
Before the first paid learner signs up, have legal confirm the data processing terms that apply when your organization hosts personal data for customers and partners. Under the GDPR, a processor contract must bind the processor to process data only on documented instructions and to apply the security measures required by Article 32, so check that your terms and any hosting or support provider's terms say the same. Confirm where customer data is stored, who can access it, and how it is returned or deleted at the end of the contract. Done when legal approves the terms and a copy is available to each customer before enrolment.
Which Moodle version and server stack a corporate site should plan for
The Moodle version you choose sets the server stack you must run, so the version decision belongs at the start of the project, not after the build. Moodle 5.1 requires 64-bit PHP 8.2 or later (8.3 and 8.4 are supported), and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 is supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Each set of minimums changes your operating system packages, PHP build, database engine and the hosting images your platform team maintains, so these need to be checked against your current estate before anything is provisioned.
Upgrade paths also constrain the choice. Sites must be on Moodle 4.2.3 or later to upgrade to 5.1, and on Moodle 4.4 or later to upgrade to 5.3. A corporate site still running an older release will need an intermediate upgrade step, which adds test cycles and downtime planning to the schedule. From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. If it does not, the site may show directory listings or errors. Ask your team to review virtual host definitions, reverse proxy rules, load balancer health checks and deployment scripts for every environment, including staging, before the first 5.1 or 5.3 build is promoted.
Support windows should drive the target. Moodle 5.3 is the next long-term support release, released on 5 October 2026, with general support until 4 October 2027 and security support until 1 October 2029. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027, and Moodle 5.2 has security support until 4 October 2027. For a corporate training platform that will hold compliance records for several years, a long-term support release usually gives the longest window between mandatory upgrades. Confirm these dates on the Moodle releases page before you commit, because the release calendar and support terms are the source of truth and can change.
Plan the version against your company's approved platform list and patch cycle, not only against Moodle's documentation. If your approved list fixes the PHP or PostgreSQL version, check whether it already meets the minimum for your target release, and raise the gap with the platform owner early. Check every plugin you depend on as well. For example, the SAML2 single sign-on plugin (auth_saml2) lists support up to Moodle 5.1, so you must confirm its support for 5.3 with the maintainer or on its plugin listing before you select 5.3. Ask any implementation partner to state in the written scope which versions, database engine and PHP build they will test against, and who pays for stack changes if the approved platform list has to move.
How a corporate Moodle rollout runs, in order
The sequence moves from agreeing what training data means and who owns it to a pilot, a full rollout and a handover that leaves your team able to run the platform. Each phase closes with a decision or sign-off, so scope changes stay visible before they reach the live system.
Map requirements and data with HR, finance and IT
Start by agreeing what the platform must know about people, courses and money. HR defines the employee record fields that drive enrolment, such as job role, location, manager and employment status. Finance defines what a paid course or customer invoice needs to reconcile. IT confirms the identity source and the systems that must receive completion data. The phase ends with a signed requirements and data map that names the system of record for each field and the owner who approves changes to it.
Design courses and compliance tracking
Next, the course structure is designed around the compliance obligations and the roles that take each course. Compliance and learning leads define course categories, prerequisites, expiry and recertification rules, and the evidence each course must produce, such as a completion record, a graded assessment or a signed attestation. The design is written as a course catalog with owners and review dates. The phase ends with sign-off from the compliance owner that every mandatory course has a rule for assignment, due dates and renewal.
Integrate identity and enrolment
This phase connects Moodle to the identity provider and the HR source so accounts and enrolments are created and removed without manual steps. The team chooses how users authenticate, for example through SAML 2.0 single sign-on, LDAP or an external database, and how enrolment is driven by HR attributes or groups. Test accounts move through joiner, mover and leaver cases. The phase ends when those cases pass in a non-production environment and the team has agreed who handles exceptions that the automated rules cannot resolve.
Choose hosting and the Moodle version
The hosting model and release are fixed here, based on where staff and customer data may reside and the support window you need. Confirm the target major release against Moodle's published support dates, the required PHP and database versions, and the web server document root, which must point to the public directory from Moodle 5.1 onward. Check any starting-version rule if you are upgrading an existing site. The phase ends with a written architecture and version decision approved by IT and security, including backup and restore responsibilities.
Migrate existing content and records
Existing course content, question banks, completion history and certificates are moved into the new platform. The team inventories what exists, decides what is retired rather than carried over, and maps old completion records to the new course structure so compliance history is not lost. Each migration batch is checked by counting courses, users and completions against the source, and by sampling records for a manager or auditor to review. The phase ends when the migrated data passes reconciliation and the data owner signs off on the record of completions.
Run a pilot with one business unit
A single business unit uses the platform for real mandatory and optional courses before wider release. The pilot tests enrolment from HR data, deadline reminders, assessment, certificate issue and the reports that managers will use. Feedback is logged against the requirements map from the first phase, and defects are fixed and retested. The pilot ends with a go or no-go decision from the sponsor and the compliance owner, based on a list of open issues that have agreed owners and severity.
Roll out company-wide with manager reporting
The platform is opened to the remaining business units in planned waves. Each wave confirms enrolment counts against HR data, checks that managers can see their team's progress, and watches for failed logins or missing enrolments. Manager reports are finalized for due dates, overdue items and completions by course, and access is limited to the people who manage each team. The phase ends when every wave has passed its enrolment and reporting checks and the sponsor accepts the rollout as complete.
Hand over to your team with support
The final phase transfers operation to your administrators and support staff. Runbooks cover account and enrolment exceptions, backups and restores, plugin and theme changes, and the upgrade calendar tied to Moodle's release and security support dates. Your team is trained on the admin tasks it will own, and the support route for issues that need a partner is written down. The phase closes when the runbooks are accepted, the first backup restore has been tested, and the operating owner has signed the handover document.
Compliance evidence for corporate training and customer data
Each card covers one obligation that often reaches a corporate Moodle, from processor contracts to disclosure rules. DeployOpen prepares systems, controls and evidence for these reviews but does not issue audit reports or certifications; independent auditors and certification bodies do. Counsel should confirm which obligations apply to your organization, and AI Act duties must be checked separately if Moodle AI providers are enabled.
GDPR Article 28(3) processor terms
If a partner hosts Moodle, runs backups or supports the platform with access to learner records, the contract must bind that partner to process personal data only on your documented instructions, including on transfers. Check that the agreement lists the data categories (names, employee IDs, assessment results, payment references), the sub-processors such as hosting and payment providers, and how data is returned or deleted at exit. Confirm who acts as controller for customer-facing courses.
GDPR Article 32 security of processing
Article 32 requires security measures suited to the risk, and Article 28(3) extends that duty to the processor. For Moodle, the evidence is concrete: encrypted connections on login and course paths, a documented patch cadence for PHP, the web server and the database, restricted and logged administrator access, and backups proven by test restores. Ask the partner for a written control set that maps each of these items to an owner and a record.
SOC 2 questions from paying customers
Customers buying paid training may ask for SOC 2 evidence. Every SOC 2 examination applies the security common criteria CC1 to CC9 from the AICPA Trust Services Criteria. A Type 1 report describes the system and the design of controls at one date, while a Type 2 report adds an opinion on operating effectiveness over a period. SOC 2 report use is generally restricted to specified parties, so it is rarely something you can publish. Confirm with your auditor whether SOC 2 fits your customers' requests.
ISO/IEC 27001:2022 Annex A controls
Organizations that certify to ISO/IEC 27001:2022 map their information security controls to Annex A, which lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). For a Moodle platform, the technological theme carries most of the design work, covering access, logging, backups, configuration and vulnerability management. Accredited certification bodies certify on a three-year cycle with at least one audit each calendar year. Confirm whether your scope includes the Moodle servers, the database and partner support access.
Data Act switching rights
The EU Data Act has applied since 12 September 2025. It requires data processing service providers to let customers switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges. Whether these rights bind a Moodle hosting or support provider depends on how the Act classifies that provider, so confirm this with counsel before signing, and check the exit data formats in the contract.
SEC Regulation S-K Item 106 disclosure
US listed companies must describe their processes for assessing, identifying and managing material cybersecurity risks under Regulation S-K Item 106. A training platform holding employee and customer data can feed that description, particularly where third-party providers have access. Document which Moodle components are in scope, who owns the risk process, and how material incidents reach the people who decide on disclosure. Counsel should confirm whether the requirement applies to your filings.
Questions buyers ask about Moodle for corporate training
What drives the cost of a corporate Moodle build?
The build is mostly paid labor, and the scope decides how much. Cost has two parts. The one-time build covers course structure design, the enrolment logic for HR-driven and self-service courses, theme and plugin work, reporting for managers, data migration and testing. Integrations add their own one-time cost: each HR feed, identity provider connection, payment gateway and finance export needs design, build and verification. Recurring costs cover hosting in your infrastructure, Moodle upgrades, plugin maintenance, backups and support. Ask any vendor for a written quote that lists each item separately, states which integrations are included, names who owns hosting and says what is recurring and what is one-time.
Can an internal team run corporate Moodle without a partner?
Yes, if the team already runs PHP, Linux and database servers well, but the upgrade work is the test. Moodle 5.1 requires 64-bit PHP 8.2 or later, and it supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Sites must already be on Moodle 4.2.3 or later to upgrade to 5.1. The web server document root must also point to the new /public directory from 5.1 onward, or the site may show directory listings or errors. Internal teams often handle the first install well and then struggle with planned upgrades, plugin compatibility and testing. Before deciding, check your team's capacity for those cycles and confirm current support dates on the Moodle releases page.
How long does a corporate Moodle rollout take?
Duration depends on how many systems you connect and how much existing content you bring over. No single timeline applies to every organization. The biggest drivers are the number of integrations (HR feeds, identity provider, payment gateway, finance or reporting exports), the volume and condition of existing courses and question banks that must be migrated, how many approval rounds your compliance and HR owners need, and whether custom plugins or themes are in scope. Pilot groups, accessibility review and user acceptance testing add time but reduce rework at launch. Any engagement should begin with a written scope and a written plan with dates, and you should ask the provider to show which tasks depend on your own teams' responses.
What must our company provide for a Moodle training project?
Most delays come from inputs the client owns, so agree them before work starts. Typical inputs include an HR data extract or feed with the fields used for enrolment, such as role, location, manager and employment status; administrative access to your identity provider so that single sign-on can be configured and tested; and a named owner for each approval. For paid courses, you must decide which payment gateway to use, how invoices, tax and refunds are handled, and whether your finance team needs an export. Ask the provider to list each input, the person responsible for it and the date it is needed.
How do paid customer courses differ from internal training in Moodle?
Internal training is driven by HR records, while paid courses add commerce, customer accounts and money handling. Internal courses usually enrol people automatically from HR data and track mandatory completion for managers and auditors. Paid courses for customers or partners need a catalog, checkout, a payment gateway connection, receipts or invoices, refunds, and account creation for buyers who are outside your directory. Card data handling changes the security scope, so confirm whether card details pass through your servers or only through the gateway's hosted pages. Plan these separately, because a payment failure should never block access to a course you have already sold.
What does ongoing Moodle support cover after launch?
Ongoing support covers keeping the platform secure, current and working after go-live. Typical work includes applying minor point releases, planning major upgrades before a version leaves support, checking plugin compatibility, patching the operating system and database, monitoring, backup testing, and small content or configuration changes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements begin as fixed-scope projects with written deliverables. Ask for a written list of what the retainer includes, how changes are requested and priced, and which Moodle release each support period assumes. Confirm current support dates for each release on the Moodle releases page.
Which Moodle version should a new corporate deployment target?
Target a release that still has security support for the whole planned life of the platform, and confirm the dates before you commit. The supplied release facts show that Moodle 4.5 is a long-term support release with security support until 4 October 2027. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.2 has security support until 4 October 2027. Moodle 5.3 is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Moodle 5.3 also removes the Classic theme from core, so check any theme work against that change. Confirm current dates on the Moodle releases page before choosing a version.
How DeployOpen scopes and supports a Moodle corporate training platform
DeployOpen implements Moodle for corporate and customer training inside infrastructure the client controls, covering HR-driven enrolment, compliance course tracking, paid courses and manager reporting. Work starts with a written scope that names the audiences, courses, integrations and reports, then moves through build, testing, documentation and handover. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Agree the audiences, such as employees, contractors and paying customers, and which enrolment rules apply to each
- List the compliance courses, renewal cycles and evidence managers need to see in reports
- Confirm the HR source, identity provider and payment gateway the platform will connect to before build starts
How we build
- Design the course and category structure, enrolment methods and role assignments for each audience
- Configure payment and enrolment plugins for paid courses, and test refunds and access revocation
- Select the Moodle release and database versions to confirm against the release notes before installation
How we hand over
- Document the configuration, enrolment rules, plugin list and manager report definitions in a handover pack
- Run acceptance tests with the client's HR and training owners against the written scope
- Train administrators on routine enrolment, course updates, backups and the upgrade process
How we support
- Offer ongoing support, upgrades and security patching as a retainer after handover
- Plan Moodle point releases and major upgrades around the client's change calendar
- Review plugin compatibility and report accuracy each time an integration or release changes
