Migrating off Moodle: what actually breaks
Twenty migrations in, here is the honest inventory — what the importer handles, what needs a human decision, and the one thing that always has to be rebuilt.
Every vendor’s migration page says the same thing, which is that migration is easy. It is not easy. It is predictable, which is better, because predictable means you can plan for it.
Here is what twenty migrations have taught us, in the order the problems actually arrive.
Course structure moves cleanly, and this misleads everybody
Sections, files, labels, page resources, folder structures — these come across without a decision from anyone. Stage one of a migration always goes well, and the danger is that a steering group sees a clean import of three courses and revises the timeline down.
Do not revise the timeline down. The easy 80% is genuinely easy and genuinely fast. It is the remaining 20% that determines whether your instructors trust the new system in October.
Quizzes move, but the question types do not all survive
Multiple choice, true/false, short answer, numerical, matching and essay all map directly. What does not map cleanly:
- Calculated questions with datasets. The question moves; the dataset needs to be regenerated and re-checked, because the random seed does not carry over and neither does the tolerance handling.
- Drag-and-drop onto an image. These map to a QTI equivalent, but coordinates are relative in one system and absolute in the other. Every one needs a human to look at it.
- Anything from a third-party question plugin. If the question type was added by a plugin, it exists nowhere in the standard and there is no honest way to translate it.
The rule we give people: budget one hour per hundred questions for review, and pull that hour from someone who teaches the module, not from IT.
Grades: the argument is about history, not data
Moving current-year grades is a technical problem and a solved one. Moving five years of historical grades is a policy problem wearing a technical costume, and it will consume more meetings than the rest of the migration combined.
The questions that actually need answering:
- Do historical grades need to be queryable, or only retrievable? These have very different costs.
- If a mark was calculated under a grading scheme you no longer use, does recomputing it in the new system count as changing it?
- Who signs off that the migrated number matches the original — and against what source of truth?
Our advice, unpopular but consistent: keep the old system in read-only mode for one full academic year, migrate current and previous year only, and let the archive question be answered separately by whoever owns records retention. Migrations that try to solve records retention on the way through do not finish.
The thing that always gets rebuilt
Content built in a proprietary page builder. Every LMS has one, they are all pleasant to use, and none of them export to anything meaningful. What comes out is either a flat HTML blob with the interactivity stripped, or a proprietary archive only that vendor can read.
This is not a technical failure on anyone’s part. It is the intended behaviour of the format, and it is precisely why we have not built one.
If your instructors have three years of page-builder content, that content is new work. Say so at the start, put an hours figure against it, and give people the choice of rebuilding it or replacing it with something standards-based. What you must not do is let it appear as a surprise in week nine.
What we would tell you to do first
Send us the three worst courses. Not the flagship one that was rebuilt last summer — the one with eleven years of accumulated plugins, the one where the instructor retired, and the one with 900 students and a legal obligation attached. Those three tell you the true shape of your migration in about a week.