How to export your data from Docebo: packages reload, learner records need a separate pull
If you are leaving Docebo because of a renewal, a pricing change, a residency requirement or lock-in, the course content is the easier half of the move. The original SCORM, AICC and xAPI packages from your authoring tools can usually be reloaded into an open-source LMS such as Moodle or Open edX, while users, enrollments and completions must be pulled out of Docebo separately and migrated as records. Start by inventorying every course with its original package file, because Docebo's copy is the packaged version you uploaded, and that is the file you want to keep. Docebo's system requirements page lists a limit of 2 GB per ZIP upload for these packages, so any package near that size should be flagged for a check of its integrity after transfer.
The learner side needs its own plan. Completion history, enrollment dates, certificates and user attributes are not inside the packages, so they come out through Docebo's API services for reporting and learner data. The exact endpoints, the paging behavior and the rate limits are set by Docebo and can change, so confirm them in Docebo's own API documentation and with your Docebo administrator before you write any export script. Ask your administrator which user fields, custom fields and completion statuses your organization relies on, because those fields are often the ones that get lost. Also confirm whether your contract includes API access and whether your administrator account can run the reports you need.
Before you export anything, agree on what the target system must hold: which completions count as evidence for compliance training, how long history must be kept, and who signs off that the exported records match Docebo. Run a small test with a few courses and a few hundred learner records, compare counts and completion dates against Docebo screens, and only then schedule the full pull. Keep the raw exports in your own storage with access logs, since they are the record of training you may need to show an auditor, and confirm retention rules with your compliance lead.
Which Docebo data can be exported, by method, format and limit
This table maps each data type you need to move out of Docebo to its export path, file format and documented limit. Rows marked to confirm lack a supplied limit or endpoint, so ask Docebo for the current documentation before you plan the migration. The main takeaway is that course packages can be reused directly, while learner records need an API-based extraction.
| Data type | Export path | Format | Documented limits |
|---|---|---|---|
| Original SCORM 1.2 packages | Re-use the original package files from your authoring tool or Docebo course library | ZIP file | Uploaded ZIP up to 2 GB per Docebo system requirements |
| Original SCORM 2004 3rd edition packages | Re-use the original package files from your authoring tool or Docebo course library | ZIP file | Uploaded ZIP up to 2 GB per Docebo system requirements |
| Original AICC packages | Re-use the original package files from your authoring tool or Docebo course library | ZIP file | Uploaded ZIP up to 2 GB per Docebo system requirements |
| Original xAPI (Tin Can 1.0) packages | Re-use the original package files from your authoring tool or Docebo course library | ZIP file | Uploaded ZIP up to 2 GB per Docebo system requirements |
| Users and profile fields | Report and Learn API services, to confirm in Docebo's API documentation | Confirm with Docebo (likely JSON via API) | Endpoint, paging and rate limits to confirm with Docebo |
| Enrollments and completions | Report and Learn API services, to confirm in Docebo's API documentation | Confirm with Docebo (likely JSON or CSV via API) | Endpoint, paging and rate limits to confirm with Docebo |
| Course metadata (titles, IDs, catalog data) | Report and Learn API services or admin reports, to confirm with Docebo | Confirm with Docebo | Field coverage and limits to confirm with Docebo |
What Docebo does not hand over, and how teams rebuild it
Course packages and learner data can be moved, but much of what makes a Docebo tenant work lives in admin settings, integrations and vendor-run features. These cards cover the items that do not transfer as files, and what to document or confirm before your contract ends.
Enrollment rules and automation
Rules that auto-enroll learners by group, branch, job role or completion status live in the admin console, not in course packages. Export a written list of every active rule, its trigger, its audience and its due dates before you cut over. Rebuild them in Moodle with cohorts, enrollment methods and plugins, or in Open edX with cohorts and course access settings, then test each rule against a sample user. Ask Docebo in writing for a full rule export or documentation of the rule logic.
Branding, themes and certificates
Logos, colors, email templates and certificate layouts are platform settings, and certificate templates are often the hardest to match exactly. Capture screenshots, template fields and the wording of every certificate and notification email. Confirm with Docebo whether certificate issuance records, verification IDs and issued PDFs can be exported, since learners may need those records to prove past completions. Expect to recreate templates in the target LMS and to re-issue or map existing credentials.
SSO and HR integration settings
Identity provider connections, attribute mappings and HRIS sync jobs are configured inside the tenant and depend on Docebo-side field names. Record each connector, the attributes it maps, the sync schedule and the rules for deactivating leavers. In the target system, rebuild these with the SSO protocols it supports, for example SAML 2.0 or OAuth 2 in Moodle, or SAML 2.0 and OAuth2 providers in Open edX, and test with a pilot group. Ask Docebo for the list of connected integrations and any API credentials that must be revoked at shutdown.
E-commerce and payment settings
If you sold courses, price lists, coupons, invoices, tax settings and payment gateway links were configured in Docebo. None of these move with SCORM or xAPI packages. Export transaction and invoice history where Docebo allows it, and keep it for finance and tax retention. Moodle and Open edX need a separate commerce plugin or integration, such as a payment gateway module, to replace these functions. Confirm in writing what order and invoice data Docebo will release and in what format.
AI features and content marketplace
Docebo's AI features, content marketplace subscriptions and any third-party course libraries are licensed services tied to the vendor account. They do not produce files you own, and their outputs, such as generated summaries or recommendations, may have no export path. Inventory which features you used, which courses were sourced from a library, and whether licensed courses may be reused at all. Plan to replace these with the target LMS's own tools or with content you hold the rights to, and check license terms before you reload anything.
Custom reports, dashboards and branches
Saved reports, dashboard layouts, branch hierarchies and custom user fields are tenant configuration. Export the report definitions and the field list, then map each report to a query or plugin in the new LMS. Branch structures often drive permissions and reporting, so document the tree and its managers before you migrate users. Ask Docebo whether report definitions can be exported and which fields the API returns, because some report outputs may need rebuilding rather than copying.
Re-using the original SCORM, AICC and xAPI packages
Standard packages are the most portable part of a Docebo export, so start here. Keep the original ZIP files that your authoring tools produced, and do not rely only on copies stored inside Docebo. 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 page. Any package larger than that limit could not have been uploaded in the first place, so check your authoring archive for files near the ceiling and confirm that you hold a complete copy of each one. Store the originals in a versioned location you control, with the course name, version and authoring tool recorded alongside each file.
Test every package in the target LMS before you retire the Docebo copy. Import a sample of each standard type into a staging instance of your chosen platform, such as Moodle, and confirm that the package launches, that the course opens in the correct sequence, and that the first screen and the final screen both behave as expected. SCORM packages depend on how the LMS handles the run-time API calls, so a package can appear to load and still fail to report completion or score. Record which packages pass and which need changes, and ask the target vendor or implementation partner to confirm how their SCORM and xAPI launch settings are configured. Do not assume that a package that works in Docebo will report the same way in another system.
Keep the xAPI statements and learner records separate from the package itself. The package holds the course, while the record of who did what, when and with what result lives in a different store, and that history has to be exported and migrated on its own track. Packages do not carry completion history, so re-uploading content will not restore certificates or transcripts. Decide early which system will receive xAPI statements, such as a dedicated learning record store, and confirm with the vendor how each statement and its identifiers will map to your reloaded courses. Treat the package inventory and the learner record export as two deliverables with two owners and two acceptance checks.
The sequence for a complete export, with a check at each step
This sequence moves courses, original packages, users, enrollments and completion records out of Docebo into storage you control, and each step ends with a check that proves the copy is complete before the next one starts. The output is a verified archive that a migration team can load into an open-source LMS without relying on Docebo staying online.
Inventory courses, learning objects and packages
Start by listing every course, learning plan and learning object in Docebo that must be kept, with its content type (SCORM 1.2, SCORM 2004, AICC, xAPI or native Docebo content), owner and the audience it serves. Record which items are active, archived or retired, because retired content often still holds completion history. The output is a spreadsheet with one row per object. Verify it by comparing the row count against the course catalog view in the Docebo admin console, and confirm with the content owners that nothing is missing from the list.
Collect original package files from authoring teams
Docebo stores uploaded packages, but the files your authoring teams kept on their own drives are usually the cleanest copies. Ask each team for the original ZIP files exported from their authoring tool, and note the version, the tool and the date of each one. Docebo accepts packages up to 2 GB as ZIP files, so check that each archive is a complete package rather than a partial upload. The check is a launch test: open each package in a standard SCORM or xAPI test player outside Docebo and confirm it starts, reports progress and closes cleanly.
Obtain API credentials and confirm Report and Learn scope
Ask your Docebo administrator to create an API client with access to the Report and Learn API services, and confirm in writing which endpoints that client can call. Store the credentials in your secrets manager, not in scripts or tickets, and record who holds them and when they expire. Before pulling any data, make one test call for a single user and one for a single course, and confirm the response contains the fields you need. If an endpoint returns less data than the admin console shows, raise it with Docebo before the export starts, since missing scope is the most common reason an export looks complete but is not.
Pull users and enrollments with paging
Request the user list and then the enrollments for each course, following the paging parameters in the responses until no further pages remain. Respect the rate limits Docebo documents for your account and add retry logic with backoff for throttled responses, so that a rejected request is repeated rather than silently skipped. Write each page to disk as received, with the request parameters, timestamp and page number. The check is a count reconciliation: the number of user records and enrollment records you stored should match the totals Docebo reports for the same filters on the same day.
Pull completions and attempt records
Export completion status, scores, completion dates and, where the API returns them, individual attempt records and session times for each enrollment. Keep these as separate files from enrollments so that a later migration can rebuild history in order. Note the time zone and date format Docebo uses, since learner records migrated with a shifted date can fail compliance questions later. The check is a manual sample: select about 20 learners across different courses and years, and compare each record in your export with the same learner's view in Docebo. Any mismatch in status, score or date means the pull logic needs correction before you continue.
Store everything with checksums in your environment
Move the packages, JSON or CSV exports and logs into storage inside your own cloud account or data center, under the access controls your security team already applies to HR and training data. Generate a checksum for every file, such as SHA-256, and store the checksum list beside the files. Keep the raw API responses separately from any transformed versions, so a later reviewer can trace each value back to its source. The output is a manifest that lists each file, its size, its checksum and its origin. Verify it by recomputing the checksums from the stored copies and confirming that every value matches the manifest.
Reconcile counts against Docebo admin reports
Compare the totals in your archive with the reports Docebo's admin console produces for the same date range and filters: active users, enrollments per course, completions and course counts. Record each difference, explain it (for example, a user deactivated after the export started), and rerun the affected pull until the gaps are either closed or documented. Keep the reconciliation sheet with the manifest, because your auditors and the team loading the data into an open-source LMS will both ask how you know the archive is complete. Sign off only when every count is matched or explained.
Paging and rate limits: what to confirm before you script the pull
Page size, pagination method and API rate limits decide how long a full pull from Docebo takes and how the script must recover from errors, so settle them before writing any code. Ask Docebo for the documented limits on the Report and Learn API services: the maximum page size, how the next page is requested (offset, cursor or page number), how many calls are allowed per time window, what response Docebo returns when a limit is hit, and whether it sends a wait interval. Also confirm the lifetime of the access token you will use, how it is refreshed, and whether a long pull can outlive it. If any of these answers are missing from Docebo's own documentation, get them in writing from your Docebo administrator or account contact before you rely on them.
Run a small test pull before the full export. Pick one course with a known number of enrollments and completions, pull users, enrollments and completions for that course only, and compare the record counts with what the Docebo administration console shows. Check the fields you need, including user identifiers, completion dates and scores, and confirm that the same record does not appear on two pages. This test also shows how long a page takes at the documented rate, which gives you a realistic plan for the full run in your own environment, and it reveals any throttling responses your retry logic must handle.
Log every page as it is retrieved. Store the page request parameters, the number of records returned, a timestamp and a checksum or record identifiers in a small database or a file that your team controls. Write each page to your target store only after it is saved, and treat the log as the source of truth for resuming. If the job stops because of a rate limit, a token expiry or a network fault, restart from the last logged page rather than from the beginning, and deduplicate on the Docebo user and enrollment identifiers. Keep the log with the export as part of your audit trail.
What to plan before the Docebo renewal or termination date
A Docebo exit touches contracts, data, people and infrastructure at once, and each step depends on the one before it. The cards below follow the order most teams work in: start the clock from the notice period, get retention terms in writing, export everything while access still exists, staff the target environment, and decide who does the migration work.
Work back from the notice period
Find the notice period, renewal date and any auto-renewal clause in your Docebo agreement before anything else. Count backward from the date access ends to set the export start date, because the full export of packages, users, enrollments and completions takes longer than most teams expect. Confirm with your account contact whether notice must be written and to whom it must be sent.
Get retention terms in writing
Ask Docebo to confirm in writing how long learner records, course files and backups are kept after termination, and when they are deleted. Ask whether deletion is certified and how you receive confirmation. Do not rely on verbal answers or on general documentation, because retention periods are contractual and your compliance team will need the written terms as evidence.
Export everything before access ends
Pull the original SCORM, AICC and xAPI packages from your authoring source files, since uploaded ZIP files may not be the only copies you hold. Then export users, enrollments, completions and scores through the Report and Learn API services, paging through results and respecting rate limits. Keep the exports in a restricted location with checksums so you can prove completeness later.
Name an owner for the new environment
Assign one person to own the target LMS, including its hosting, upgrades, plugins and sign-on setup. This owner also schedules the security review of the new environment before any learner data is loaded, covering access control, backups, logging and vulnerability management. Without a named owner, cutover dates slip and the review tends to happen after go-live.
Decide internal or partner delivery
Decide whether your own team will rebuild enrollment rules, HR and SSO integrations and reporting, or whether a fixed-scope partner will do it under a written scope. An internal team carries the work alongside daily duties, while a partner needs deliverables, timelines and acceptance criteria agreed before work begins. Request a quote that follows from that written scope.
Plan the target platform version
Choose the target release and its database and PHP requirements before you build. For Moodle, confirm which long-term support or current release fits your upgrade cycle, since each release lists its own minimum PHP, database and upgrade-from version. Confirm these details against the release notes for the version you select, not against an older guide.
Questions buyers ask before exporting from Docebo
How much effort does a full export from Docebo take?
Effort depends mostly on the number of course packages, the learner volume and the quality of existing data. Packages are the largest transfer, since 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 size of your largest courses matters. Pulling users, enrollments and completions goes through the Report and Learn API services, where paging and rate limits set the pace. Ask Docebo to confirm the current limits for your tenant before estimating the job, since they are not repeated here.
Can an internal team export from Docebo without outside help?
Yes, a team with API experience and access to the original course files can usually do it in-house, but the work is not trivial. The steps involve locating original packages from authoring tools, scripting paged API calls, handling rate limits and reconciling records between systems. Teams without scripting skills or without a test environment often choose a fixed-scope engagement for the extraction instead. Either way, plan a written check of the output before anyone decommissions the Docebo tenant.
What does the export need from Docebo administrators and the API owner?
Your Docebo administrators must confirm which courses, catalogs and user groups are in scope, and who holds the rights to each content package. The API owner needs credentials with read access to the Report and Learn API services and must agree on the paging and throttling approach with Docebo's documented limits. Ask administrators to identify any content that was built by a third party or licensed from a library, because those packages may carry restrictions on reuse.
Which parts of the export are one-time and which recur?
The initial extraction of packages, users, enrollments and completions is one-time work. Recurring work appears only if you run a parallel period, where Docebo and the new LMS both hold live enrollments, or if you schedule incremental syncs until cutover. Ask any provider to separate these two costs in the quote, and to state whether ongoing syncs are included or billed as a retainer.
Are the course packages enough to move learner history?
No, packages alone do not carry learner history. Standard SCORM, AICC and xAPI packages hold course content, while completion history, scores, enrollment dates and learner records live in Docebo's data and must be exported and migrated separately. The reloaded course also has to be linked to these records in the new platform, which means mapping learner identifiers carefully. Confirm this mapping with your compliance owner before the cutover, since training evidence often depends on it.
How do you verify that an export is complete?
Verify completeness by reconciling counts and sampling records, not by trusting a single successful run. Compare the number of packages, users, enrollments and completions in Docebo with the counts in the target system, and open a sample of each course to confirm it launches and reports progress. Keep the export logs and a hash or checksum list for each package so you can prove later what was moved. Auditors and internal reviewers often ask for this evidence, and DeployOpen prepares the controls and records for review, while independent auditors issue any attestation.
What should a written scope or quote for a Docebo export include?
A written scope should list the content inventory, the data classes in scope (users, enrollments, completions, certificates), the target platform, the validation method and the acceptance criteria. Ask for the assumptions about API limits, the handling of packages that fail to load, and what happens if Docebo changes its API during the work. The quote should separate one-time extraction from any post-cutover support or retainer. DeployOpen does not publish prices, and a quote follows from the written scope.
What risks should we plan for before starting the export?
The main risks are incomplete learner records, packages that do not run outside Docebo, and rate limits that stretch the schedule. Content that depends on Docebo-specific features, such as certain assessments or certificates, may not behave the same way in another LMS. Keep the Docebo tenant readable until verification is signed off, and confirm your contract terms for data return and retention before you give notice.
How DeployOpen scopes, delivers and supports a Docebo data exit
DeployOpen approaches a Docebo data export as a fixed-scope engagement inside your own infrastructure. We agree the scope in writing first, then extract, verify and hand over learner records and course packages in a form your chosen open-source LMS can use. Ongoing support is available as a retainer.
How we scope
- Inventory which SCORM, AICC and xAPI packages are still live and which versions your authoring tools produced
- Define which user, enrollment and completion fields must be exported through the Report and Learn API services
- Agree paging, rate limit handling and the export windows in writing before any extraction starts
How we build
- Build extraction scripts that page through Docebo API responses and log every request and error
- Check package integrity for ZIP files near the 2 GB upload limit and confirm each one reloads in a test LMS
- Reconcile exported record counts against Docebo reports so gaps are found before cutover
How we hand over
- Deliver the export scripts, data dictionary and reconciliation results with a documented run sequence
- Provide a mapping of Docebo user, enrollment and completion fields to the target LMS data model
- Document where exported data is stored in your environment and how access to it is controlled
How we support
- Offer a retainer for re-runs, late-changing enrollments and questions raised during parallel running
- Confirm with your team which records must be retained for audit, legal or regulatory purposes and for how long
- Coordinate with your Docebo administrator and with the target platform team during cutover and decommissioning
