Moving to Moodle from Canvas or Blackboard: what migrates

Moving from Canvas, Blackboard or Brightspace to Moodle 5.x: which export formats Moodle reads, what gets lost, how users move, and a migration plan that works.

Drawing of a person pushing a wheelbarrow of boxes across a plank bridge over a gap, with some boxes falling in. One box is blue.

Course content migrates to Moodle, roughly. People and their history do not. Moodle 5.3 imports IMS Common Cartridge 1.0 and 1.1 and nothing newer, it has no Blackboard course importer at all, and no LMS export carries student submissions, grade history or discussion posts in a form Moodle will read. Pages, files, links and simple quizzes come across. Rubrics, complex quiz settings, LTI tool setups and every integration you built around the old system have to be rebuilt.

So plan the migration as two projects: move the content, which is mostly mechanical, and rebuild everything that connects the LMS to the rest of your institution, which is not.

If you are moving because of what happened to your vendor, that story is in Moodle vs other LMSs in 2026 (the section on what happened to the paid vendors). This post is about the move itself.

What can Moodle 5.x import?

Less than people expect. Here is what a current Moodle reads from another LMS:

InputMoodle 5.3 supportNotes
IMS Common Cartridge 1.0Yes, course restoreDetected and converted on restore
IMS Common Cartridge 1.1Yes, course restoreThe most useful format for migration
Common Cartridge 1.2, 1.3, Thin CCNoRequested in MDL-60803, not in core
Blackboard course archive or course packageNoNot in core since Moodle 2.0
Blackboard question pools (.dat or .zip)Yes, question importThe “Blackboard” question format
Moodle XML, GIFT, Aiken questionsYes, question importMoodle XML keeps the most data
Users and enrolments (CSV)Yes, Upload usersManual enrolment only
Grades (CSV, XML, pasted)Yes, grade importValues only, mapped onto grade items

The Common Cartridge limit comes straight from MoodleDocs: “Moodle currently only supports the import of IMS CC version 1.0 and 1.1 packages.”1 The 5.3 code agrees. Moodle’s backup converters are imscc1, imscc11 and moodle1 (the last is for Moodle 1.9 backups), and the 1.1 converter checks the manifest for the exact 1.1 namespace before it accepts a file.2 A 1.3 cartridge is not “partly supported”. It is not recognised.

On Blackboard, the MoodleDocs “Blackboard migration” page for 5.3 still describes Moodle 1.9 and 2.x tools and is marked as needing an update.3 The one Blackboard-specific thing left in core is the question import format, which takes “questions saved in all Blackboard export formats” as a .dat or .zip file.4

What does Canvas export?

A Canvas course export is an .imscc file (a Common Cartridge zip). Instructure’s guide says all course content is included except student interactions and grades, which you export separately as CSV, and that some LTI tools such as Google Drive and Microsoft 365 lose their configuration. Exports over 20 GB fail, and finished exports expire after 30 days.5

The useful detail is in the open source Canvas code: the exporter writes a Common Cartridge 1.1 manifest by default, and 1.3 only when asked.6 That is why a plain Canvas export usually restores in Moodle without complaint.

What it restores into is another matter. Canvas puts its own data in its own namespace inside the cartridge: course settings, assignment groups, grading standards, rubrics in rubrics.xml, module rules and so on.6 Moodle’s Common Cartridge importer only knows forums, labels, quizzes, web resources and LTI links.2 Everything Canvas-specific is skipped.

What does Blackboard export?

It depends which Blackboard you mean.

Learn Original can export a Common Cartridge in version 1.0, 1.1 or 1.2. Pick 1.1, because Moodle won’t read 1.2. Blackboard’s own documentation lists the losses:7

  • Discussion forums export, but threads do not.
  • Surveys are not exported.
  • Assignments export “in a limited format”, content only.
  • Multiple choice loses partial credit. Fill in the blank keeps only the first answer.
  • Incompatible questions are dropped. So are random blocks, question sets, file attachments on questions and instructor notes.
  • Item attachments are lost unless they live in Course Files.

Ultra is the problem. University help pages describe exporting an Ultra course as a Blackboard course package, which only Blackboard reads.8 We could not find an official Blackboard page that documents a Common Cartridge export for Ultra courses, and the Blackboard help pages we tried now redirect to Anthology’s new help site. Check what your own Ultra tenant offers before you plan around it. If it is course packages only, you need either a converter or a manual rebuild.

What does Brightspace export?

D2L lists Common Cartridge 1.0 to 1.3 and Thin Common Cartridge 1.3 as supported versions.9 University guides describe the Import/Export/Copy Components tool exporting either a Brightspace package or Common Cartridge 1.3, with Thin CC as a variant that only carries links, LTI tools and metadata.10 We could not load D2L’s own export page to confirm the version, so treat this as second-hand.

If it holds, it is the Brightspace trap: the obvious export is a 1.3 cartridge, and Moodle 5.3 will not open it. Something has to rewrite the manifest to 1.1 and drop what 1.1 cannot hold, or someone rebuilds the course.

What usually doesn’t survive?

This list is ours, built from the documented limits above. Expect to rebuild or re-check all of it:

  • Student work and history. Submissions, attempts, feedback, forum posts and grade history. Canvas says so outright,5 and Blackboard’s Common Cartridge export is content only; it does not even include discussion threads.7 Keep the old system read-only, or archive it, for appeals and accreditation.
  • Gradebook structure. Categories, weights, drop rules and late policies live in vendor-specific files. Moodle can import grades from CSV, XML or a pasted spreadsheet, but it works like manual grading: you map columns onto grade items, and weights, categories and history do not come with it.11
  • Quizzes beyond the basics. Moodle lists quiz support in Common Cartridge as partial.1 Simple multiple choice and true/false usually come through. Partial credit, formula questions, random selection from pools and per-question settings often do not. Moving question banks separately (Blackboard pools through the Blackboard format, or a conversion to Moodle XML) gives better results than relying on the cartridge.
  • Rubrics and outcomes. Vendor extensions, so dropped. Moodle has its own rubric and competency tools; you rebuild them there.
  • LTI tools. A cartridge can carry an LTI link, but not the tool’s registration with your new platform. Every LTI 1.3 tool (publisher content, proctoring, video, plagiarism checking) needs setting up again on the Moodle side, and check whether your contract with each vendor covers a new platform.
  • Embedded links. Links between pages and to files are rewritten by the old LMS on export and often point back to the old system after import. Search the restored courses for the old hostname.
  • Integrations. SIS sync, single sign-on, the reports your registrar runs, the plugin in the old LMS that one department can’t live without. None of that is in any export.

How do users and enrolments move?

Separately from content, and usually from your source systems, not from the old LMS.

  • Accounts. Moodle 5.3 core has authentication plugins for LDAP, OAuth 2 (Microsoft, Google and other OpenID Connect providers), Shibboleth and an external database.12 SAML is not in core; the usual choice is the contributed auth_saml2 plugin.13 If your old LMS already used SSO, point Moodle at the same identity provider and users keep their logins.
  • One-off loads. Upload users takes a CSV with username, first name, last name and email, an auth column for the login method, and course1, role1, group1 columns to enrol people. It only uses manual enrolment.14 Fine for the first load or a small site.
  • Ongoing sync. For a university, enrolments should come from the student information system every term, not from a spreadsheet. Core gives you an external database enrolment plugin, flat file, IMS Enterprise and LDAP enrolment, plus the web services API.12 If your SIS can write to a table Moodle reads, the database plugin is often enough. If it can only talk through its own API, someone writes the glue.

What does a realistic migration plan look like?

Our rule of thumb: a whole institution moves in one academic year, not one summer. The order that works:

  1. Inventory. List every course, who owns it, when it last ran, and which tools it uses (LTI tools, publisher content, special quiz types, rubrics). Archive courses that haven’t run in two years instead of moving them. List every integration too: SIS, SSO, reporting, library, video, plagiarism.
  2. Build Moodle first. Hosting, SSO and SIS enrolment sync before any course moves. The hosting side is covered in how to host and deploy Moodle in 2026, and the version requirements in Moodle 4.5 to 5.3: what changed. Start on 5.3 LTS.
  3. Pilot ten or so courses. Pick a mix: a plain text-and-files course, a quiz-heavy one, one with lots of LTI tools, one from each faculty. Export, restore, and have the teacher check it. This is where you learn what your exports actually lose.
  4. Decide per course type: import, convert or rebuild. Simple courses import. Courses with large question banks get their questions moved separately. Courses that lose too much get rebuilt by hand, which is also the chance to drop five years of dead links.
  5. Clean up. Fix broken links, re-create rubrics and gradebook setup, re-add LTI tools, check accessibility. Our view: budget more time for this than for the import itself.
  6. Run both systems in parallel for a term. New courses go on Moodle, old ones finish where they started. Nobody switches LMS mid-course.
  7. Cut over at a term boundary. Then set the old LMS to read-only for as long as your records policy and your contract allow, and export what you must keep (grade CSVs, reports) before the contract ends.

Where does custom code come in?

Three places, and each one is a normal Moodle plugin:

  • SIS integration. When the database enrolment plugin doesn’t fit, a local plugin or scheduled task that reads your SIS API and creates courses, users, groups and enrolments, and sends final grades back.
  • A feature the old LMS had. An attendance rule, a grading workflow, a report, a block a department relied on. Moodle has plugin types for activities, question types, reports, blocks, enrolment and authentication, so most gaps can be filled in days, not months.
  • A converter. If you have hundreds of Brightspace 1.3 cartridges, Ultra course packages or Canvas question banks the importer mangles, a script that turns them into Moodle backups or Moodle XML is cheaper than rebuilding by hand. The output is a Moodle format you control, so it works across upgrades.

That is the work we do. If your migration needs one of these, a Moodle developer can scope it before you commit to a cutover date.

Sources

  1. MoodleDocs, IMS Common Cartridge import and export (5.3). ↑ ↑

  2. GitHub, moodle/moodle MOODLE_503_STABLE, public/backup/converter and public/backup/cc, checked 31 October 2026. ↑ ↑

  3. MoodleDocs, Blackboard migration (5.3). ↑

  4. GitHub, moodle/moodle MOODLE_503_STABLE, qformat_blackboard_six language strings; MoodleDocs, Import questions (5.3). ↑

  5. Instructure Community, How do I export a Canvas course?, checked 31 October 2026. ↑ ↑

  6. GitHub, instructure/canvas-lms, lib/cc/manifest.rb and lib/cc/cc_helper.rb, checked 31 October 2026. ↑ ↑

  7. Blackboard, Common Cartridge Course Packages. ↑ ↑

  8. Grand Valley State University, Export Courses in Ultra; Humber College, Exporting or archiving a course in Ultra. ↑

  9. D2L Brightspace documentation (mirrored by South Dakota Board of Regents), IMS Common Cartridge versions. ↑

  10. Pima Community College, Exporting a D2L course; Texas Christian University, Export Course Components. ↑

  11. MoodleDocs, Grade import (5.3). ↑

  12. GitHub, moodle/moodle MOODLE_503_STABLE, public/auth and public/enrol, checked 31 October 2026. ↑ ↑

  13. Moodle plugins directory, SAML2 Single sign on (auth_saml2). ↑

  14. MoodleDocs, Upload users (5.3). ↑

Need a Moodle plugin built or rescued?

Tell the scoping assistant what you need. You get a fixed price and a timeline in a few minutes, and an engineer reviews it within one business day.

Get a fixed quote