Which open-source LMS can replace Docebo, and what moving involves
Moodle fits broad corporate and compliance training, and Open edX fits teams building course-style programs with a strong authoring need. If your Docebo renewal, pricing terms or data residency requirements have pushed you to look elsewhere, the first decision is which of these two platforms matches your catalog. Moodle is free and open-source software under the GNU General Public License version 3, and it is widely used by universities, schools and companies. Open edX is stewarded by Axim Collaborative, a nonprofit founded by Harvard and MIT, has no licensing fees, and includes the Open edX Studio authoring tool. Both can be self-hosted inside your own cloud account, data center or private network, which is the main reason many teams with residency or lock-in concerns evaluate them.
Teams usually start the review with their contract and their content. Docebo accepts SCORM 1.2 and SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages uploaded as ZIP files of up to 2 GB, according to Docebo's system requirements page, so your course packages are portable standards content rather than proprietary objects. Confirm the package sizes and versions in your own library before you commit, because older SCORM 1.2 packages and large video-heavy SCORM files often behave differently after import. Also confirm which of your reporting, certification and manager-approval workflows depend on Docebo-specific features, since those will need to be rebuilt rather than reloaded.
Reloading packages is the easy part. Completion history and learner records must be exported and migrated separately, and the enrollment rules and HR integrations that assign training to people will need to be rebuilt on the new platform. Decide early whether a learning record store will receive xAPI statements, and test that the new platform writes the statements your audit trail requires. Ask any implementation partner for a written scope that lists each integration, each report and each record type to be migrated, along with the test evidence for each. Feature gaps in Docebo's AI assistance and content marketplace are covered in the sections below, so plan those as separate decisions rather than assuming a like-for-like replacement.
Moodle and Open edX as self-hosted Docebo alternatives
Moodle and Open edX are the two open-source platforms most likely to take over corporate courses from Docebo, and self-hosted Canvas LMS is a narrower course-focused option. Each card below names the license, the component you would run, and the trade-off you accept before reloading SCORM, AICC or xAPI packages into it.
Moodle for broad corporate training
Moodle is free and open-source software under the GNU General Public License version 3, and it is used by universities, schools and companies. For a Docebo replacement, its strength is the breadth of its plugin ecosystem, which covers SCORM and xAPI player support, enrollment, reporting and many HR and single sign-on connectors. Check which SCORM and xAPI plugins your content needs, test a sample of packages from your authoring tools, and confirm how completion data is stored so you can export it. Trade-off: you assemble and maintain more plugins yourself.
Open edX with Studio authoring
Open edX is stewarded by Axim Collaborative, a nonprofit founded by Harvard and MIT, and it has no licensing fees. Its Studio authoring tool gives course teams a built-in way to build and edit content, which reduces dependence on external authoring for new courses. The edx-platform code is licensed under the GNU Affero General Public License version 3, so any modifications you host for users over a network carry source disclosure duties that legal teams should review. You can run it yourself or use a managed Open edX provider. Trade-off: it is built around course-style learning more than enterprise compliance workflows.
Self-hosted Canvas LMS for courses
Canvas LMS is created and maintained by Instructure, and its source code is released under the AGPLv3 license. The repository wiki includes Quick Start and Production Start guides for self-hosted installs, and its Course Import Tool accepts Common Cartridge and IMSCC packages, which helps when moving structured course material out of other systems. It is oriented toward academic course delivery, so enrollment rules, HR feeds and certification tracking typically need custom work. Confirm which Instructure-hosted features are absent from the open-source code before you commit. Trade-off: it fits course content well but needs more work for workforce compliance.
Which open-source option covers each Docebo capability
This table maps each main Docebo capability to Moodle, Open edX or both, and marks coverage as native, via plugin, partial or something to confirm with the vendor or community. Use it to scope which features you rebuild, which you add through plugins and which you drop or replace. Coverage marks describe typical starting points, so verify plugin versions and xAPI Learning Record Store compatibility in your own environment before committing.
| Docebo capability | Moodle | Open edX |
|---|---|---|
| SCORM 1.2, SCORM 2004 and AICC delivery | Native support for SCORM and AICC packages in the course activity set | Native support for SCORM packages through the course content tools, confirm AICC handling for your packages |
| xAPI (Tin Can 1.0) delivery | Via plugin, confirm the xAPI plugin version and its compatibility with your Learning Record Store | Via plugin or external tooling, confirm xAPI support and LRS compatibility in your deployment |
| Learner records and reporting | Native course and activity reports, extended by plugins for cross-course analytics | Native course reporting, cross-course analytics usually needs external data pipelines, confirm with your provider |
| Learning record store (LRS) integration | Requires an external LRS, which you select, host and back up yourself | Requires an external LRS, which you select, host and back up yourself |
| Enrollment and rule-based assignment | Native cohort and enrollment methods, rule-based automation typically needs plugins or custom code | Native enrollment and cohort tools, rule-based assignment typically needs custom development, confirm with your provider |
| HR and HRIS integration | Via web services, LDAP or SSO plugins, HR feed mappings are built and maintained by your team | Via LMS APIs and identity integration, HR feed mappings are built and maintained by your team |
| Certification and recertification tracking | Partial, native completion conditions with plugins for expiry and recertification, confirm the plugin fits your rules | Partial, native certificates with custom or plugin logic for expiry and recertification |
| Content marketplace and third-party libraries | Not applicable | Not applicable |
| AI-assisted features | Not applicable | Not applicable |
How the cost of self-hosting Moodle or Open edX compares to Docebo
This table lists the cost components on the Docebo side and on the self-hosted Moodle or Open edX side, marking each as one-time or recurring and naming what drives it up. Use it to build a like-for-like comparison, then request written quotes that show each line separately. No prices are shown because none were supplied, and DeployOpen does not publish a price list.
| Cost component | Docebo subscription and self-hosted open source | Who is paid and what drives it |
|---|---|---|
| Platform licensing | Docebo: recurring subscription, priced by contract. Moodle and Open edX: no license fee under their open-source licenses. | Docebo: vendor contract terms, user count and modules. Open source: none, but confirm any paid add-ons you plan to use. |
| Infrastructure and hosting | Docebo: included in the subscription. Self-hosted: recurring cloud or data center costs for compute, storage, database and backups. | Concurrent learners, content volume, backup retention and high-availability design. Ask for a sizing estimate tied to your user count. |
| Implementation and configuration | Self-hosted: one-time build of roles, enrollment rules, catalog and branding. Docebo: one-time configuration work, often with the vendor or a partner. | Number of enrollment rules, approval workflows and custom reports. Ask for a fixed-scope statement of work with named deliverables. |
| Content re-import and QA | Self-hosted: one-time reload of SCORM, AICC and xAPI packages, followed by testing each package in the new player. | Package count, package size (Docebo accepts ZIP files up to 2 GB per its requirements page), and number of broken or legacy packages. |
| Learner history migration | Self-hosted: one-time export and mapping of completions, scores and transcripts, with a retained archive for audit. | Years of history, record volume and the fields needed for certifications. Confirm the export format with Docebo before work starts. |
| HR and identity integration build | Self-hosted: one-time build of HRIS, SSO and user provisioning connectors, then recurring maintenance when source systems change. | Number of source systems, sync frequency and whether the sync is one-way or two-way. Request the integration list in writing. |
| Support, security patching and upgrades | Docebo: recurring, included in the subscription. Self-hosted: recurring retainer or internal staff time for patches, releases and vulnerability response. | Release cadence, number of environments, and compliance evidence you must produce. Ask whether support is by retainer or per incident. |
| Internal skills and staffing | Self-hosted: recurring internal or contracted roles for platform administration, database work and security operations. | Team size, on-call expectations and skills gaps. Docebo: vendor admins handle much of this, though your team still administers the tenant. |
| Exit and migration costs | Docebo: one-time cost of exporting content and records if you leave. Self-hosted: one-time cost of migrating in, then recurring cost of keeping the exit path open. | Volume of content, learner records and integrations. Ask each vendor for its export capabilities and any fees for data extraction. |
What you give up when you leave Docebo and how teams work around it
Moving off Docebo means losing some features that a vendor runs for you, not only ones you can see in the interface. The cards below cover the most likely gaps, the usual workaround for each, and the point where you should confirm the current Docebo feature list directly with the vendor before you commit.
Vendor-run AI features
Docebo offers AI-assisted capabilities that run in the vendor's cloud and are maintained with its release cycle. Open-source Moodle and Open edX do not ship equivalents with the same scope, so teams usually rebuild only the features they use, such as content tagging or search, through plugins or a separate service they host. Ask Docebo which AI features exist today, which data they process, and whether any can be disabled. Then decide which ones your learners depend on before you plan a replacement.
Content marketplace integrations
Docebo connects to third-party content catalogs through vendor-maintained connectors. In a self-hosted LMS, those catalogs are not connected by default, so you either keep buying access directly from the provider and import packages, or you build a connector against each provider's API. Standard SCORM, AICC and xAPI packages from a catalog can still be loaded, but licensing terms and single sign-on for the catalog must be re-established. Confirm which marketplaces you use and whether each one allows package download or only streamed access.
Vendor-managed uptime and security attestations
When Docebo runs the platform, uptime commitments, patching, and third-party attestations are the vendor's responsibility and appear in its contract and reports. Self-hosting moves those duties to your team or to a partner: monitoring, backups, patch windows, and evidence collection for your own assessments. Attestations for the hosting environment are not transferred to you automatically. Ask Docebo for its current attestation reports and service levels, and map each item to the control owner in your organization.
Out-of-box reporting
Docebo ships with dashboards and standard reports for completions, certifications, and learner activity. Moodle and Open edX provide built-in reports and logs, but their layouts differ, and some compliance views require custom queries, reporting plugins, or an analytics layer fed by xAPI statements. Plan the reports auditors and managers rely on, rebuild them against a test dataset, and confirm that the exported history matches what Docebo produced before retiring the old views.
Migrating from Docebo to Moodle or Open edX in seven phases
This sequence moves courses, packaged content, learner history and enrollment logic from Docebo to a self-hosted platform in controlled stages, so that every course and completion can be traced before Docebo is switched off. Each phase ends with a written check that the next phase can rely on.
Inventory courses, packages and integrations
Your team lists every active and archived course, every uploaded SCORM, AICC and xAPI package, and every integration that touches Docebo, including HR feeds, single sign-on, certificate tools and reporting exports. Record the package format and version for each item, along with its owner and whether it is still assigned to anyone. The output is a single inventory signed off by the business owners of the training catalog, with items marked keep, retire or rebuild. Confirm the Docebo upload limits and package types in your own tenant settings before you rely on the list.
Export packages and learner records separately
Download the original package files from your authoring source or Docebo's content library, and keep them in a versioned repository with checksums. Export completion history, scores, attempt records and certification dates as a separate data set, because the packages carry course logic but not the historical learner record. Ask your Docebo administrator or account team which export formats and fields are available, and check them against a sample learner. The check is a reconciled count of learners and completions per course that matches the source reports.
Map enrollment rules, roles and HR attributes
Document every automatic enrollment rule, branch, group, role and approval flow in Docebo, then rebuild each one as a Moodle or Open edX equivalent, such as cohorts, groups, role assignments or enrollment plugins. Map HR attributes like department, location and job code to the identity fields your new platform will read. Involve HR operations and the identity team, because enrollment logic depends on data they own. Sign-off means every rule has a documented target, a named owner and a test case that expects the same learners to be enrolled.
Pilot a few SCORM and xAPI courses
Select a small set of representative courses, including at least one SCORM package and one xAPI package, and load them into a non-production instance of your chosen platform. Test launch, bookmarking, score reporting, completion status and the handling of attempts, using a small group of test learners. Confirm how the learning record store receives xAPI statements and whether your reporting needs a separate LRS. The pilot ends with a defect list and a decision on whether the packages need repackaging, which the platform team should document before any production load.
Run in parallel and reconcile completions
For a defined period, keep Docebo live for existing enrollments while the new platform receives the same courses for a controlled learner group. Compare completions, scores and certificate dates between the two systems each week, and investigate each difference at the learner level. Parallel running is where most migration errors surface, so involve compliance owners who rely on the records. The phase closes when the discrepancy log is empty or every remaining difference has an approved explanation and a correction.
Cut over enrollments and HR sync
Freeze new enrollments in Docebo, load the migrated completion history and active enrollments into the new platform, and switch the HR synchronization feed to point to it. Confirm that single sign-on, notifications and certificate links work for real users before opening the platform widely. Keep a rollback plan that names the conditions under which enrollment returns to Docebo. The cutover is complete when a sample of learners in each department can sign in, see their assigned courses and show the correct status.
Archive records and decommission Docebo
After the business and compliance owners accept the migrated records, export a final archive of Docebo data, including course packages, learner records, audit logs and reports, and store it in a location your retention policy allows. Confirm with your legal and compliance teams how long the archive must be kept and who can access it. Only then cancel the subscription, remove integrations and revoke access. The step is done when the archive has been verified, the retention decision is recorded and Docebo no longer receives any learner data.
Which option fits your situation: compliance, data residency or content-heavy programs
When a regulator, customer contract or internal policy requires learner records and course content to stay in a named region or inside your own data center, a self-hosted LMS moves that control to you. Moodle and Open edX both run in your cloud accounts, on-premises servers or air-gapped networks, so the hosting location, database, file storage and backups are decisions you make and document.
- Hosting location: Confirm which cloud regions, data centers or network zones your policy allows, and deploy the database, media storage and backups only inside them.
- Backup and log copies: Include search indexes, email relays, analytics exports and backup vaults in the residency map, since these often leave the primary region.
- Third-party content: Vendor libraries and externally hosted video may still send learner data outside your boundary, so review each integration.
- Access from outside the region: Support staff and contractors who connect from other countries count as data access under many policies, so define who can reach production.
- Operations ownership: Someone on your team or a contracted operator must own patching, restores and capacity, because self-hosting moves that work to you.
Ask your legal and privacy team to write the residency requirement as specific hosting, storage and access rules before comparing platforms.
Docebo is a paid subscription, so the cost question is whether a license-free core, plus the people and services needed to run it, costs less over your planning horizon. Moodle is distributed under the GNU General Public License version 3, and Open edX has no licensing fees, which removes the per-seat license line. The remaining costs are infrastructure, staff time, integration work and any outside support you buy.
- One-time costs: Migration of packages, enrollment rules, HR connectors and reporting, plus environment setup and testing, are paid once, usually against a written scope.
- Recurring costs: Hosting, storage, backups, security monitoring, upgrades and staff time recur every year, and they grow with learner count and content volume.
- Internal or partner operations: Decide whether your team runs the platform or a managed Open edX provider or implementation partner does, since this changes the recurring line more than the license does.
- Upgrade cadence: Budget for regular core and plugin upgrades, because skipped upgrades raise later costs.
- Quote requests: Ask any provider to separate setup, migration, run and support fees, and to state which items are optional.
Compare the total of these components against your current Docebo invoice and renewal terms rather than against the license alone.
Teams that need custom workflows, branded experiences, bespoke reports or authoring-led course production will find that both Moodle and Open edX can be extended. Moodle offers a plugin ecosystem and a large administrator community. Open edX includes the Open edX Studio authoring tool, which lets course teams build and edit courses within the platform, and its code is licensed under the GNU Affero General Public License version 3, which carries source-sharing obligations when you modify and offer the software over a network.
- Plugin fit: Check whether each required feature exists as a maintained plugin for your target version before assuming it can be built.
- Authoring workflow: Compare how course authors create content in Studio or Moodle activities against the authoring habits your teams already have in Docebo.
- Custom code ownership: Record every local change, because custom code must be carried through each core upgrade.
- License obligations: Have counsel review how the AGPL applies to your modifications if you run a modified Open edX and make it available to users over a network.
- Reporting and APIs: Confirm the reporting features and APIs your business teams depend on, since these are often the most expensive custom work.
Before committing, build one representative course and one custom report on a test instance to measure the effort.
Regulated organizations need training records that show who was assigned what, when they completed it, which version of the content they saw and who could change those records. Moving to a self-hosted LMS means you take on the access control, logging, change management and backup evidence that a SaaS vendor previously supplied as part of its own assurance. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments.
- Access control: Define administrator roles, enforce multi-factor authentication for privileged accounts and review access on a set schedule.
- Audit logging: Retain logs of enrollment changes, grade edits and record deletions in a location administrators cannot silently alter.
- Record integrity: Document how completion records and content versions are preserved when courses are updated or reloaded.
- Vendor assurance: Docebo and Cornerstone may hold their own certifications, which you cannot inherit when you self-host, so map the controls you must now evidence yourself.
- Assessor scope: Ask your auditor which controls they expect to see, and confirm the relevant control IDs with the applicable standard owner.
Bring your compliance lead and external assessor into the design phase so that the evidence you collect matches what they will request.
Questions buyers ask before replacing Docebo with a self-hosted LMS
How much effort does moving off Docebo to Moodle or Open edX take?
Effort depends mostly on the volume and age of content, the number of integrations, and how many learner records must be carried over. No effort figure is supplied for this migration, so treat any number you hear as unverified until it comes from a written scope. The main drivers are the count of SCORM, AICC and xAPI packages, whether completion history must be migrated, how many HR and single sign-on connections must be rebuilt, and how many enrollment rules exist. A small catalog with few integrations is a very different project from a multi-region program with compliance reporting. Ask for a page-by-page inventory of courses, packages and integrations before you ask for a timeline.
Can our internal team migrate from Docebo without outside help?
A team with LMS administration, Linux operations and integration experience can often handle the platform setup, but the migration itself touches several disciplines at once. Your team will need to confirm the Docebo export options available to them, rebuild enrollment logic, and test reporting before cutover. Check whether anyone has run Moodle or Open edX in production, who will patch and back up the system after launch, and whether there is capacity to test while business-as-usual support continues. Many organizations split the work: internal owners keep content and HR decisions, and an implementation partner handles deployment, integration and hardening. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, typically under a written, fixed scope.
What do HR, security and content owners need to provide during the migration?
The migration needs decisions and access from people outside the LMS team. Before work starts, confirm the following:
- HR owners: the source of truth for job roles, org units, manager relationships and hire or termination events, plus the rules that assign mandatory training.
- Security owners: identity provider settings, network placement, logging requirements, encryption and backup policy, and which compliance controls the new system must evidence.
- Content owners: the list of active, retired and archived courses, the authoring tool that produced each package, and who approves content before it goes live.
Agree on who signs off each of these items. Gaps here usually show up as broken enrollments or unexplained audit findings after cutover.
Do SCORM and xAPI packages reload into Moodle or Open edX unchanged?
Standard packages usually reload without rebuilding, because Docebo accepts SCORM 1.2, SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages uploaded as ZIP files of up to 2 GB, according to Docebo's system requirements and limitations page. Reloading still needs testing. Packages that rely on vendor-specific player calls, unusual launch files, or LRS endpoints hard-coded to Docebo may need changes. Check that xAPI statements point to your new learning record store, not the old one. Test a sample from each authoring tool before bulk loading. Moodle supports SCORM and AICC packages, and Open edX can deliver content through its own authoring and course tools, so confirm the exact standards support for your chosen platform and version in its documentation.
What happens to learner completion history when we leave Docebo?
Completion history does not move with the course packages. Packages carry the content, while completion records, scores, certificates and attempt history sit in Docebo's database and must be exported and migrated separately. Plan for three things: an export of learner records in a format you can map, a decision on whether historical records are loaded into the new LMS or kept in an archive, and a reconciliation step that proves the counts match. For regulated training, keep the original records accessible for the retention period your policy requires, even if the new system does not display them. Ask Docebo which export formats and fields are available under your contract, and confirm what your auditors will accept as evidence of past completion.
Can AI features and the content marketplace be replaced in an open-source LMS?
Partly. Moodle and Open edX cover course delivery, assessment, reporting and standard content packages well, but they do not ship a built-in equivalent to every Docebo feature. Marketplace integrations to third-party content libraries are not automatic, so each connection needs to be checked against the provider's own API and licensing terms. AI features such as automated content generation or recommendations are not provided out of the box by these platforms. Where you need them, they are added as separate components with their own data handling, hosting and cost, and these should be scoped and reviewed separately. List every Docebo feature your users rely on, mark which ones are core LMS functions and which are add-ons, and confirm each gap before you commit to a timeline.
How is the migration scoped and quoted?
DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask any provider to break its quote into components: discovery and inventory, platform installation in your environment, content reload and testing, enrollment and HR integration rebuild, learner record migration, security hardening, backup setup, documentation, and training for administrators. Also ask which costs are one-time and which recur, such as hosting, patching, upgrades and support. Ongoing support, upgrades and continuous testing are available as retainers. Ask for the assumptions behind each line, because the package count, integration count and record volume usually drive the largest changes.
How DeployOpen scopes, migrates and supports a Docebo replacement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Docebo replacement, that means agreeing a written scope first, building Moodle or Open edX in your environment, and handing over documented, tested systems your team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Scope inventories the SCORM, AICC and xAPI packages, learner records, enrollment rules and HR feeds in use today.
- Ask for a quote built from that written scope, with each component priced separately: platform build, integrations, migration and testing.
How we build
- Deploy Moodle or Open edX in your own cloud account, data center or air-gapped network, under your control.
- Reload original SCORM, AICC and xAPI packages and verify launch, completion and score reporting in a staging environment.
- Rebuild enrollment rules and HR integrations, then run security testing of the application, APIs and infrastructure before cutover.
How we hand over
- Documentation covers architecture, configuration, integration mappings, backup and restore steps and the upgrade procedure.
- Migration evidence records what was moved, what was reconciled and what was exported separately, such as learner history.
- Compliance readiness material prepares systems, controls and evidence for your assessors, who issue any audit report or certification.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Confirm with us which upgrade and patch responsibilities sit with your team and which sit with the retainer.
- Support scope is set in writing, so response expectations and service levels are agreed before go-live rather than assumed.
