How to Migrate Off Moodle Without Losing Course Data

Start with the plugins, not the courses

You rarely lose Moodle data because an export failed. You lose it because you exported before you understood which of your plugins was quietly holding a business rule together. Audit those first, then move the content.

Here's the trap. Moodle backs a course up into an .mbz file, and that file is genuinely good at carrying the things you can see: activities, resources, the course structure, question banks. What it doesn't carry is the behaviour a plugin added on top. A custom enrolment plugin that grants access when someone pays. A grading plugin that changes how a total is calculated. Those don't travel in the backup. They travel in your memory, until the day they don't.

Inventory before you export a single course

On one Moodle install I picked apart before a rebuild, the site had fourteen active plugins. Twelve were cosmetic or convenience. Two were load-bearing: one decided cohort access, one adjusted a competency calculation the compliance team relied on. Nobody had written that down. If we'd led with a course export, we'd have moved the courses and lost the two rules that actually mattered.

So the first pass is a spreadsheet, not a download button.

Moodle's own documentation is blunt about the fragile part: it tells administrators to select plugins for a specific Moodle version and to test upgrades outside production first. If a plugin can break on an upgrade of the same platform, assume it will not survive a move to a different one. (Moodle's plugin and upgrade guidance)

Move one difficult course before you promise a timeline

Pick your worst course. Not the tidy demo one, the real one with a weird grading scheme, a SCORM package, and an external tool. Migrate that end to end and see what breaks. A sample of one hard course tells you more about the schedule than a full content export ever will.

Then be honest about what shouldn't come. Most Moodle installs I've seen carry years of dead courses nobody will open again. Those belong in an archive you can search, not in the new platform's data model. Migration is a good moment to stop paying to carry things you've already stopped using.

Where a clean rebuild changes the shape of this

If the plan is a custom platform rather than another Moodle, the two load-bearing plugins stop being risks and become part of the spec. The cohort-access rule and the competency calculation get written down, built on purpose, and tested. That's the real argument for a custom Moodle alternative: not that Moodle is bad, but that the rules you've been keeping in plugins and memory finally get to live in code you own.

For the standards work underneath a move, read SCORM vs xAPI. For the shape of the whole cutover, see what a smooth LMS migration actually looks like. And if you're weighing whether to rebuild at all, custom LMS development starts with exactly this kind of inventory.