Migrate from Docebo to Moodle

How to migrate from Docebo to Moodle without losing completion history

Original SCORM, AICC and xAPI packages usually reload into Moodle, but completions, enrollments and users have to be exported from Docebo through its API and loaded separately. 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, so the authoring source files you still hold are the safest starting point. Confirm that you have the original package for every course, not only the copy Docebo has been serving, because a package exported from the LMS can carry Docebo-specific wrappers. If your renewal, a data residency requirement or a lock-in concern is the trigger, start by inventorying which courses are still assigned, which are retired and which carry compliance records you must keep for a defined period.

In most organizations the work is run by an internal platform or L&D team with an implementation partner handling the API extraction, Moodle installation, integrations and cutover. Your L&D owners decide which courses, enrollment rules and completion rules must be rebuilt, while your identity and HR owners decide how accounts and org structure map into Moodle. Effort and risk concentrate in three places: pulling completion history with the correct timestamps and scores, rebuilding enrollment rules that Docebo may have driven from HR data, and reconnecting single sign-on and HR feeds. Ask any partner to show a written mapping of every Docebo report field to a Moodle table or report before work starts, and confirm which Docebo API services your contract includes, since access can differ by plan.

A Moodle migration is not a lift-and-shift of Docebo's features. Docebo's automation, marketplace content and AI features do not come across as settings, so each one you rely on needs a named Moodle plugin, a custom build or a documented manual process. Treat the xAPI learner records as a separate store decision, because replayed package statements and historical completion data may need a learning record store outside the LMS. Plan a parallel run where Docebo stays read-only for a defined period, and reconcile completion counts per course and per learner before you retire it. Confirm the Moodle version and database requirements for your chosen release in the official release notes before you size the new environment.

Which Docebo capabilities map cleanly to Moodle and which need rework

This table compares the main Docebo capabilities that matter for employee training with their Moodle equivalents, marking each row as clean, needs rework or gap. Read it as a starting inventory: confirm each row against your own Docebo tenant and the Moodle release you choose before you plan the migration.

Docebo capability	Moodle equivalent	Status and note
Course catalog and course structure	Courses, categories and course sections	Needs rework. Catalog structure can be rebuilt, but category and naming conventions need a deliberate mapping.
SCORM 1.2 package hosting	SCORM activity module	Clean. Original packages from authoring tools reload as standard content; test launch and tracking on each one.
SCORM 2004 3rd edition package hosting	SCORM activity module with SCORM 2004 support	Clean. Confirm sequencing and navigation behavior for multi-SCO packages during test runs.
AICC package hosting	AICC activity module	Needs rework. Confirm the AICC activity is enabled on your chosen release and test each package end to end.
xAPI (Tin Can 1.0) package hosting	xAPI activity module or external LRS connection	Needs rework. Statements usually go to a separate learning record store, so choose and configure the LRS before cutover.
Enrollment rules and automatic enrollment	Cohorts, enrolment methods and plugins	Needs rework. Rules must be rebuilt, usually from HR attributes, and tested with sample users.
Completion tracking and history	Course and activity completion, plus exported records	Gap for history. Current completions can be loaded, but historical learner records need an export and separate import plan.
Certificates	Certificate activity or third-party certificate plugins	Needs rework. Templates, signatures and issuance rules must be recreated and checked against your policy.
Reporting and dashboards	Built-in reports, custom reports and LRS analytics	Needs rework. Report definitions must be recreated, and some Docebo views may have no direct equivalent.
Single sign-on	Core authentication plugins or SAML2 SSO plugin	Needs rework. Confirm your identity provider protocol and configure the matching auth plugin.
HR sync and user provisioning	External database, LDAP or web service integrations	Needs rework. Field mapping and scheduled sync jobs must be designed and monitored.
AI features, marketplace content and Docebo-specific automation	Plugins or no equivalent	Gap. Decide per feature whether to find a Moodle plugin, rebuild the workflow or drop it.

Which records and integrations move through Docebo's API

Four groups of data leave Docebo by different routes: the original course packages, user records, enrollment and completion history, and the integrations that feed or authenticate them. Each group needs its own export method, its own check and its own rebuild on the Moodle side before cutover.

Original content packages

Reuse the SCORM 1.2, SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) files from your authoring tools wherever you still hold them, because Docebo accepts these as ZIP uploads of up to 2 GB each. Pull packages from Docebo only when the source files are gone, and check each one for launch behavior and completion settings in Moodle before enrolling learners. Confirm the export format and download method for course files in Docebo's documentation before you script anything.

Users and profiles

Export user accounts, profile fields, branches and group membership through Docebo's API so Moodle receives the same identifiers that HR and SSO use. Map Docebo usernames and email addresses to Moodle accounts before the first load, since mismatched identifiers cause duplicate learners and broken completion links. Confirm endpoints, paging and rate limits in Docebo's API documentation before scripting the pull.

Enrollments and completion history

Enrollments, course status and completion dates are the records auditors and managers ask for, and they do not travel with the course files. Export them through Docebo's reporting and learning API services, keep the timestamps and scores, and store the extract in a format you can query after Docebo is retired. Moodle can load historical records only through its own tools or a custom import, so plan that work as a separate build item.

HR feeds and SSO integrations

HR-driven enrollment rules and single sign-on sit outside the course data but decide who gets access on day one. Moodle core ships authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, and the SAML2 single sign-on plugin covers SAML identity providers. Document every Docebo connector, then rebuild each one through a Moodle authentication method or web service rather than copying Docebo's configuration.

xAPI learning record store

Statements from xAPI courses can be sent to a learning record store (LRS), which is a separate system from the LMS and a separate decision. Choose whether the LRS holds all statements for reporting, feeds Moodle, or stays as an archive, and confirm how your xAPI packages address it before cutover. Moodle reporting alone may not replace a dedicated LRS, so test a sample course end to end.

Migration sequence from inventory to decommission

The sequence moves employee training from Docebo to Moodle in five gated stages, so each stage produces a written artifact that the next one depends on. Nothing is switched off until learner records reconcile and the organization has decided how long to keep its Docebo exports.

Inventory packages, learners and integrations
Before any build work, list every course with its original SCORM, AICC or xAPI package, its version and the authoring tool that produced it, since Docebo accepts ZIP uploads of up to 2 GB and the source files are what you reload. Count active learners, identify which integrations feed or read from Docebo (HR, SSO, reporting, certificates) and record the reports your compliance team relies on. The output is a signed inventory with a package list, learner volume, integration map and reporting requirements, and a named owner for each item.
Choose the Moodle release and build the target
Select the Moodle release line your organization will run, checking the PHP and database versions it requires and the upgrade path from your current installation, and confirm the web server document root points to the correct directory for that release. Your partner or internal team then builds the hosting, database, backup and authentication setup in your own infrastructure. The output is a documented environment with a tested backup and restore, and a list of the Moodle plugins you have approved and why.
Run a pilot with one audience
Load a small set of courses covering different package types and one learner audience through the target Moodle instance, including at least one course that depends on completion tracking and one that uses a certificate or deadline rule. Ask learners and course owners to test launch, progress saving, pass or fail status and the reports produced. The output is a pilot log with each defect classified, and a go or no-go decision recorded with the people who will sign off the cutover.
Reconcile both systems in parallel
Run Docebo and Moodle side by side for the audiences in scope, with new enrollments created in Moodle and historical records pulled from Docebo through its API, using the Report and Learn API services and handling the paging and rate limits they document. Compare user counts, enrollments, completion dates and scores for a sample and for every mandatory course, and investigate each difference. The output is a reconciliation report with zero open differences on mandatory training, or a documented exception for each one that remains.
Cut over sign-on, HR feeds and content
Freeze new enrollments and completions in Docebo, perform the final export of users, enrollments and completions, load the delta into Moodle and confirm the rebuilt enrollment rules now assign training correctly. Switch single sign-on and HR-driven user provisioning to Moodle, update links in internal portals and communicate the new login path to learners. The output is a cutover record showing the export timestamp, the reconciled counts and the owner who approved the switch to production.
Retain exports and decommission Docebo
Keep the final Docebo exports, original packages and reconciliation reports under your organization's records retention policy, which decides how long they must be held and in what form. Confirm with your legal and compliance owners that no open audit or learner query depends on Docebo access before you give notice. Once retention is secured, cancel the subscription and remove any remaining integrations or API credentials. Ask your partner and your Docebo contract owner to confirm the notice period and end-of-service steps in writing, as these come from your agreement and not from this plan.

How the migration changes by starting point and size

A single-company catalog with few packages is usually the simplest move. Most of the work is in testing each package once in Moodle, because the content itself is small and the enrollment logic is often a handful of manual or group-based rules. The effort is concentrated in confirming that each course launches, reports progress and records completion the way your compliance team expects.

Package testing: Launch every SCORM, AICC and xAPI package in a Moodle test course and check the score, completion status and time-tracking fields that your reports read.
Rule rebuilding: Recreate the few enrollment rules by hand, then confirm each one with a test user from each department.
Reporting reconciliation: Compare a sample of completion records from Docebo with the same learners in Moodle before you switch.
Single sign-on: Confirm which identity provider authenticates staff today and which Moodle authentication plugin will replace it.

Confirm early whether your compliance owner accepts a sample-based reconciliation or requires every completion record to be matched.

What drives cost and duration in a Docebo to Moodle move

This table lists the factors that change the effort of moving employee training from Docebo to self-hosted Moodle, and what each one costs in time or money. Read it as a checklist for scoping a quote, with the recurring run costs of a self-hosted Moodle set apart from the one-time migration work. Most quotes move with package count, SCORM version mix and integration complexity more than with anything else.

Driver	Why it changes cost or effort	How to keep it down
Package count and age	Each SCORM, AICC or xAPI package must be located, tested and reloaded, and old packages often lack source files or have broken launch paths. Volume drives both test time and storage.	Inventory packages in Docebo first, retire courses nobody has taken in recent years, and confirm which authoring source files still exist before scoping.
SCORM 1.2 versus SCORM 2004 or xAPI mix	SCORM 1.2 packages usually reload with less rework than SCORM 2004 or xAPI content, which can depend on specific LRS endpoints or sequencing rules. Mixed formats need separate test passes.	Group packages by standard, reload a representative sample of each group early, and confirm the Moodle release supports the standards you use.
Volume of learner history	Completion records, scores and attempt history must be pulled through Docebo's API in pages, then mapped to Moodle users and course IDs. Larger histories add export runtime and reconciliation work.	Decide which history must move (for example, records needed for compliance retention) and archive the rest. Ask the vendor for the paging and rate limit rules before estimating.
HR and SSO integrations	Provisioning from an HR system and sign-in through an identity provider must be rebuilt in Moodle, often with the SAML2 plugin or an external database connector. Attribute mapping errors are a common source of rework.	Document current attribute flows, pick the Moodle auth method per source early, and test with a small group of real accounts before cutover.
Custom Docebo automation to rebuild	Enrollment rules, auto-enrollment, notifications and branch logic configured in Docebo have no direct copy in Moodle and must be recreated with plugins, cohorts or custom code.	List every automation rule, mark which ones are still used, and reduce them to the Moodle features you will keep before design starts.
Reporting requirements	Dashboards and compliance reports built on Docebo data must be rebuilt from Moodle's reporting tools or an xAPI learning record store, which adds design and validation work.	Write down each report, its audience and its source fields. Agree on a small set of required reports for launch.
Moodle hosting model	Self-hosting puts server, database, backup, patching and upgrade work on your team or your implementation partner. A managed partner shifts some of this into a service contract. Moodle 5.1 and 5.3 have different PHP and database minimums, and 5.1 requires the web root to point to /public.	Choose a Moodle release line before design. Ask any provider to state the PHP, database and document root setup and who performs each upgrade.
Recurring run costs	Hosting, storage for course packages, plugin upkeep, security patching and support recur every year. The one-time migration effort is separate and ends at cutover, so the two must not be compared as if they were the same kind of cost.	Ask the quote to show one-time and recurring lines separately, and request the upgrade and patching cadence in writing.
Figures to request in a quote	A quote should state package count and formats, history volume in scope, integration list, automation rule count, report list, hosting model and the upgrade path, with each cost line marked one-time or recurring.	Confirm the inventory numbers yourself before sending the scope. Ask the provider to show its assumptions and what would change the price.

Running Docebo and Moodle in parallel and cutting over

Start by choosing the pilot audience, because it sets how long the two platforms must stay in step. A common choice is one business unit or one role family with a clear set of mandatory courses, moved first into Moodle while everyone else stays in Docebo. Record which course IDs, learner groups and enrollment rules belong to the pilot, and decide which system is the source of truth for each one. The rule should be simple: a learner is enrolled and tracked in exactly one platform for any given course at any time. Dual enrollment in both systems for the same mandatory course is the most common cause of conflicting completion records, so block it in the design rather than rely on managers to notice.

Keep enrollments in sync through the HR feed, not by hand. Point the HR or identity feed at Moodle for pilot users only, and keep the Docebo feed for everyone else, with a dated change log of which users moved. Use the Docebo export described in the data export topic to take a fresh snapshot of users, enrollments and completions before each reconciliation run, and compare it with Moodle's completion records for the same course IDs. Confirm with your compliance owner which completion evidence must be kept, where the xAPI learning record store sits during the overlap, and how long Docebo must remain readable for audit requests. The overlap period depends on your scope and the compliance deadlines you must meet, so confirm both before setting any date.

The cutover checklist should be a written runbook with an owner for each step: freeze new enrollments in Docebo for the cut population, run the final API export of users, enrollments and completions, reconcile it against Moodle, switch the SSO application and the HR feed to Moodle, and confirm that Docebo login is disabled for migrated users. Prepare communications to learners and managers that explain the new login address, where completions now appear, and who to contact for a disputed record. Test the rollback path before cutover, including how Docebo would be reactivated and how any learner activity in Moodle would be carried back. Ask your Moodle partner or internal team to confirm the cutover order against the Moodle release you deploy.

What usually goes wrong in a Docebo to Moodle migration and how to prevent it

Most failed LMS moves do not fail on content. They fail on learner records, identity attributes, upgrade prerequisites and compliance deadlines that nobody tested end to end. The cards below cover six risks that recur in Docebo to Moodle projects, each paired with the check that catches it before learners and auditors notice.

Completion records that do not match packages

Reloaded SCORM, AICC and xAPI packages carry their own tracking, but Docebo's completion history lives in its database and must be pulled through its API and mapped to new course IDs. If a course was re-versioned or split during the move, past completions can attach to the wrong module or disappear. Run a reconciliation test: pick a sample of learners per course, compare completion dates and scores in Docebo with those in Moodle, and sign off only on zero unexplained differences.

xAPI statements sent to an unready store

Moodle needs an xAPI learning record store to receive statements from courses that use xAPI. Choosing and sizing that store late, or pointing courses at an unconfigured endpoint, means statements are lost or silently queued while learners complete training. Before cutover, confirm which LRS will hold historical and new statements, test the endpoint with a sample course from each authoring tool, and confirm where the statements are retained and who can query them.

SSO attributes that differ from Docebo

Docebo users often arrive through an identity provider that sends attributes such as employee ID, department or job code. Moodle's authentication plugins map these differently, so a new login can create a duplicate account and orphan the old enrollments. Write an attribute map that lists each source attribute, its Moodle profile field and the matching rule, then test with a pilot group of accounts that exist in both systems before any production login is switched.

Upgrade path blocked by an old start version

Moodle only upgrades from specific earlier versions. Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. If the team plans to stand up a current release and import data, the source version constraint does not apply, but any in-place upgrade of a legacy instance does. Run a version check on any existing Moodle environment before scheduling work, and record the upgrade route in the cutover plan.

Web server pointing at the wrong folder

From Moodle 5.1 the web server document root must point to the new public directory instead of the main Moodle folder. Teams that carry an old Apache or Nginx configuration into a new release can expose directory listings or throw errors on login, which looks like a platform fault rather than a configuration one. Add a docroot check to the deployment runbook, verify the root resolves to the public directory after each upgrade, and test the login and course pages from outside the internal network.

Compliance training gaps during cutover

Mandatory training with regulatory deadlines cannot pause while the platform changes. If Docebo is switched off before Moodle holds every active assignment and due date, learners may miss required courses and the organization loses evidence of who completed what. Keep Docebo read-only for an agreed overlap window, freeze new mandatory assignments in one place at a time, and have compliance owners sign off on a list of active mandatory courses in both systems before decommissioning Docebo.

Questions buyers ask before moving employee training to Moodle

How much effort and cost does moving employee training from Docebo to Moodle take?

The effort is driven mostly by how much content, history and integration you carry over, and the work splits into one-time migration and recurring operation. One-time work includes reloading SCORM, AICC and xAPI packages into Moodle, exporting users, enrollments and completions through Docebo's API, rebuilding enrollment rules and testing HR and single sign-on links. Recurring costs include hosting, database and backup storage, Moodle upgrades, plugin maintenance and security patching that you now carry yourself. Ask any partner for a fixed-scope quote that lists each content library, each integration and each report, with the assumptions behind them. Your own hosting and staff time also belong in the comparison with your current Docebo subscription.

How long does a Docebo to Moodle migration take?

The timeline depends on the size of your content library, the number of learner records to move, how many HR and identity integrations must be rebuilt, and how many compliance reports must match the old history. A pilot with one course family and one set of enrollment rules usually shows which of these dominate your schedule. Ask for milestones covering a staging environment, a content test in which every package is launched and completion is confirmed, a cutover window and a parallel-run period. Because the cutover date affects compliance training due dates, agree on how in-progress enrollments will be handled before you set a target date.

What does our team need to provide during the migration?

A successful move needs several owners, not only the platform team. Content owners must confirm which SCORM, AICC and xAPI packages are current, retire outdated courses and test a sample of each type after reload. HR must confirm the source of truth for hires, transfers and leavers, and which job roles trigger mandatory enrollments. The identity team must define how single sign-on and user provisioning will work in Moodle, including which authentication plugins they expect to use. Compliance must specify which completion records, certificate dates and audit fields regulators or internal auditors need, so the export and reports can be verified against them before the old system is switched off.

Can our internal team migrate Docebo to Moodle without a partner?

Yes, an experienced internal team can do the work, but the decision should rest on capacity and skills rather than on the software alone. Your team needs administrators who can install and harden Moodle, write and test API scripts against Docebo's Report and Learn API services, and maintain database and web server configuration. Be realistic about the ongoing side: Moodle requires a regular upgrade cycle and a team that can apply security updates on time. If you bring in a partner, ask for a written scope that covers implementation, integration, hardening, backup and documentation, and be clear about which parts remain with your staff after handover. Note that DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

Which Moodle release should we choose for employee training?

For a regulated employee training platform, choose a release that is still inside its support window on your go-live date and plan the next upgrade before you launch. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Confirm current dates on the Moodle releases page before you commit, because the release calendar moves on.

Why does the upgrade path matter when we choose a Moodle version?

The upgrade path decides whether your first Moodle version can be maintained for years without a rebuild. Each release sets its own minimum requirements: Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, with PHP 8.4 supported, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and it can be upgraded only from Moodle 4.4 or later. Moodle 5.1 also requires the web server document root to point to the new /public directory. Ask your team to confirm which versions your server stack, plugins and integrations support before you pick a release.

Will we keep our SCORM, AICC and xAPI content after moving to Moodle?

Usually yes, because Docebo accepts standard SCORM 1.2, SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages uploaded as ZIP files of up to 2 GB. The original packages from your authoring tools are the safest source, so locate them before you retire any course in Docebo. Content still needs testing in Moodle, since packages that depend on a specific player, a hard-coded launch path or a Docebo-only API call may behave differently. Completion history and learner records are a separate task: they must be exported through Docebo's APIs and imported or mapped in Moodle, and you should confirm with a test cohort that completions, scores and certificate dates carry over correctly.

What should we ask about xAPI and learning record storage before we start?

Decide early whether you need a learning record store (LRS) for xAPI statements, because Moodle's native reporting does not replace one for every xAPI use case. Ask the team to list which packages send xAPI statements, where those statements are stored today in Docebo, and which reports depend on them. Then confirm with each candidate LRS vendor or project which xAPI version it accepts, how it handles historic statements, and how access controls and retention are configured. Keep the LRS on infrastructure you control if the learner data is sensitive, and ask for a written data flow diagram that shows where each record goes during and after the migration.

How DeployOpen scopes, runs and supports a Docebo to Moodle migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Docebo to Moodle move, we start with a written scope that covers the training content, learner records, identity and HR integrations, and the Moodle hosting you choose.

How we scope

Inventory every SCORM, AICC and xAPI package, its version and its known launch issues before any reload
Agree in writing which user, enrollment and completion data is in scope for export through Docebo's API
Map each enrollment rule, HR feed and SSO connection to a Moodle equivalent or a documented replacement
Confirm the target Moodle release, PHP and database versions, and the xAPI learning record store choice

How we build

Stand up Moodle in your own cloud account, data center or air-gapped network with the web root set to the /public directory
Reload packaged courses into Moodle and test each one for tracking, bookmarks and completion reporting
Rebuild enrollment rules, cohorts and HR or SSO integrations, including the authentication plugins your directory requires
Migrate completion history into a documented format and reconcile record counts against the Docebo exports

How we hand over

Deliver runbooks for installation, upgrades, backups, cron tasks and the xAPI store configuration
Document the data mapping, reconciliation results and any learner records that could not be migrated
Walk your administrators through course management, enrollment rules and reporting in Moodle
Provide compliance-ready evidence of configuration and access controls for your own assessors to review

How we support

Plan Moodle point releases and major upgrades against the published support windows for your chosen version
Offer ongoing support, upgrades and continuous security testing as a retainer after handover
Run security testing of the Moodle deployment and its integrations on a schedule agreed in the scope
Confirm with your team, before go-live, who owns the Moodle hosting, backups and incident response