Migrate from Docebo to Open edX: what the move involves
Moving a customer or partner academy from Docebo to Open edX is a rebuild, not a file copy. The work splits into four parts: rebuilding courses in Open edX Studio, re-establishing identity for external learners, replacing Docebo's commerce and certificate functions, and migrating learner records as a separate project. Platform and learning teams usually lead it, often with an implementation partner, because the catalog, integrations and reporting touch several owners at once. If your renewal, data residency requirement or lock-in concern is driving the decision, start by listing which of these four parts your academy actually depends on, since that list sets the scope.
Content is the most predictable part. Docebo accepts SCORM 1.2, SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages as ZIP files of up to 2 GB, according to Docebo's system requirements and limitations page. Keep the original packages from your authoring tools, because they can be reloaded rather than rebuilt from scratch. Open edX Studio is where courses are restructured into Open edX course runs, so confirm early which packaged modules can be imported as-is and which need re-authoring, especially interactive content that depends on Docebo-specific player features. Inventory this before estimating anything else.
The hardest work sits in identity, commerce and reporting, and it is where the risk concentrates. Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI for third-party authentication, so map each external audience to one of these before cutover, and check how partner and reseller accounts are provisioned today. Docebo's e-commerce and enrollment automation have no one-to-one equivalent, so decide who will own payment, invoicing and certificate issuance. Finally, learner history must be exported through Docebo's APIs and loaded into your new system, and Aspects analytics in Open edX relies on xAPI statements, so validate the reporting design before you commit to a cutover date.
Which Docebo capabilities map to Open edX and which need rework
This table maps the Docebo capabilities used for customer and partner education to their Open edX equivalents. Each row is marked clean, needs rework or gap, so you can see which items move across as they are and which need design, build or a confirmed deployment choice. Treat the marks as a starting point and verify each row against your chosen Open edX deployment before you commit to a timeline.
| Docebo capability | Open edX equivalent | Status |
|---|---|---|
| SCORM 1.2 and SCORM 2004 3rd edition packages | LMS delivery of packages authored in Studio or imported from existing SCORM files | Needs rework: test each package in a staging LMS before cutover |
| AICC and xAPI (Tin Can 1.0) packages | Package delivery requires confirmation against your deployment; xAPI events route to Aspects analytics | Needs rework: confirm AICC support and xAPI event mapping for each package |
| ZIP upload up to 2 GB per package | Upload limits depend on hosting and storage configuration | Needs rework: confirm limits with your provider or Tutor settings |
| Course catalog and course authoring | Studio authoring with course runs and sections | Needs rework: rebuild catalog structure, metadata and course runs |
| Enrollments and learner groups | LMS enrollment with course runs and cohort-style enrollment setup | Needs rework: map enrollment rules and group logic by hand or through the API |
| Completion certificates | Certificate configuration in the LMS, with templates set per course run | Needs rework: rebuild templates and confirm issuance rules |
| Single sign-on for external users | Third-party authentication via OAuth2, SAML 2.0, Shibboleth and LTI | Clean: supported providers exist, but each identity provider needs configuration |
| Content marketplace and AI features | No direct equivalent identified in the supplied materials | Gap: confirm each feature before planning replacement |
| Reporting and learner analytics | Aspects analytics with xAPI statements, ClickHouse storage and Superset dashboards | Needs rework: build dashboards and reports that match current Docebo outputs |
| E-commerce and paid course sales | Depends on the chosen deployment and plugins; confirm payment and checkout options | Gap: verify with your deployment provider before design work starts |
Which content and records move cleanly and which do not
Standard SCORM, AICC and xAPI packages move most cleanly. 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. Because those are packaging standards rather than Docebo-specific formats, the original files from your authoring tools can usually be re-uploaded to Open edX rather than rebuilt. Before you rely on that, check each package's size against the 2 GB limit, since a file that loaded in Docebo is not guaranteed to fit your new hosting's upload and storage settings. Keep the original source files, not only the exported packages, so you can re-publish if a load test fails.
Completion history, enrollments and learner records do not travel inside the course package. Pull users, enrollments and completion data from Docebo's API as a separate export, map Docebo user identifiers to the accounts you will create in the Open edX LMS, and decide whether historical scores and certificate dates must be preserved for audit. Open edX Studio is the authoring path for any course you rebuild, and a package that was built for a particular runtime may depend on the content type, so treat package reuse as a case-by-case decision. Run a pilot load test with one representative package per content type, confirm that progress tracking, scores and completion events are recorded in the Open edX LMS, and check that the result matches the Docebo export. Confirm these behaviors with your Open edX provider or in your own test environment before committing the full catalog.
Data to export and integrations to rebuild from Docebo
Migrating from Docebo to Open edX involves four kinds of data: content, people, learning activity and the services around them. Each one follows a different export path and needs a different rebuild on the Open edX side, so plan them as separate workstreams.
Original course packages
Docebo accepts SCORM 1.2, SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages as ZIP files of up to 2 GB. Keep the original files from your authoring tools rather than relying on Docebo copies, since those are the packages you will import or re-publish. Check that each package launches in a standalone test player before loading it into Open edX Studio, because Open edX has its own handling of SCORM and xAPI content and some packages need adjustment. Confirm each package's version and size inventory early.
User accounts and identity links
Export the user list from Docebo with the fields you need to match learners in Open edX, typically a stable email or external ID. Decide whether Open edX accounts are created by bulk import or by first login through your identity provider. Map each Docebo user to one Open edX identity so that enrollments and certificates attach to the right person. Confirm with the client how duplicate accounts, deactivated users and external customer or partner domains are handled before any data moves.
Enrollments and completions via the API
Enrollment status, completion dates and scores are pulled through Docebo's API services, not from course packages. Page through results in batches and watch for rate limits, which tend to surface on large learner populations. The exact API surfaces, paging behavior and rate limits must be confirmed in the client's Docebo tenant before the export is scripted. Store the raw exports, since they are the only evidence of historical completions for audit or customer disputes.
Certificates and e-commerce
Docebo-issued certificates, certificate templates and any paid enrollment records do not carry over as working objects. Export a list of certificates issued, with recipient, course and issue date, and decide whether to reissue them, keep them as archived records or link to a verification page. Open edX has its own certificate and e-commerce configuration, so rebuild pricing, checkout and tax handling deliberately, and confirm with the business which payment provider and invoicing process will replace the Docebo flow.
External reporting and data feeds
Dashboards, scheduled reports and downstream feeds that read from Docebo often break silently after cutover. Inventory every consumer, including BI tools, CRM syncs and partner reports, and decide which move to Open edX tracking data. Open edX Aspects captures tracking logs as xAPI statements and presents them in Superset dashboards, but it is a separate deployment with its own sizing. Confirm with the client what reporting must exist on day one and what can be rebuilt afterward.
SSO for external users
Customer and partner learners often sign in with their own company accounts or social logins, not with corporate directory accounts. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI. Identify which external identity providers your learners use, confirm which protocol each one supports, and test sign-in for each audience before cutover. Plan how to handle learners who currently use a Docebo password rather than federated login, since those passwords cannot be exported.
Migration sequence from inventory to decommission
This sequence moves Docebo customer and partner academies to Open edX in controlled stages, so each audience is verified on the new platform before its access and records are switched over. It ends with Docebo retired and an archived copy of everything you need to keep.
Inventory courses, audiences, integrations and commerce
Your team lists every course, learning path, audience group, certificate template, SSO connection, API consumer and payment flow in Docebo. For each course, record whether you hold the original SCORM, AICC or xAPI package, since Docebo accepts those formats and the packages can be reloaded into Open edX Studio. Identify which items are stored only inside Docebo, such as quizzes built in its editor, so they can be rebuilt. The step is done when every item has an owner and a target: reuse the package, rebuild in Studio, or retire it.
Pilot one academy on Tutor or a managed provider
Choose one customer or partner academy with a small catalog and deploy Open edX for it, either with Tutor on Docker or Kubernetes or through a managed Open edX provider. The maintainers recommend a service provider or Tutor for production, so avoid a bare-metal build unless you have the staff to support it. Load the pilot courses into Studio, configure identity and certificates, and have a small group of real learners complete them. The pilot is complete when learners finish a course end to end and the certificate and completion data match what Docebo produced for the same content.
Run Docebo and Open edX in parallel
Keep Docebo live for all audiences while the remaining academies are built on Open edX. Migrate learner records in a scripted run through the Docebo API, then compare user counts, enrollments and completion dates against the source for each audience. Agree with the business owner which platform is the system of record for enrollments during this period, so no learner is enrolled in both places without notice. The step closes when reconciliation reports show no unexplained differences for each migrated audience.
Cut over audiences in waves
Move one audience at a time. For each wave, freeze new enrollments in Docebo for that group, run a final incremental export, point the academy's public address to Open edX through a DNS change, and switch the login path to the new identity configuration. Tell the audience in advance which address and sign-in method to use, and keep Docebo read-only for that group until the wave is accepted. A wave is accepted when its learners can sign in, launch courses, and receive certificates, and the owner signs off.
Decommission Docebo with archived exports
After the last wave is accepted and the agreed retention period for historical records has been confirmed with your legal and compliance teams, export the remaining learner records, completion history, certificates and original packages from Docebo. Store them in your own encrypted archive with an index of what each file contains. Confirm with Docebo how and when your subscription and data will be closed, then revoke API credentials and integrations. The step is done when the archive has been restored and spot-checked and the subscription is closed in writing.
What drives cost and duration in this migration
This table lists the main factors that raise or lower the effort of moving Docebo customer and partner academies to Open edX, with the reason each one matters and how to keep it under control. Use it to see which items your own inventory will decide, then ask each vendor or implementer to price those items separately in a written scope.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of courses and package types | Each SCORM 1.2, SCORM 2004, AICC or xAPI package must be uploaded, tested and launched in Open edX Studio. Native Open edX course structures and interactive content formats can need rework. | Inventory every package by type and size before scoping. Retire inactive courses, and rebuild only the courses that still have active learners. |
| Volume of learner history | Completion records, scores and enrollments must be pulled through the Docebo API, mapped to Open edX learner identifiers and loaded in a controlled order. Paging and rate limits lengthen extraction runs. | Agree a retention cut-off with compliance owners. Migrate active enrollments and recent completions, and archive older records as exported files. |
| Number of external audiences and sites | Customers, partners and resellers may need separate branding, catalogs and reporting. Each audience adds configuration, content visibility rules and testing. | Group audiences by shared catalog and branding. Ask for a site and audience count in the quote so the scope is fixed before build starts. |
| Identity integration complexity | External users often sign in through their own identity providers. Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, so each provider needs attribute mapping and login testing. | List every identity provider, protocol and attribute set in advance. Confirm which providers your Open edX hosting path supports before committing to a design. |
| E-commerce and certificate rebuild | Docebo storefront, pricing, invoicing and certificate templates do not transfer directly. Open edX payment, enrollment and certificate configuration must be designed, tested and reconciled with finance. | Document current price rules, tax handling and certificate wording. Decide which certificates must match prior versions and which can be reissued. |
| Reporting requirements | Dashboards, completion reports and xAPI-based analytics need to match what business owners use today. Open edX Aspects uses ClickHouse, Superset and an event routing layer, which adds components to design and run. | List the reports used in the last quarter and their owners. Remove unused reports from scope and confirm data retention for analytics. |
| Open edX hosting choice | Tutor on Docker or Kubernetes means your team or implementer operates the stack, including upgrades. A managed Open edX provider shifts hosting and operations to the provider under its own terms. | Compare run responsibilities, upgrade cadence and support terms side by side. Ask each option to state who patches the platform and who restores backups. |
| Testing and cutover | Learners, instructors and external admins need acceptance testing on migrated content, records and sign-in paths before a switch. Parallel running may extend the period both platforms are maintained. | Define acceptance criteria per audience. Ask for test environments and a written cutover and rollback plan in the quote. |
How the move differs by academy size and starting point
A single customer-facing academy usually maps to one Open edX installation with one LMS and one Studio instance. The main work is rebuilding a modest catalog in Studio, reloading packaged SCORM, AICC or xAPI content and deciding how learners sign in. Because there is one brand and one audience, you rarely need multi-site configuration, and reporting can start from the standard LMS data before you add Aspects.
- Multi-site setup: Usually not needed. Confirm that your branding, domain and certificate templates fit one site before you add complexity.
- Identity federation: Often a single OAuth2 or SAML 2.0 connection to your customer identity provider, or local accounts for a small group.
- Reporting: Standard LMS progress and certificate data may be enough at first. Add Aspects if you need xAPI-based analytics.
- Content reload: Reload original packages and test each one in a staging course run before you publish.
- Certificates and e-commerce: Rebuild certificate templates and decide on payment handling early, since these are separate from the course build.
Before you start, ask your team which learner records must move, and confirm with DeployOpen's written scope how Docebo API exports will be handled.
When you run separate academies for resellers, partners or distributors, each audience usually needs its own branding, enrollment rules and reporting view. In Open edX this is typically handled with a multi-site configuration, so each academy has its own domain, theme and course set while sharing one platform. The decisions here are architectural, so make them before building courses.
- Multi-site setup: Map each partner academy to a site with its own domain, theme and organization. Decide early which content is shared and which is partner-specific.
- Identity federation: Partner users often sit in different identity providers. Plan one federation connection per partner where the partner supports SAML 2.0 or OAuth2, and confirm which providers your version supports.
- Reporting: Decide whether each partner sees only its own learners. Aspects dashboards may need separate filtering or access rules, which you should confirm in a proof of concept.
- Enrollment and access: Migrate partner-specific enrollments from Docebo and check that each learner lands on the correct site.
- Certificates: Issue partner-branded certificates from each site's templates.
Illustrative example: three reseller academies with different sign-in providers would need three federation setups and three sets of reporting rules, even if they share one course library.
A large catalog serving several audiences, such as customers, partners and internal staff, adds volume and dependency risk. The number of packages, learner records and integrations grows the migration effort more than the number of academies does. Plan migration in waves by audience and content family so you can test reporting and access before moving everything.
- Multi-site setup: Group courses into sites by audience. Keep shared libraries in one place to avoid duplicate maintenance.
- Identity federation: Test every sign-in path, including Docebo SSO connections you are replacing, before cutover.
- Reporting: Validate completion counts per site against Docebo exports. Large volumes make manual checks unreliable, so script comparisons where possible.
- Content reload: Check package sizes and formats. Docebo accepts packages of up to 2 GB, so confirm that your largest packages load in your new environment.
- Operations: Plan hosting capacity, backups and upgrades for the number of learners and sites. Open edX supports only its latest named release, so budget time for upgrades.
Illustrative example: a catalog with several thousand packages would need a wave plan, a reconciliation report per wave and a rollback path for each audience. Ask for those items in any written scope.
What usually goes wrong and how to prevent it
Most failed Docebo to Open edX migrations are not caused by the course content itself. They come from learner history, identity, certificates, commerce and the platform's own release and hosting demands being planned late. Each card below names one risk and the check to run before cutover.
Learner history lost in package reload
Reloading SCORM, AICC or xAPI packages restores the course content, but not the attempts, scores and completion dates learners already earned in Docebo. Those records must be exported separately and mapped to Open edX enrollments. Before cutover, pick a sample of learners with partial progress and confirm their history appears in the target system. Ask whether any content depends on Docebo-hosted tracking that a package reload cannot replay.
Identity mismatch for external users
Customer and partner learners often have accounts tied to a Docebo login, a company domain or an external identity provider. If usernames, email addresses or identifiers do not match during import, learners either lose access or appear as duplicate accounts. Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, so agree the identity provider and matching key before loading users. Test a login from each external organization.
Certificates not matching issued history
Certificates already issued by Docebo carry dates, course names and identifiers that a new Open edX certificate configuration may not reproduce. Partners may rely on those credentials for their own compliance or contract records. Decide whether historical certificates are re-issued, kept as archived documents or linked from the new platform, and verify the verification method with the business owner. Do not assume new certificates will replace old ones without that agreement.
Commerce gaps found late
Docebo-based academies often sell courses, apply coupons or invoice partners. Open edX Studio and the LMS do not replace a storefront on their own, so payment, tax, invoicing and refund flows must be designed and tested as separate work. Map every sold product, price rule and invoice format from the current system, then confirm which gateway and e-commerce component will handle them. Commerce that is discovered after cutover usually delays revenue.
Open edX release support window
Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026, with Willow and Xylon listed for December 2026 and June 2027. Plan an upgrade path and a named owner for each upgrade, because a deployment left on an older release falls outside community support. Confirm with your provider which release they will maintain.
Under-sized self-hosted infrastructure
Open edX development requires Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached, and multi-node deployments need a shared cache such as Redis or Memcached. The maintainers recommend production through a service provider or with Tutor, because bare-metal installation is complex and receives limited community support. Size the database, cache, storage and load-balancing layer from expected concurrent learners, and get a written hosting, backup and patching plan before go-live.
Questions buyers ask before moving from Docebo to Open edX
What does a Docebo to Open edX migration cost and what drives the price?
The cost depends on the volume and type of content, how many learner records you must carry over, and how much integration work sits around the platform. Open edX itself has no licensing fees, so the spend falls on hosting, storage for course packages, implementation, integration, testing and ongoing operations. Hosting and support are recurring costs, while course rebuilding, data export, certificate and e-commerce replacement, and security testing are mostly one-time. Ask any implementation partner for a quote built from a written scope that lists catalog size, package count, learner volume, integrations and the environments you need. Ask whether the quote separates one-time migration work from recurring operations so the two can be compared with your current Docebo subscription.
How long does it take to move from Docebo to Open edX?
The timeline depends mainly on how many courses must be rebuilt in Open edX Studio, how many packages can be reused as they are, and how many learner histories must be exported and mapped. A catalog with mostly standard SCORM packages moves faster than one that needs new course structure, custom assessments or redesigned certificates. Plan a parallel run for at least one academy or audience before cutting over, so customers and partners are not disrupted. Your implementation partner should state the phases, dependencies and acceptance criteria in the written scope before work starts, and the schedule should follow from that scope rather than a general estimate.
What does our team need to provide for the migration?
Your team needs to supply access to the Docebo environment, an inventory of courses and their original packages, and the list of audiences, sites and roles that will exist in the new academy. Someone must own business decisions on course design, certificate wording, pricing and branding, and someone must approve test results. You also need access to the identity provider and any CRM, billing or HR systems that feed enrollments. Docebo accepts SCORM 1.2 and SCORM 2004 3rd edition, AICC and xAPI (Tin Can 1.0) packages as ZIP files of up to 2 GB, so confirm that every package in your library falls within those formats and limits before you commit to reuse.
Can our own team migrate from Docebo to Open edX without a partner?
A capable in-house team can migrate, but the work is more involved than a standard LMS setup. The maintainers of edx-platform recommend running Open edX in production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Open edX also needs MySQL 8.0, MongoDB 7.x, Memcached and Python 3.12 for development, and multi-node deployments need a shared Django cache backend such as Redis or Memcached. Assess whether your team already runs Kubernetes or Docker, has Python and Django experience, and can own upgrades. If not, a fixed-scope engagement with DeployOpen covers planning, implementation, integration, hardening, backup and documentation inside your own infrastructure.
Does learner history and completion data move to Open edX?
Learner history does not move automatically. Original course packages can be reloaded, but completion history, enrollments and learner records must be exported from Docebo and mapped into Open edX separately. Docebo's Report and Learn API services are the usual route for pulling users, enrollments and completions, and they include paging and rate limits that shape the export schedule. Decide early which history you must keep for compliance or customer records, because older attempts and certificates may need to be stored as archived data rather than recreated. Ask your partner how they will verify record counts and spot-check individual learners after each import.
Does selling courses work in Open edX after moving from Docebo?
Selling courses is a feature you must plan and build, not a switch to turn on. Docebo's e-commerce, enrollment automation and content marketplace features do not have a direct one-to-one replacement, so you need to decide how payments, invoices, refunds, tax handling and course access will work in the new academy. Open edX provides the course and enrollment foundation, and the commerce layer is typically added through configuration or integration with a payment provider. Confirm payment processor requirements, the data you must keep for finance, and any PCI-related obligations with your team and your processor before you choose a design.
How is Open edX supported after the migration is complete?
Open edX is stewarded by Axim Collaborative, a nonprofit founded by Harvard and MIT, and the project has no licensing fees. Support options include the community, a managed Open edX provider, a Tutor-based deployment with professional support from Edly, or a retainer with an implementation partner. The Open edX project states that the latest named release is the only supported release, so you must plan upgrades on a regular cycle. The current named release is Verawood, and the next releases are listed as Willow and Xylon. Ask any provider which release they will run, how they handle upgrades and security patches, and what response commitments they will put in writing.
Which single sign-on and authentication options does Open edX support?
Open edX third-party authentication supports OAuth2 providers, including Google, Facebook, LinkedIn and Azure Active Directory by default, along with SAML 2.0, Shibboleth and LTI. Older provisional support exists for CAS and SSL client certificates. For customer and partner academies, confirm which identity provider your external users already rely on and whether it uses SAML 2.0 or OAuth2. Test sign-in for each audience, including account linking for learners who already hold accounts, before you cut over the academy.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Docebo to Open edX, we start with a written scope that separates course rebuilds, content reuse, learner record migration and e-commerce replacement so each piece can be checked on its own.
How we scope
- Inventory courses, audiences, customer and partner academies, and the Docebo features your teams use today.
- Decide which SCORM, AICC and xAPI packages are reloaded into Open edX Studio and which are rebuilt.
- Agree in writing how learner records, completions and certificates will be exported and reconciled.
- Confirm identity provider needs, including SSO for external learners, and the e-commerce replacement before work starts.
How we build
- Deploy Open edX in your environment, with Tutor or another method your operations team can run.
- Configure Studio, course runs, enrollment rules, certificates and single sign-on to match the agreed scope.
- Script the Docebo API extraction and load routines, then test them against a sample of learner data first.
- Verify package playback, scoring and completion behavior in staging before any learner-facing cutover.
How we hand over
- Deliver runbooks for deployment, backups, upgrades, course authoring and learner support.
- Document the data mapping, reconciliation results and any records that could not be migrated.
- Walk your administrators and course authors through Studio, the instructor dashboard and reporting setup.
- Record which controls and evidence your compliance team will need for its own assessment.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for a quote built from the written scope, and confirm which items fall under the retainer.
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
