Moving a Moodle site sounds like it is all about the courses. In practice the courses are the easy part. What your learners, auditors and funding bodies care about is the record of who completed what, when, and with what result. Those records are also the easiest thing to damage in a move.
This guide sets out how to plan a migration, whether you are changing host, upgrading several versions or tidying up an old site, so the records arrive intact and you can prove it.
Start by naming the kind of move
Four different jobs all get called a migration, and they carry very different risks for your records.
- A whole-site move. The database, the uploaded files (the moodledata directory) and the code move together to a new server. Users, enrolments, grades, completions and logs all come across, because nothing is being rebuilt. This is the safest route for records.
- An upgrade on the same server. The database stays where it is, so the main risk is a plugin that does not work on the new version.
- A course-by-course move. Courses are backed up and restored into a new or clean site. A course backup can carry user data such as enrolments, submissions, grades and completion, but only if it is included when the backup is made. Grade history and course logs are left out unless an administrator switches them on first, badges already issued do not come across, and restored accounts arrive without passwords. Site-wide data does not travel this way at all.
- A change of platform. Moving between Moodle and another learning management system (LMS) rarely transfers the detail of each attempt, such as quiz answers and SCORM progress. Plan to export the records and keep them as an archive.
If keeping records is the priority, move the whole site, and treat the move and the upgrade as two separate steps with a records check after each. Which comes first depends on whether the new server can run your current version. Rebuild course by course only when you have a reason to leave things behind.
List what counts as a record
Before anyone touches a server, write down what you must be able to show after the move. For most organisations that list includes:
- Enrolments and roles, including dates.
- Activity completion and course completion.
- Grades, including the history of changes and any grades changed by hand (overrides).
- Quiz attempts, assignment submissions and feedback.
- SCORM tracking: status, score and attempts for each learner.
- Certificates and badges already issued, with their dates and verification codes.
- User profile fields that hold identifiers, such as a student number.
- Logs, where you rely on them as evidence of participation. Check how far back your site keeps them.
Registered training organisations and funded programs usually have set retention periods for this evidence, and they differ by type of record. Check your regulator's requirements and your funding contracts, keep to the longest that applies, and make the list match them.
Check the upgrade path and your plugins
Moodle does not always upgrade from an old version to the newest one in a single step. Each release states the earliest version it can upgrade from, along with the versions of PHP (the language Moodle runs on) and the database it needs. A site that is several major versions behind may need two or three upgrades in sequence, with PHP upgraded along the way. The release notes for your target version list the minimum.
Plugins matter even more. Activities, certificates and attendance tools added as plugins keep their records in their own part of the database. If a plugin is not available for the new version, those records cannot be used there until a compatible version is installed, and in a course-by-course move its activities are skipped altogether. List every plugin, check each one against the target version, and decide what happens to the data of any you plan to retire. Export that data first: uninstalling a plugin through Moodle deletes its records permanently.
Rehearse on a copy
Run the whole migration on a private test copy of the site (a staging copy) before you schedule the real one. A rehearsal tells you how long the move takes, which plugins fail and what breaks after the upgrade, while the live site carries on untouched.
Keep the copy fully separate: switch off its outgoing email, disconnect it from your live systems and protect it like the live site, because it holds the same personal information. Ask the people who run reports and issue certificates to test the copy, not only the technical team.
Reconcile before and after
Do not rely on the site looking right. Compare numbers taken from the old site with the same numbers from the new one. If the old site shows 1,284 completions for a course, the new one should show 1,284.
- Total users, and enrolments in each course.
- Course completions, by course.
- Final grades for a sample of learners in each course.
- The number of certificates issued. Also check that an old verification code still works and that an old certificate still downloads with its original date.
- SCORM attempts and scores for a sample of learners.
Then open individual learner records side by side on both sites. Include a learner with a long history, one with an overridden grade and one who completed years ago. Check that submitted files still open. Keep the before and after figures, with the date and the name of the person who checked them. That is your proof.
Plan the cutover
The cutover is the switch from the old site to the new one.
- Pick a quiet period, tell learners and staff in advance, and agree who decides that the checks have passed and what happens if they have not.
- Put the old site into maintenance mode, so nothing is submitted during the move, and ask administrators to stay out too.
- Take a final backup of the database and the files, and keep it.
- Keep the same web address if you can. If it has to change, redirect the old one: certificates and badges already issued, bookmarks and other systems may all point to it. Links stored inside course content need updating too. Moodle includes a search and replace tool for this, but Moodle calls it experimental and its changes cannot be undone, so try it on the rehearsal copy first.
- Reconnect single sign-on, enrolment sync with your student management system and any external tools, which are often tied to the old address.
- Check what lives outside Moodle. Plagiarism checking, virtual classroom recordings, video hosting and externally hosted tools hold their own records and do not move with the site.
- Confirm that Moodle's scheduled background tasks and outgoing email are working before you reopen, and that the new site is being backed up.
Keep the old site, and an independent copy
Keep the old site for an agreed period after cutover, closed to learners and open only to a few named staff, in case a question comes up that only it can answer. Switch off its outgoing email and disconnect it from your other systems, as you did for the rehearsal copy. Then shut it down.
Export your key completion and grade reports to files as well, and store them outside Moodle. A record that exists in two places is far harder to lose. Store these copies securely, limit who can open them, and agree when they will be deleted. A report is a summary, so if you have to keep the assessments themselves, check that the submissions have come across or been archived too.
A closing checklist: how records get lost
- Courses are restored without their user data.
- Learners end up with duplicate accounts, because usernames, email addresses or the login method changed, and their history stays with the old account. Agree one identifier, usually the username, and make sure it and the email address match on both sites before anything is restored. Moodle has no built-in way to merge two accounts afterwards.
- A plugin that held records is missing on the new site, or was uninstalled before its data was exported.
- Certificates are reissued with new dates and codes, instead of the originals being carried over.
- A SCORM package is replaced with a new version, which can delete the attempts recorded against the old one.
- Completion settings are unlocked and changed after the move. Moodle warns that this can delete existing completion data.
Where we come in
Skills Leap Australia upgrades and migrates Moodle sites, and handles course and data migration, hosting and ongoing support. If you are planning a move, a 30-minute platform strategy call is a good place to start. See learning platform services and Moodle customisation.