What does Moodle cost to run when the core is free?
The Moodle core carries no licence fee. Its code is licensed under GPL-3.0 and maintained by Moodle HQ, so you can download it and run it without paying for the platform itself. Total cost of ownership is driven by four things: where the site is hosted, how often it is upgraded, which plugins it depends on, and who runs it. Each of these creates recurring cost, and none of them appears on a licence invoice. Before you compare options, list these four cost lines for your own environment so that every option is priced against the same set of work.
Hosting is the first line. Moodle can be self-hosted in your own cloud account or data center, or run as managed hosting through MoodleCloud or Moodle Partners. Self-hosting costs include compute for web nodes, the database server, file storage for moodledata, backups, monitoring, cron capacity and outbound email. Managed hosting replaces some of these with a service fee, but the scope varies. Ask each provider which backup retention, restore testing, PHP and database patching, and security response are included, and which are extra. Upgrade effort is the second line. Moodle ships major releases in April and October and minor releases every two months, so budget for regular test upgrades in a staging environment, not only for the occasional major move.
Plugins are the third line. The core includes authentication plugins such as LDAP, LTI, OAuth 2 and Shibboleth, and Moodle documents more than 50 plugin types, so most sites rely on at least some third-party code. Free plugins still need someone to check compatibility with each new release, test them and remove them when they are abandoned. Paid plugins add an annual or per-site fee on top. Before you buy one, confirm the licence terms, whether the price recurs, whether the vendor supports the Moodle version you run, and what happens to your site if you stop paying. For SAML 2.0 single sign-on, the SAML2 plugin (auth_saml2) is commonly used, and its version support should be checked against your target release.
The fourth line is people. Most organizations keep day-to-day administration in-house, covering user and course management, roles, enrolments, backup checks and routine support requests. They usually bring in a partner for implementation, upgrades, integrations and specialist work. Whether that split works depends on in-house skills in PHP, the database platform you choose and Linux server administration. If those skills are thin, the upgrade and hosting lines will grow quickly. When you request a quote, ask for one-time costs and recurring costs as separate lines, the assumptions behind each, and which tasks the partner will hand back to your team after go-live.
What a Moodle cost of ownership study includes
A cost of ownership study turns Moodle's free core into a costed model for your environment. Each card below is a deliverable you keep, and together they connect hosting, versions, plugins, people and money in one document.
Hosting options compared
The study sets self-hosting in your own cloud account or data center against MoodleCloud and Moodle Partner managed hosting, using the same workload for each. It records what the host provides, what your team still operates, and where data and backups live. Check who holds administrator access, where student data is stored, and what the managed option charges for growth in users or storage.
Sizing and environment inventory
This deliverable lists every environment you run or plan to run, including production, staging, test and disaster recovery. It records PHP and database versions, web server, storage, cron workers and expected concurrent users at peak, such as exam periods. Use it to confirm that the database and PHP versions your target Moodle release requires are available on your platforms.
Plugin and theme inventory
The inventory lists each installed plugin and theme with its type, owner, source and support status for the Moodle version you plan to run. Moodle documents more than 50 plugin types, so the list often includes blocks, enrolment methods, authentication plugins and reports that each need upgrade testing. Flag any plugin that has no maintainer or no release for your target version, because those items drive custom work cost.
Upgrade cadence plan
The plan maps your upgrade calendar to Moodle's release pattern: majors every six months and point releases every two months, plus LTS releases with security support windows. Moodle 4.5 has security support until 4 October 2027, and Moodle 5.3 has general support until 4 October 2027 and security support until 1 October 2029. Choose which track you follow and budget a test cycle before each move.
Staffing model
The staffing model estimates which roles keep Moodle running and who fills them: Moodle administrators, a developer for plugins and themes, a database or infrastructure operator, a support desk and course designers. For each role it records whether the work is internal, managed by a host, or bought from a partner on retainer. Ask what share of administrator time the model assumes for upgrades, incidents and user management.
Written cost model
The cost model separates one-time costs, such as scoping, migration, integration and initial hardening, from recurring costs, such as hosting, licenses for any paid plugins, backups, monitoring, upgrades and support. Each line states who is paid, what drives the amount up or down, and how it changes at each major release. Use it to compare options side by side, and ask any partner to price the same lines in the same structure.
Self-hosting, MoodleCloud or a Moodle Partner: what changes the bill
The core Moodle code is free under GPL-3.0, but the bill depends on who runs the platform. Moodle's own materials describe three routes: download the code and self-host, use MoodleCloud, or use managed hosting from a Moodle Partner. Each route moves infrastructure, patching, backups, upgrades and day-to-day administration to a different party, and each changes what you control, including where data is stored and which custom plugins you can install. Decide the route first, because it sets most of the recurring cost lines that follow.
When you self-host, your organization pays for servers or cloud resources, the web server, PHP, the database, file storage, backup storage and the staff who patch and upgrade the stack. Your team also schedules the security and point releases, tests each major upgrade and keeps the cron and caching services running. You keep full control of data location, of the database and file server configuration, and of custom plugins and themes, which you can install and test on your own timetable. The cost is mostly internal labor and infrastructure that recurs every month, plus one-time build and migration work.
MoodleCloud and Moodle Partner hosting shift some of those duties to a vendor. The supplied facts do not give MoodleCloud or partner price points, and they do not list what each provider includes. Before comparing, request current pricing in writing and ask each provider to state, line by line, who operates the servers, who applies security releases and major upgrades, what backup frequency and restore testing are included, where data is hosted, how many environments you get, and whether you can install custom or third-party plugins and themes. Ask what happens to your data and configuration if you leave. Also ask which Moodle version the service runs and how quickly it moves to new releases.
Whichever route you choose, check the costs that sit outside the hosting bill. Plugin licenses and the effort to vet, test and maintain contributed plugins recur with every release. Administrator time for role changes, course requests and support tickets is a permanent cost. Moodle's upgrade rules add work: for example, Moodle 5.1 requires PHP 8.2 or later and sites must already be on Moodle 4.2.3 or later to upgrade, and from 5.1 the web server document root must point to the /public directory. A managed service may absorb those tasks, but only if the contract says so. Ask for a written list of what is excluded, and for the unit price of any extra work such as custom plugin support.
Which factors push Moodle running costs up or down
This table lists the factors that most change what a self-hosted Moodle costs to run and maintain, with why each one matters and one way to keep it under control. Read each row as a question to answer about your own environment before requesting a quote. The main takeaway is that most recurring cost comes from the number of plugins, customizations and integrations you carry, not from the core platform itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| User count and peak concurrency | Exam and enrolment peaks drive web, database and cron capacity far above average daily use, so sizing follows the busiest hour. | Ask for the peak concurrent users you must support and schedule heavy quizzes or imports outside those windows. |
| Number of environments | Each environment (production, staging, test) needs hosting, backups, patching and a refreshed data copy, so cost grows with every copy. | Keep one shared staging environment for upgrade and plugin testing, and refresh it from production only on a set schedule. |
| Installed plugins and their maintenance status | Every plugin must be checked against each Moodle release, and abandoned plugins can block upgrades or open security gaps. | Install only plugins you use, prefer maintained ones with recent release support, and remove unused plugins before each upgrade. |
| Theme and customization depth | Heavy theme overrides and custom code need retesting after every release and often need rework when core templates change. | Use a child theme with limited template overrides and move branding into settings or SCSS where possible. |
| SSO and HR or student information system integrations | Each integration adds identity mapping, sync jobs, error handling and monitoring, and each one has its own owner and failure modes. | Standardize on one identity provider and one sync method, and document field mappings so changes stay in one place. |
| Data volume in moodledata and the database | Growing file storage and database tables increase backup duration, restore time, storage cost and the effort of migrations and upgrades. | Set retention rules for old courses and logs, archive completed cohorts, and confirm backup and restore timing with a test restore. |
| Compliance and accessibility evidence requirements | Assessors and accessibility reviews need recorded configurations, test results and change history, which take ongoing administrator time. | Agree the evidence list early, automate configuration exports where your tooling allows, and keep change records in one place. |
How a Moodle cost review moves from inventory to a costed plan
The review runs in a fixed order so that each phase feeds the next, and it ends with a written cost model the organization can test against its own assumptions. Each step below closes with an output the decision makers can review.
Inventory the current Moodle estate
The partner records what exists today: where the site is hosted, which Moodle and PHP versions run, which database engine is in use, the installed plugins and their versions, active user and course counts, and every integration such as SSO, HR feeds, grade exports and external content tools. Your administrators and the platform owner confirm the figures, and the inventory is complete when each item has a named owner and a source. If the organization is evaluating Moodle without an existing site, the same inventory applies to the requirements, such as expected users, course volume and integrations.
Compare hosting options on shared assumptions
Self-hosting in your own infrastructure, MoodleCloud and a Moodle Partner hosting arrangement are costed against the same inventory, the same user and peak-load assumptions, the same integration list and the same support hours. The output is a side-by-side comparison showing which costs are paid to whom, such as cloud compute, storage, database, backups, licenses for any paid plugins, and labor. Ask each option to state in writing which plugins and integrations it supports, because a hosting option that cannot run a required plugin changes the cost model.
Build the supported-version and upgrade calendar
The partner maps the current version against Moodle's published release schedule and support windows. Moodle ships major releases in April and October and point releases every two months, and the support dates for each release are published on the releases page. For example, Moodle 4.5 is an LTS release with security support until 4 October 2027, while Moodle 5.1 has security support until 19 April 2027. The calendar lists each upgrade the organization will need, the PHP and database versions each one requires, and the upgrade path the site must follow. Confirm the dates against the official releases page before you commit to a plan, since they can change.
Model staffing and skills needs
The partner estimates the administrator, developer, web server and database skills that the chosen option requires, and identifies which of them exist in-house. It separates regular administration (user and course support, plugin updates, backups, monitoring) from periodic work (major upgrades, plugin compatibility checks, security patching, cron and performance tuning). The output is a role map showing who covers each task, whether the work is internal, contracted or included in a hosting fee, and where cover is thin. Ask whether a hosting partner's support includes upgrades or only infrastructure.
Write the cost model with assumptions
The partner assembles a written model that lists every cost component: one-time costs such as migration, configuration, theme work and initial integration, and recurring costs such as hosting, storage, backups, licenses, support retainers and staff time. Each line states its assumption and its source, such as a vendor quote or the organization's internal rate. Vendor prices and rates come from the vendors and the organization, not from estimates in this review. Ask every bidder to price against the same scope so the totals can be compared.
Test the model with sensitivities
The partner reruns the cost model with the assumptions that move most, such as user growth, peak exam load, number of plugins, number of upgrades in the review period, and the staffing options. Each sensitivity shows which line changes and by how much, so the decision makers can see which assumptions carry the decision. The review is complete when the sponsor has signed off the assumptions, the model covers every option on the same basis, and the sensitivity results have been discussed with the people who own the risks.
Which recurring Moodle costs teams underestimate after go-live
This table lists the cost components that continue after a Moodle site goes live, showing whether each is one-time or recurring and who usually pays for it. Read it as a checklist to confirm with your own team or partner before comparing quotes. The main takeaway is that upgrades recur because Moodle releases follow a fixed cycle and each version has a supported window.
| Cost component | One-time or recurring | Who usually pays and why it recurs |
|---|---|---|
| Hosting and compute | Recurring | The organization, through its cloud account or data center. Web and cron nodes run continuously and scale with concurrent users and exam peaks. |
| Database and storage | Recurring | The organization. Database licenses or managed service fees, plus moodledata growth from uploaded course files, recur as enrolments and content grow. |
| Backups and disaster recovery | Recurring | The organization. Backup storage, retention and periodic restore tests continue after launch, and recovery testing must be repeated after infrastructure changes. |
| Security patch application | Recurring | The internal platform team or the partner under a retainer. Security releases are applied outside the regular upgrade calendar, and each one needs a test cycle. |
| Six-monthly major and two-monthly point upgrades | Recurring | The internal platform team or partner. Moodle ships majors every six months and point releases every two months, and each version has a supported window, so upgrades repeat for the life of the site. Confirm the current support windows for your version. |
| Plugin maintenance and compatibility testing | Recurring | The organization or partner. Each core upgrade can break contributed or custom plugins, so compatibility checks and fixes repeat with every release. |
| Third-party or paid plugin subscriptions | Recurring where the vendor charges | The organization. Some commercial plugins charge annual or per-site fees and may require matching upgrades. Ask the vendor which Moodle versions each subscription covers. |
| External support contracts | Recurring | The organization, through a retainer or support agreement. Scope, response expectations and what is covered should be confirmed in writing before signing. |
| Administrator and teacher support time | Recurring | Internal staff time. Administrators handle user issues, course requests and configuration changes, and teachers need continuing help as features change between releases. |
How the cost picture changes by starting point
Moving from a commercial LMS changes the license line most visibly, because the Moodle core is licensed under GPL-3.0 and carries no per-seat license fee. Spend moves toward hosting, data migration, integration and staff time, and much of the new cost is one-time work.
Cost lines that move:
- Subscription fees: The recurring platform license ends, but confirm what your current vendor charges for data exports, API access and exit support.
- Data migration: Courses, users, grades and completion history need mapping, test restores and reconciliation. This is one-time effort that scales with record volume and content complexity.
- Hosting and operations: You pay for infrastructure and administrator time directly, or pay a hosting provider. MoodleCloud and Moodle Partners are managed hosting options to compare.
- Parallel running: Most cutovers keep both systems live for a period, which adds cost for two environments and duplicate support.
- Integrations: SSO, HR and student information system connectors built for the commercial product usually need rebuilding in Moodle.
Before accepting a quote, ask the partner which of these lines are fixed in the written scope and which depend on data volume or integration findings made during discovery.
A site on an older release may not be able to upgrade directly to the current version. Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires sites to be on Moodle 4.4 or later. A site below those minimums needs intermediate upgrades first, and each step carries its own testing and plugin work.
Cost lines that move:
- Stepping upgrades: Each intermediate release adds test cycles, rollback planning and administrator time, so the number of steps drives the one-time cost.
- PHP and database versions: Moodle 5.1 requires 64-bit PHP 8.2 or later, and Moodle 5.3 requires 64-bit PHP 8.3 or later. Database minimums also rise, which can mean rebuilding database servers.
- Web server configuration: From Moodle 5.1 the web server document root must point to the /public directory. This touches hosting, reverse proxy and deployment scripts.
- Plugin replacement: Older plugins may have no release for the target version, so budget for replacement, rework or retirement.
- Theme decisions: The Classic theme was removed from core in Moodle 5.3, so sites that depend on it need a theme plan.
Ask the partner to map the upgrade path from your exact current version, and to show which steps appear in the quote as separate lines.
Moodle documents more than 50 plugin types, including activity modules, blocks, themes, enrolment, local and report plugins. Every custom or unmaintained plugin adds compatibility work with each major and minor release, so the cost of a heavily customized site is mostly recurring.
Cost lines that move:
- Plugin audit: A one-time review of every installed plugin covering source, license, last release and code quality. Plugins with no clear owner are the most common source of unplanned work.
- Upgrade rework: Custom code must be tested against each target release. This is a recurring line that grows with the number of plugins.
- Ownership after handover: Decide who maintains each plugin once the project closes. An unowned plugin often becomes the largest hidden cost.
- Configuration versus code: Replacing custom code with configuration or a maintained contributed plugin lowers recurring cost but adds one-time analysis and change work.
- Documentation: Administrators need records of what each plugin does, how it was configured and how to test it after an upgrade.
Ask the partner for a plugin-by-plugin estimate of upgrade effort, and for a named owner for each plugin in the handover plan.
Running Moodle on Kubernetes or other containers shifts cost toward platform engineering, image pipelines and storage. The Moodle application work stays the same, but the cluster becomes part of what must be patched, monitored and supported. Confirm the exact container and storage design with the partner, because it depends on your platform standards.
Cost lines that move:
- Platform skills: If your team already operates clusters, the added cost is small. If not, cluster operations become a recurring line, either in-house or through a managed service.
- Shared file storage: The moodledata directory must be available to every web and worker pod. The storage class and its performance need to be confirmed for your cluster.
- Image maintenance: Images must be rebuilt for each Moodle minor release, PHP change and security update, which adds a recurring pipeline cost.
- Cron and task workers: Scheduled tasks are usually separate workloads, which adds design, scaling and monitoring work.
- Tooling licenses: Cluster, registry and monitoring products may carry their own license terms. Confirm these before the budget is set.
Ask the partner whether image maintenance and cluster operations are in the quoted scope, or whether they will be handed to your team at go-live.
In an air-gapped or sovereign environment, managed hosting may not be an option. The cost of ownership moves from a provider contract to in-house infrastructure, offline update handling and evidence work. Some services that a typical deployment uses, such as external AI providers or cloud identity services, may be unavailable, which changes integration scope.
Cost lines that move:
- Infrastructure and backups: You own hardware or private cloud capacity, backup storage and disaster recovery, with no provider absorbing those costs.
- Offline updates: Each release, plugin update and security patch must be obtained, verified and transferred through your approved process. This recurs with every release cycle.
- Plugin supply chain: Each plugin needs vetting before import, so review time grows with the number of plugins.
- Blocked services: Outbound connections to external services may be restricted, which removes some integrations or requires internal alternatives.
- Evidence and access control: Logs, retention settings and administrator access reviews are recurring tasks that your assessors may request.
Ask the partner which components need outbound connectivity, and how the offline update cycle is priced across a full year of releases.
Where Moodle cost models go wrong
Most Moodle budgets fail in predictable places: the free core gets mistaken for the whole bill, version requirements change between releases, and recurring work is left out. The cards below name each failure and the check that prevents it before a budget is approved.
Treating the core as the whole bill
Moodle's code is GPL-3.0 licensed, so the core carries no license fee, but hosting, storage, backups, monitoring, plugin work, upgrades and administrator time all still cost money. Build the model line by line, listing who pays for each item and whether it is one-time or recurring. Ask any hosting or partner quote to state what it covers before comparing totals.
Ignoring PHP and database requirement changes
Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15, while Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17. A server, database or managed service sized for the older stack may need replacing during the upgrade. Check the release notes for the target version and include any runtime or database upgrade, testing and licensing effects in the estimate.
Missing the public document root change
From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. Sites that keep the old root can show directory listings or errors. Budget time for web server configuration changes on every node, reverse proxy rules and smoke tests, and confirm that the hosting provider supports the new path before committing.
Underestimating plugin maintenance
Moodle documents more than 50 plugin types, and most sites rely on several contributed plugins that each need compatibility checks for every major release. Plugins that lapse can block an upgrade or require custom code later. Estimate recurring time for reviewing each plugin, testing it on staging and replacing or removing those that are no longer maintained.
Leaving out staging environments
A budget that prices only production leaves no place to test upgrades, plugin changes or theme updates before users see them. A staging copy needs its own servers, database, file storage and refreshed data, and it must be kept close enough to production to be useful. Include the staging environment as a recurring line item, not a one-off build cost.
Sizing for average load, not exam peaks
Assessment periods can push concurrent users, cron tasks and file activity far above normal daily use. A plan sized for average traffic may slow or fail exactly when grading matters most. Ask for the expected peak concurrency and assessment calendar, and compare hosting options on peak capacity, scaling time and load test results rather than monthly averages.
Comparing managed prices with different scope
Managed hosting quotes often differ in whether they include backups, restore testing, security patching, version upgrades and support. Comparing a low headline price with a self-hosted total that includes those items skews the decision. Build a comparison sheet with the same scope for each option and ask each provider to confirm in writing what is included and excluded.
What your team needs to provide before a cost review
A cost review of a Moodle platform is only as accurate as the facts behind it. Before a partner can model what running Moodle will cost, your team needs to confirm the current installed state, the usage profile and the cost you already pay. A partner can only model cost from facts the client can confirm, so an estimate built on guesses will shift the moment the first invoice or server log contradicts it. Start by collecting the inputs below, and note who provided each one and when. The first group is the technical baseline. Record the current Moodle version, the PHP version and the database engine and version, including whether the database is PostgreSQL, MySQL, MariaDB or Microsoft SQL Server. Pair this with the web server and operating system. The upgrade path and the cost of getting there depend on these values. For example, a site on an older 4.x release may need an intermediate upgrade before it can reach the 5.1 or 5.3 release line, and each target release sets its own minimum PHP and database versions. Confirm these against the release notes for your target version, not against memory. The second group is the plugin and customization inventory. List every installed plugin with its version and where it came from: the Moodle plugins directory, a commercial vendor, an in-house developer or a manual copy. Mark which plugins are paid, which have a known maintainer, and which are custom code that someone on your team must maintain. Include the active theme, any local or report plugins and any enrolment or authentication plugins. Paid licences, renewal dates and the per-year fees should go on the same list, because they are a recurring cost that the core licence does not cover. The third group is usage and integrations. Provide user counts, active course counts and concurrent peak figures for exam weeks, enrolment intake and end-of-term periods. Describe the integration inventory: the identity provider and protocol in use, the HR or student information system that supplies users and enrolments, and every LTI tool that launches from Moodle. Each integration adds a support and testing line, so an unlisted tool is a common source of unexpected cost. Finally, gather the hosting and labour figures and name the owners. Collect hosting invoices or an infrastructure inventory that shows compute, storage, backup, database and licence charges. Ask your administrators and support staff for honest estimates of the hours they spend on upgrades, plugin fixes, tickets and content support each month. Then name one accountable owner each for finance, security and academic decisions, so that assumptions can be approved or corrected without delay.
Questions buyers ask about Moodle cost of ownership
Does the Moodle core cost anything to use?
No licence fee applies to the Moodle core. Moodle's code is licensed under GPL-3.0, so you can download and run it without paying for the software itself. The cost of ownership comes from running it: the infrastructure it sits on, the people who operate and upgrade it, the plugins and themes you add, backups, monitoring, and support. Some plugins and integrations are commercial, so check the licence of each one before it enters your scope. Ask any partner to list every component in the quote and to state which items are one-time and which recur each year.
Should we self-host Moodle or use MoodleCloud?
The choice depends on who must control the data, the configuration and the upgrade timing. Moodle can be self-hosted in your own infrastructure or run as managed hosting through MoodleCloud or Moodle Partners. Self-hosting gives you control over the server location, the plugin list, the database and the upgrade schedule, but you carry the operations work or pay a partner to do it. Managed hosting shifts much of the operations work to the provider but limits what you can install and how you configure the platform. Compare both options against the same list of requirements, including data residency, integrations, custom plugins and your internal skills, before you request a quote.
How long does a Moodle cost review take?
The duration depends on the scope you agree in writing, so confirm it there. A cost review usually covers the current or planned hosting model, sizing for expected users and peak exam load, the plugins and integrations in play, and the upgrade cycle you will follow. The number of systems, the availability of your staff for workshops, and the amount of existing documentation are the main factors that change the time needed. DeployOpen works on fixed-scope engagements, so the scope document should state the timeline, the deliverables and the client inputs required before work starts.
What does a Moodle implementation need from our team?
Your team provides decisions, access and knowledge of how the institution actually runs its courses. Expect to name an owner for the platform, supply cloud or data center access, confirm identity provider details, and make decisions on roles, course categories and which plugins are allowed. Your staff should also review test results, sign off each stage and provide representative data for migration and load testing. Ask the partner to list these inputs with an estimated effort for each named role, so you can see the internal commitment before you agree to the scope.
Can our own staff run Moodle without a partner?
Yes, if you have the skills and the time to keep the platform current, and many teams do this in-house. Running Moodle well requires working knowledge of Linux, the web server, PHP, the database, cron, backups and the Moodle administration area. You also need a process to test each release and each plugin before production. Check your team against the supported PHP and database versions for the Moodle release you plan to run, and confirm that at least two people can cover upgrades and incidents. If those gaps exist, a partner can cover them under a retainer or a fixed-scope project.
What usually drives the Moodle running cost up the most?
Peak load, the number of custom or paid plugins, and the frequency of upgrades drive most of the recurring cost. Infrastructure grows with concurrent users during exams, file storage grows with course content and backups, and high availability adds nodes, a replicated database and shared storage. Each custom plugin or theme adds testing and maintenance effort at every major release. Integrations with HR systems, student information systems and identity providers also add ongoing work when source systems change. Ask the partner to show which of these factors the quote assumes and what changes the price if they grow.
How do the six-monthly releases and LTS versions affect our budget?
Major releases arrive twice a year, so plan for regular upgrade work and a longer cycle when you choose an LTS version. Moodle ships major releases every six months, in April and October, and minor point releases every two months. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next LTS, released 5 October 2026, with security support until 1 October 2029. Each major version also has its own PHP and database requirements, so budget for testing and possible infrastructure changes at each step. Ask any partner to state which release and support window the quote covers and what the upgrade work includes.
What should we ask for in a partner quote for Moodle?
Ask for a written, fixed-scope quote that lists every component, every assumption and every recurring cost. The quote should name the hosting model, the Moodle release and its support window, the plugins and themes in scope, the integrations and their data flows, and the testing and backup approach. It should separate one-time implementation work from annual support, upgrades and infrastructure. Request the acceptance criteria, the client inputs needed, the exclusions and the process for handling changes to scope. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes, delivers and hands over Moodle cost work
DeployOpen approaches Moodle cost of ownership as a written, fixed-scope piece of work inside your own infrastructure. We model the recurring costs of self-hosting, managed hosting and partner hosting against the same requirements, then hand over a model your team can maintain.
How we scope
- Confirm which Moodle release line you run or plan to run, and the PHP and database versions that line requires.
- Inventory current hosting, plugins, theme work, integrations and administrator hours so each cost has a named owner.
- Agree in writing which hosting options, cost categories and time horizon the comparison will cover before work starts.
How we build
- Build a cost model that separates one-time setup from recurring hosting, licensing of paid plugins, upgrades and support.
- Test the hosting assumptions against a sized staging environment, including the web server document root change required from Moodle 5.1.
- Check each paid plugin and integration for upgrade compatibility with the Moodle versions in your roadmap.
How we hand over
- Deliver the cost model as a spreadsheet and written assumptions, with each input traceable to a source your team can verify.
- Document the infrastructure, plugin inventory and upgrade calendar so administrators can update the model themselves.
- Walk your finance, IT and academic stakeholders through the results and record the decisions taken.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to keep the model current.
- Review the model when Moodle releases change support windows, PHP requirements or hosting options.
- Agree retainer scope, response expectations and review cadence in writing before any ongoing work begins.
