Docebo cost vs self-hosted Moodle: where the money moves
If your Docebo renewal or a pricing change has forced a cost review, the first thing to settle is that Moodle carries no license fee. Moodle is free and open-source software under the GNU General Public License version 3, according to the Moodle GitHub repository, so the comparison does not turn on a line item for software. It turns on what you pay to run the platform yourself: infrastructure, staff time, support and the security and compliance evidence Docebo currently provides for you. Neither Docebo's subscription prices nor any Moodle hosting or partner prices are published on this page, so you will need written quotes from each side before you can compare totals.
Build your model by component rather than by a single headline number. On the Moodle side, expect recurring costs for hosting and database capacity, storage for uploaded course packages (Docebo accepts SCORM, AICC and xAPI ZIP packages of up to 2 GB each, according to Docebo's system requirements page, so confirm the same package sizes and total volume you hold today), backups, plugin maintenance and the people who patch and upgrade. Moodle ships major releases twice a year and point releases every two months, and each upgrade has its own PHP and database requirements, so budget for test environments and upgrade effort as a recurring cost. Ask any Moodle partner or internal team to price these in writing, and ask which items are one-time and which recur each year.
The costs most likely to be underestimated are the ones Docebo's subscription currently absorbs. Ask Docebo for its current security documentation and compare it with what your own auditors will need to see once Moodle is in your infrastructure, because you will be producing that evidence yourself or paying someone to do it. Also price the one-time migration effort, including reloading packages, rebuilding HR and SSO integrations and moving completion records, and check whether your Docebo contract includes data export at no extra charge. Compare the resulting multi-year totals, not year-one invoices, and ask each vendor to state in writing exactly what is included.
Which cost components change when you leave Docebo
This table compares each cost component of a Docebo subscription with what you pay and staff for when Moodle runs in your own infrastructure. Read the commercial column for what the vendor bundles today, the self-hosted column for who pays and for what, and the timing column to separate one-time migration work from costs that recur every year. The main takeaway is that licence fees fall away but hosting, upgrades, security evidence and skilled staff move onto your budget.
| Cost component | Docebo (vendor-provided service) | Self-hosted Moodle (who pays and for what) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Annual or multi-year SaaS subscription, typically priced by user or contract scope; confirm terms in your Docebo order form | No licence fee for Moodle core under GPL-3.0; you pay for any commercial plugins, managed hosting or a Moodle Partner if you choose one | Recurring for Docebo; none for core Moodle |
| Hosting | Included in the subscription; Docebo operates the environment | Your cloud account, data centre or private network: compute, database, backups and monitoring, sized for your learner count and peak course launches | Recurring |
| Storage for course packages | Packages uploaded as ZIP files up to 2 GB each under Docebo's stated limits; storage allowances depend on your contract | Object or file storage you provision for SCORM, AICC and xAPI packages, media and backups; growth is driven by package size and retention rules | Recurring |
| Plugins and themes | Platform features and integrations are managed by Docebo; custom branding and extensions go through the vendor | Plugin selection, testing and upgrades for each Moodle release, including branding themes; some plugins are community-maintained and need a review cycle | Recurring, with a one-time build for custom work |
| Integrations and SSO | Vendor-built connectors for HR, SSO and reporting, subject to the features in your plan | Configuration of Moodle's built-in authentication options such as LDAP, OAuth 2, SAML through a plugin and LTI, plus custom work for HR feeds and reporting | One-time build, recurring maintenance |
| Security attestations | Docebo's own certifications and reports are available to you as the vendor's evidence; confirm current scope and dates with Docebo | You own the control evidence for your environment: hardening, access reviews, logging, vulnerability management and the documentation an assessor asks for. Certifications are issued by independent auditors, not by the platform | Recurring, with a one-time readiness effort |
| Support | Vendor support tiers in your contract | Internal staff or an implementation partner for incidents, patch cycles and user support; confirm response expectations in writing before you rely on them | Recurring |
| Upgrades and internal skills | Vendor applies platform updates on its schedule | Moodle ships major releases in April and October and point releases every two months; each upgrade needs PHP and database version checks, testing and a change window. Budget for staff who know PHP, PostgreSQL or MySQL and Linux operations | Recurring |
| One-time migration effort | Not applicable to the subscription; you pay for exit work only once | Reloading original packages into Moodle, rebuilding enrollment rules and integrations, and exporting users, enrollments and completions through Docebo's API. Ask for a fixed-scope quote that lists each item | One-time |
What pushes the Moodle total cost up or down
Self-hosted Moodle costs move with a handful of operating variables rather than a per-seat subscription. The cards below cover the drivers that change hosting, staffing and support effort, so you can ask a partner or your own team for a quote built on your actual numbers.
Active users and concurrency
Docebo bills and scales for you, while Moodle capacity is your responsibility. Peak concurrent sessions, not registered accounts, usually set the web and database tier you pay for each month. Count active learners at your busiest training window, such as a compliance deadline or a product launch, and ask for load testing before you size the servers. Compute and database hosting are recurring costs that rise with that peak.
Size of course packages
Docebo accepts SCORM, AICC and xAPI ZIP uploads of up to 2 GB each, according to its system requirements page. In Moodle, the same packages sit in your object or file storage, and every backup and restore copies them. Inventory the total size of the packages you keep, including older versions, and decide how much media belongs in a CDN or object store instead of the application volume.
Availability and recovery targets
A SaaS vendor carries uptime and disaster recovery for Docebo under its own agreement. With Moodle, a stricter recovery point or recovery time target means a standby database, replicated storage, tested restores and monitoring, all of which recur. Write down how long learners can be locked out and how much completion data you can afford to lose, then price redundancy against those answers.
Integrations and SSO connections
Each HRIS feed, HR or LMS-to-CRM sync, SSO connection and third-party content library adds build and maintenance work. Moodle core ships authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and others, and SAML2 support comes through a plugin. Count every inbound and outbound connection you have today, then assign ownership for upgrades, since plugins must be checked against each new Moodle release.
Existing PHP, database and Linux skills
The largest hidden cost is often staff time. A team already comfortable with PHP, PostgreSQL or MySQL, and Linux administration can run Moodle with internal effort, while a team without those skills will pay a partner or hire for them. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, so confirm your staff can handle those upgrades on a twice-yearly major release cycle.
How Moodle upgrade cadence turns into a recurring staff cost
Moodle does not hand you a single installation project. It ships major releases in April and October and minor point releases every two months, so the work of keeping a self-hosted site current recurs for the life of the platform. Under a Docebo subscription, the vendor carries the upgrade cycle and you carry the testing and change approval. Under self-hosted Moodle, your team carries the cycle itself: reading release notes, rebuilding a staging copy, checking every installed plugin against the new core, and scheduling the production change. Budget that as a standing role, not a one-off project, and ask any implementation partner to price it as a recurring component.
The version facts set the planning constraints. Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and sites must already run Moodle 4.2.3 or later to upgrade. From 5.1, the web server document root must point to the /public directory instead of the main Moodle folder, so every virtual host and reverse proxy rule needs a change at that step. Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17, MariaDB 11.4 or SQL Server 2019 or later, and sites must be on Moodle 4.4 or later. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next LTS with security support until 1 October 2029. Each jump can also force a PHP or database upgrade, which means infrastructure work sits inside the same change window as the application upgrade.
Your plan should start with a documented upgrade path: which release you run today, which LTS line you intend to stay on, and how many minor releases you will absorb between major moves. Confirm current general and security support dates on the Moodle releases page before you commit to a line, because those windows differ between releases. Ask your operator or implementation partner for the rate of the upgrade calendar, the test environment they will maintain, the plugin compatibility checks they will perform, and the rollback procedure for a failed database migration. Those items, not the license fee, are where most of the recurring cost in this comparison sits.
How to build the Docebo versus Moodle model with your own numbers
This sequence turns a Docebo renewal and a self-hosted Moodle option into a three-year model where recurring and one-time costs are separated, each line has an owner, and every figure traces to an invoice, a contract term, a hour estimate or a written quote.
Pull the Docebo invoice and contract terms
Finance or procurement gathers the current Docebo order form, the renewal terms, the licensed user or learner counts, any add-on modules, overage clauses, support tier and the notice period for changes. The procurement owner confirms each figure against the signed contract rather than a sales summary. This step is done when every subscription line has a document reference and a renewal date that the model can cite.
List every environment and integration in scope
The LMS owner, with HR systems, identity administrators and the compliance lead, lists each environment the replacement would need (production, staging, test and any sandbox), every integration that feeds or reads Docebo (HRIS sync, single sign-on, reporting exports, content authoring tools, external content libraries) and each audience, including employees, contractors and external learners. Each integration gets a named technical owner. The output is a scope register that the rest of the model uses as its row list.
Size hosting and storage from the package inventory
The content owner exports an inventory of course packages with their format (SCORM 1.2, SCORM 2004, AICC or xAPI), file size and version. Docebo's documented upload limit is a ZIP file of up to 2 GB per package, so the largest items are flagged for review. The platform team converts the inventory into storage and database sizing for a self-hosted Moodle instance, then prices hosting from its own cloud or data center quotes. Hosting and storage stay separate lines, and the step closes when the team can explain which assumptions drive each number.
Assign hours to each recurring operational task
The platform lead estimates the internal and partner hours needed each year for patching, Moodle major and point upgrades, backups and restore tests, single sign-on and HR sync support, monitoring, plugin maintenance and security response. Moodle's release cadence (major releases in April and October, point releases every two months) and its supported PHP and database versions should be reflected in the upgrade line. Each task gets an owner, a frequency, and a labelled assumption. The output is a recurring labour table with hours, roles and the source of each estimate, such as a staff timesheet or a vendor quote.
Add one-time migration and testing effort
The project manager adds the one-time work: installation and hardening, reloading the original packages, migrating users, enrollments and completion history through the Docebo export, rebuilding enrollment rules, testing integrations and running user acceptance. Completion records and learner history must be exported and migrated separately from the packages, so that work gets its own line. The step is complete when each one-time item has an estimate, an owner and a way to check it against the scope register.
Add the compliance evidence you will now carry
The compliance lead lists the assurance work that Docebo's provider currently carries and that the organization would own in its own environment, such as access reviews, logging, change records, backup evidence and vulnerability management. Some of this may be covered by controls the organization already runs. The lead asks each relevant auditor or certification body which evidence they expect, and records those items as recurring or one-time. This step produces a clear statement of what is not included in the model, so no reader assumes a saving that the business still has to pay for.
Run three-year scenarios at your own rates
Finance builds three scenarios over a three-year horizon: Docebo renewal at current terms, Docebo with the expected price change, and self-hosted Moodle with support from an internal team, a partner, or a mix. Staff time is costed at the organization's own loaded hourly rates, not averages from a report. Recurring and one-time totals are shown on separate rows, every line carries an owner and a source reference, and each assumption can be changed without rebuilding the model. The model is complete when a reviewer can trace any total back to its inputs.
Security attestations you take on when you run Moodle yourself
A SaaS vendor may hold its own attestations, and running Moodle yourself moves that evidence onto your team. Cornerstone's learning platform page, for example, describes its cloud service as holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization for the service it operates. Docebo's current attestation set is not something this page can state from supplied sources, so request its latest reports and certificates directly from Docebo before you build the cost model. Ask for the scope of each document, the period it covers, and whether it applies to the modules and regions you use. A self-hosted Moodle carries no such attestations by default. Whatever Docebo's documents cover for its own service does not transfer to your Moodle instance.
Once you run Moodle in your own cloud account or data center, your organization owns the controls and the evidence behind them. That includes access reviews for administrator and teacher roles, backup and restore tests, patch records for the operating system, web server, PHP and database, logging and retention, and vendor risk records for any managed hosting partner or plugin author you rely on. An external audit, if you need one, is commissioned and paid for by your organization, and its scope and timing are yours to set. Plan for that recurring cost in your model, not only the one-time build cost. Confirm early which frameworks your auditors will assess against, since that decides which control set you must document.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, control mapping and evidence collection for the Moodle stack. DeployOpen does not issue audit reports, attestations or certifications, and those come only from independent auditors and certification bodies. In a written scope, ask who owns each control after handover, which evidence is generated automatically and which is collected by hand, and how often it must be refreshed. Treat any gap between the Docebo documents you receive and the controls you must run yourself as a line item in the comparison, because that gap is where unplanned effort and cost usually appear.
Three ways to run Moodle and what each one bills
Self-running means you download Moodle, which is free and open-source software under the GNU General Public License version 3, and operate it in your own cloud account or data center. The software itself carries no license fee, so your cost is the infrastructure and the people who run it. Those costs recur every month, and they grow with user count, course media and the number of environments you keep.
- Compute and database: Web, PHP and database servers, plus backups and a staging copy for testing upgrades.
- Storage for course packages: SCORM, AICC and xAPI packages, video and uploaded files, which grow over time and need backup.
- Staff time: Platform engineers or administrators for patching, upgrades and monitoring. Moodle 5.1 requires PHP 8.2 or later and a web root that points to the new /public directory, so upgrades are real engineering work.
- Plugins and integrations: Single sign-on, HR feeds and reporting connectors are configured and maintained by your team.
- Security evidence: Hardening, vulnerability management and the controls you will be asked to show in an assessment.
Ask your internal team to estimate each line in writing before comparing it with a subscription quote.
MoodleCloud is one of the managed hosting options Moodle lists alongside self-hosting. Under this model the hosting provider operates the Moodle instance, so the subscription covers much of the infrastructure work that a self-run team would otherwise do. You still own the content, the user population, the integrations you configure and the policy decisions about who sees what.
- What the provider typically includes: Hosting, platform operation and Moodle version management, as described by the managed option. Confirm the exact list in writing.
- What you still pay for: Subscription tiers that may scale with users or storage, plus any add-on plugins and custom development.
- What you still own: Course design, enrollment rules, SSO and HR integration configuration, and your content migration.
- Data location: Confirm where data is stored, which backups exist, and how you retrieve a full export if you leave.
- Compliance evidence: Ask which attestations or assessment reports the provider holds, and which controls remain your responsibility.
Request the subscription terms, the storage and user limits, and the exit process before you treat this option as a cost comparison with Docebo.
Moodle Partners are organizations that provide managed Moodle hosting and services, as listed by Moodle. A partner can host the platform, run upgrades, and provide support, development or integration work. Pricing and scope vary by partner and by agreement, so the quote is the only reliable basis for comparison.
- Hosting and operations: Confirm whether the partner runs in your region, in a dedicated environment, or in shared infrastructure.
- Support and upgrades: Ask who handles the 6-monthly major releases, the security patches, and the testing of your plugins before each change.
- Customization: Custom plugins, theme work and integrations are usually billed separately from hosting. Ask for rates and for who owns the code.
- Data and exit: Confirm backup frequency, export formats and the steps for moving to self-hosting if your needs change.
- Attestations: Ask which security evidence the partner can supply and which controls you must still document yourself.
Ask for a written scope that lists each service, its recurring or one-time status, and the named responsibilities for your data.
Questions buyers ask about the Docebo to Moodle cost case
What drives the cost of running Moodle ourselves instead of a Docebo subscription?
The main drivers are the infrastructure you run, the people who operate it, and the work you take on that Docebo currently carries. Moodle itself has no license fee because it is GPL-3.0 licensed, so the recurring costs are hosting (compute, database, storage for course packages and backups), staff time for upgrades, patching, monitoring and plugin maintenance, and any paid support or managed hosting you choose. Storage grows with the SCORM, AICC and xAPI packages you upload, and Docebo's per-package limit of 2 GB for ZIP uploads is a useful reference point when sizing. Ask Docebo for a written list of what the subscription includes today (hosting, security attestations, uptime commitments, support tiers) so you can compare line by line.
Does Moodle have a license fee?
No. Moodle is free and open-source software under the GNU General Public License version 3, and the code is maintained by Moodle HQ. You do not pay a license fee to download, use or modify it. Costs appear in the services around it: hosting, managed hosting through MoodleCloud or Moodle Partners if you choose it, paid plugins from third parties, and the people or partner who run the platform. Confirm the license terms for any plugin you plan to use, since plugins are separate packages with their own licenses and are not covered by the core license.
How long does a migration from Docebo to Moodle take?
The duration depends on how much content, how many learner records and how many integrations you move, and on how many audiences and rules you rebuild. There is no supplied timeline for this migration, so the figure should come from a written scope, not a generic estimate. The main variables are the number of course packages to reload and test, the volume of completion history to export and map, the enrollment rules and HR or single sign-on integrations to rebuild, and how much parallel running you need. Ask any provider for a phased plan with the work listed per phase and the acceptance tests for each.
What does our team need to provide during a Moodle migration?
Plan for time from the people who own the content, identity, HR data and reporting. Content owners need to confirm which packages are current and which can be retired. Identity and HR staff need to explain user sources, group rules and how external users are handled. Reporting owners need to define which completion and compliance records must be kept and in what form. Your security team should review hosting, backups, access and logging. Ask whoever is delivering the work to list these inputs in the written scope so that each dependency has a named owner and date.
Can our internal team run Moodle without outside help?
Often yes, if you have engineers comfortable with PHP, a supported database, web server configuration and routine Linux operations. Moodle's upgrades are staged, and sites must already be on a supported release to upgrade, so someone has to own that schedule. Be honest about the gaps: security reviews, backup restore testing, plugin compatibility checks and any compliance evidence will fall to you. Many organizations split the work, keeping day-to-day operation in house and buying a fixed-scope implementation, hardening or retained support for the parts they cannot staff. Confirm your skills against the Moodle release requirements before deciding.
Which Moodle version should we plan on?
Plan on a long-term support release, and check the current dates before you commit. Moodle 4.5 is an LTS release from 7 October 2024 with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next LTS with general support until 4 October 2027 and security support until 1 October 2029. Confirm the current release status on the Moodle releases page at the time of your decision. Note the upgrade rules too: Moodle 5.3 requires sites to run Moodle 4.4 or later, and Moodle 5.1 requires sites on 4.2.3 or later, so an older install may need intermediate steps.
What should we request in a written quote for a self-hosted Moodle migration?
Ask for a fixed scope that lists each deliverable, the environment it runs in, and the acceptance test for it. Include the Moodle version and the PHP and database versions it requires, the content packages in scope and how they are reloaded, the learner record export and mapping method, the integrations to rebuild, and backup and restore testing. Request the handover documents, the runbook for upgrades, and a support option described in writing with its response scope. Also ask which items are one-time and which recur, such as hosting, support retainers and plugin subscriptions. DeployOpen does not publish a price list; a quote follows from the written scope.
What do we still have to confirm with Docebo before comparing costs?
Confirm with Docebo what your current contract includes, because the comparison only works if both sides cover the same things. Ask which hosting, backups, uptime commitments, security documentation and support tiers are included, and which items are billed separately. Confirm the export options for users, enrollments and completions, and the format of the original packages you can take with you. The Docebo system requirements page lists the supported package formats and the 2 GB ZIP limit, which you can check against your library.
How DeployOpen scopes a fixed-price Moodle implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted Moodle inside your own cloud accounts, data centers or air-gapped network. Engagements are fixed-scope, so the deliverables for replacing Docebo are agreed in writing before any work starts.
How we scope
- We inventory your Docebo subscription components, including hosting, storage, integrations and attestation reliance, before estimating the Moodle side.
- The written scope names the Moodle release line, database engine, PHP version and hosting target agreed with your infrastructure team.
- We list which SSO, HR feed, reporting and content-loading integrations are in scope, and which remain with your internal teams.
How we build
- We install Moodle with the database and PHP versions required by the chosen release, and set the web root to the public directory.
- We configure authentication plugins such as SAML2 or LDAP, and test them against your identity provider with sample accounts.
- We load a representative set of SCORM, AICC and xAPI packages and verify launch, completion and grade reporting before wider rollout.
How we hand over
- We document the deployment, backup and upgrade procedures so your team can run the platform after handover without us.
- We deliver the control evidence and configuration records your auditors or assessors will request, without issuing any attestation ourselves.
- We agree a rehearsal of the cutover and a rollback plan in the written scope, so learner records are reconciled before Docebo access ends.
How we support
- Ongoing support, Moodle minor-release upgrades and continuous security testing are available as retainers after handover.
- Retainer scope is agreed in writing, covering which patch cycles, backup tests and plugin updates your team wants us to own.
- Ask for the support boundary in your quote: which tasks stay with your staff and which move to a retainer.
