Moodle's .mbz backup format only restores into another Moodle site, it isn't a general-purpose export. Moving to a different platform means extracting SCORM content and files separately, and pulling gradebook and completion data as CSV rather than relying on a single backup file to carry everything across.
Usually one of three things. Self-hosted Moodle carries real IT overhead, someone has to patch it, host it, and manage plugin compatibility across upgrades, and that burden grows with scale. Some teams want a more modern learner-facing interface than Moodle's default theme provides out of the box. And some organizations outgrow what Moodle's plugin ecosystem covers for a specific use case, a branded academy, a partner training portal, or a continuing-education program with its own compliance requirements. None of that is a knock on Moodle, which remains genuinely strong for institutional and open-source use cases; it's a mismatch between what the platform was built for and where the organization has ended up.
A Moodle course backup (.mbz) is a complete, self-contained archive, but it's built to restore into another Moodle installation, not to be read by a different LMS. Treating it as a universal export is the most common mistake in a Moodle migration: it isn't one. The content that does travel cleanly is anything built to open standards inside Moodle, primarily SCORM 1.2 and SCORM 2004 packages, which Moodle stores as portable activity types that can be extracted and uploaded almost anywhere. Course files themselves (documents, videos, images) can also be pulled via Moodle's "download course content" option as a plain file archive.
Content built with Moodle-native activity types, a Moodle Quiz, a Book resource, a Lesson activity with branching, doesn't have an equivalent format outside Moodle. Those get rebuilt in the new platform's native tools. Gradebook structure is similar: custom grade items, weighted categories, and completion rules configured inside Moodle are exported as CSV data, but the rules and logic behind them typically need to be reconfigured natively in the destination platform rather than imported as a working system.
For a straightforward course catalog, a few hundred courses, mostly SCORM content, no heavy custom plugin dependencies, 4 to 8 weeks from audit to cutover is realistic. Instances with extensive custom plugins, multi-tenant configurations, or years of gradebook customization take longer, because that custom logic has to be rebuilt natively, not because the file migration itself is slow.
Moving specifically to LearnWorlds? Our guide to migrating to LearnWorlds covers that platform pairing in more detail, including Moodle as one of the source platforms.
Book a 20-minute call and walk through your course catalog. We'll tell you honestly what transfers cleanly and what needs a rebuild.
Book Your 20-Min Discovery Call →