As a planning figure, expect to rebuild or substantially rework about 20 to 30 percent of a Moodle course library when you move it to WordPress, and more if it leans on SCORM. The number that matters is not how many courses you have. It is how many objects of each type they contain.
When a contractor tiles a bathroom, they never order tiles to cover the exact square footage. They add 10 to 15 percent on top of the measurement. Some tiles crack during cutting. Corners need awkward pieces. A few get dropped. Every experienced tiler factors this in before placing the order. It’s called a breakage allowance, and it’s not pessimism. It’s just how you plan the job.
I’ve seen content migrations stall for the same reason a tiling job runs short: the person planning assumed that everything would transfer cleanly, and when it didn’t, the project fell behind. The budget ran out, the launch date slipped, and the instructional team found itself rebuilding assets it thought were already done.
A Moodle-to-WordPress migration needs a breakage allowance. The question isn’t whether some content will break. It’s how much, and what rebuilding it will cost. For the wider budget picture, including hosting and integrations, see what a Moodle LMS actually costs.
What breaks when you migrate Moodle to WordPress: SCORM, quizzes and the gradebook
Moodle stores course content in a structure that makes sense inside Moodle. Quiz questions connect to gradebook entries. SCORM packages depend on Moodle’s runtime to report completion back to the learner record. H5P activities may render cleanly inside Moodle but behave differently once detached from their original host. Forum discussions tie to enrollment data that has no native equivalent in WordPress.
When you export a Moodle course and bring it into a WordPress LMS, whether that’s LearnDash, LifterLMS, or Tutor LMS, you get back the text and the image files. You get some of the structure. What you don’t get automatically is the interactivity, the conditional access logic, the gradebook integration, or the learner history.
The content types most likely to need significant rework or full rebuilding:
- SCORM and xAPI modules that depend on a Moodle-specific runtime
- Quiz banks with branching logic or adaptive sequencing
- Conditional release rules tied to grade thresholds
- Certificates that pull from Moodle’s custom field set
- Discussion forums where learner history is part of the course design
- Grade calculations that weight activities differently by role or cohort
The types that migrate with minimal friction: video files, PDF resources, static text pages, images, and audio. The simpler the content type, the cleaner the move. The Moodle to WordPress conversion process walks through how user mapping, enrollments and reporting fit around that content.
How to size the allowance before the project starts
The practical way to estimate breakage is by content type, not by total course count. A migration involving 20 courses built mainly around video and PDF resources will have a much lower breakage rate than a migration involving 20 courses dense with embedded quizzes, SCORM modules, and conditional release rules. Counting courses tells you almost nothing useful. Counting objects by type tells you what the project actually is.
Before I scope a migration project, I want a content audit sorted by type: video, document, quiz, SCORM, H5P, forum, assignment, grade item. Each type has a different profile for how cleanly it migrates and what rebuild time looks like when it doesn’t. A SCORM module that needs rebuilding as native WordPress quiz logic might take several hours of careful work per module. A video that needs uploading to a new host and re-embedding might take twenty minutes. Those two numbers come from completely different budget lines.
A rough planning figure for a migration with moderate interactive content: expect to rebuild or substantially rework somewhere between 20 and 30 percent of the material rather than migrate it directly. If SCORM makes up a significant portion of the catalogue, that number goes higher. If the courses are primarily text and static resources, it goes lower. These are calibration figures, not guarantees. They give procurement a defensible starting point rather than a number drawn from optimism.
How to run a Moodle content inventory before you migrate
The most useful thing I do at the start of a migration engagement is build a content inventory. Not a course list. A content inventory: every object type in the catalogue, with a flag on each item noting whether it migrates cleanly, needs rework, or needs rebuilding from scratch.
That one document changes the shape of what follows. It gives procurement something concrete to evaluate against a real budget. The instructional team gets a working list of decisions to make before anyone touches the destination system. The project schedule finally has a foundation built on what’s actually in the catalogue rather than what everyone assumed was there.
Without it, the project runs the same way as the tile contractor who measured the floor, ordered exactly enough, and is now two days behind waiting for a second delivery while the bathroom sits unfinished.
If you’re planning a Moodle-to-WordPress transition and haven’t done this audit yet, that’s the place to start. If you only need the two systems to work together rather than one replacing the other, that is a different project, covered in Moodle WordPress integration: what it actually takes. And for what a finished WordPress LMS looks like, see the M.L. Campbell LearnDash LMS case study. The WordPress consulting work I do typically begins with exactly this kind of inventory, so the scope going into the project reflects what’s actually in it rather than what the course list implied.
Tell me about your project
The fastest way to a straight answer. Tell me what you need and I will reply within a business day, honestly, even when the answer is that I am not the right fit.
Prefer to talk? Call 647-641-0643
Share your project details
Use this form for project scope, technical SEO support, onsite training requests, or a focused next-step conversation.