Moodle

Moodle migration services with every record accounted for

We move courses, users, grades, completion and files into, between or out of Moodle sites. Each migration gets a full trial run on a copy, and the numbers are compared with the source before you switch.

  • Rehearsed before cutover
  • Counts reconciled
  • Old site kept as archive
Get a free quote See our work
What is included
  • Whole-site moves
  • Course backup and restore
  • Users and enrolments
  • Grades and completion
  • Plugin compatibility audit
  • Rehearsal and cutover
Get a free quote Reply within one business day. NDA on request.
The problem

What makes LMS moves risky

Nobody migrates an LMS for fun. The hosting contract is ending, the old platform is being retired, two organizations have merged and now own three Moodle sites, or the current server simply cannot cope. Whatever the trigger, the fear is the same: that on Monday morning a learner logs in and three years of grades are gone.

A Moodle migration is really two different jobs that get confused. Moving a whole site (same Moodle, new home) is mostly an infrastructure task with a strict checklist. Moving content and history into Moodle from elsewhere, or merging sites, is a data project where every course, user and record has to be mapped. We do both, and we also help clients leave Moodle when a different platform fits them better. For a move that also changes the Moodle release, see Moodle upgrade.

  • History that must not be lost

    Completion dates and grades are evidence for auditors, accreditors or employers. A migration that brings the courses but drops the records has failed, however good the new site looks.

  • A site too big to copy casually

    The moodledata directory holds years of uploads and backups. Copying it takes many hours, and learners keep submitting work while the copy runs.

  • Plugins that will not come along

    The old site depends on plugins that are unmaintained or unavailable on the new host. Courses restore with broken activities and missing blocks.

  • Two sites, overlapping people

    After a merger the same person exists on both sites with different usernames, and both sites have a course called Induction with different content.

What we do

What we move in and out of Moodle

We scope a migration by listing what has to arrive intact, then choosing the method that carries it.

Whole-site moves

Database, code and the moodledata file store transferred to new hosting, with configuration, cron, caching and mail rebuilt and the site address changed cleanly.

Course backup and restore

Courses carried as .mbz backups, with or without user data, restored into a planned category structure and checked activity by activity.

Users and enrolments

Accounts created or matched on a stable identifier, with profile fields, cohorts, roles and enrolments rebuilt and a clear plan for passwords or single sign-on.

Grades and completion

Historical grades, completion dates and certificates carried over or imported, so transcripts and compliance reports stay continuous across the move.

Plugin compatibility audit

Every installed plugin checked against the target site, with a decision for each: keep, update, replace with a core feature or retire.

Rehearsal and cutover

At least one full dress rehearsal with timings, then a scheduled freeze, final sync, verification and DNS switch, with the old site kept read-only.

Typical projects

Moodle migration scenarios we handle

01

Moving to new hosting

From a shared server or an expiring vendor contract to your own cloud account, on the same Moodle release, with a short read-only window and no change for learners.

02

From another LMS into Moodle

Courses rebuilt or imported through SCORM and common cartridge packages, question banks converted, users loaded and completion history brought in as records.

03

Consolidating several Moodle sites

Departments or merged organizations brought onto one site, with duplicate users matched, a category per former site and plugin sets reconciled.

04

Leaving Moodle

Course content, users and completion records exported and loaded into a WordPress LMS, a custom platform or a hosted product, when that suits your direction better.

In depth

What actually moves in a Moodle migration

A Moodle site is three things

The database holds users, courses, grades, logs and settings. The code directory holds Moodle, plugins and the theme. The moodledata directory holds every uploaded file, stored under hashed names that only the database can interpret. A whole-site move must carry all three in a consistent state. Copy the files on Friday and the database on Sunday, and you get submissions that point at nothing. We put the site in maintenance mode for the final sync, having copied the bulk of moodledata in advance so the window stays short.

Course backups and their limits

The .mbz backup is Moodle's portable course format. It carries activities, resources, question banks, settings and, if selected, user data such as submissions, attempts, grades and completion. It is the right tool for moving selected courses or merging sites, and it has limits you should know about before planning around it. Site-level items such as cohorts, site-wide role definitions and site settings are not inside a course backup. Very large courses can exceed time and size limits unless backups are run from the command line. And activities from a plugin that is missing on the target simply do not restore.

Matching people

When a course is restored with user data, Moodle tries to match each user to an existing account and otherwise creates one. In a consolidation that is where duplicates are born. We agree the identifier first, clean both user tables against it, and load or map accounts before any course arrives. Passwords deserve a decision too. Inside a whole-site move they come along. From another platform they generally cannot be reused, so we plan for single sign-on or a reset email at first login.

Coming from a different LMS

There is no button that converts another platform into Moodle. Content moves through standards where the source can export them (SCORM, common cartridge, question formats) and by rebuilding where it cannot. History moves as data: we extract enrolments, grades and completion dates from the old system and write them into Moodle through its APIs, so reports and certificates show the original dates. We tell you up front what cannot be carried, typically attempt-level detail and discussion threads.

Rehearse, reconcile, then switch

Every migration is run at least once in full on a staging target. We time each step, then compare counts between source and target: users, enrolments per course, grade items, completions, files. Your own staff spot-check courses they know. Only when the numbers agree do we schedule the cutover, and the old site stays online in read-only form until you are ready to archive it. If the right destination turns out not to be Moodle at all, our migration and modernization team plans the move out with equal care, including moves to LearnDash.

Process

A Moodle migration plan step by step

  1. 1

    Inventory and scope

    We catalog courses, users, plugins, file volume and integrations on the source, and agree what moves, what is archived and what is left behind.

  2. 2

    Target preparation

    The destination site is built or cleaned up, with structure, plugins, authentication and theme in place before any data arrives.

  3. 3

    Dress rehearsal

    A full trial migration runs on staging. We record timings, fix what fails and produce the first reconciliation report for you to review.

  4. 4

    Freeze and cutover

    The source goes read-only at an agreed hour, the final sync runs, checks are repeated and the address is pointed at the new site.

  5. 5

    Aftercare

    We watch logs, cron and support tickets through the first days, keep the old site available for reference, and archive it on your say-so.

Deliverables

What you hold after the Moodle cutover

  • A reconciliation report comparing source and target
  • A plugin decision list with replacements noted
  • Redirects from old course addresses where they changed
  • The previous site preserved read-only until sign-off
  • A cutover runbook with timings and rollback point
FAQ

Moodle migration questions before you commit

Will learners lose their grades and completion records?
They should not, and proving that is the core of the job. A whole-site move carries every record as it is. When moving selected courses or coming from another LMS, we migrate grades and completion dates explicitly and compare the totals with the source before cutover. You sign off on that comparison.
How long is Moodle offline during a migration?
For a whole-site move, a short read-only window while the final database and file sync runs. Its length depends mostly on the size of the database and how much changed since the pre-copy. The rehearsal gives a measured figure, and we schedule the window for a night or weekend that suits your learners.
Can you migrate us from another LMS into Moodle?
Yes. Content comes across through export standards such as SCORM and common cartridge where the old platform supports them, and is rebuilt where it does not. Users, enrolments and completion history are extracted and loaded as data. We list anything that cannot be carried before you commit.
Do users have to reset their passwords?
Not when the whole Moodle site is moved, because accounts travel with the database. Coming from another product, stored passwords usually cannot be transferred, so users either sign in through single sign-on or receive a reset link on first visit. We plan the communication with you so the help desk is not surprised.
We have several Moodle sites. Can they become one?
Yes. We choose one site as the base or build a fresh one, agree a common identifier for users, then restore courses from the others into their own categories. Conflicting plugins, roles and themes are reconciled first. The former sites stay available read-only for as long as you need them.
Can you help us move away from Moodle?
Yes. If your catalog and audience are better served elsewhere, we export courses, users and completion records and load them into the new platform, whether that is a WordPress LMS, a hosted product or a custom build. We will tell you plainly what you gain and which Moodle features you give up.
Related

Moodle Upgrade

Moodle Maintenance & Support

Migration & Modernization

LearnDash

Moodle Integration
Start a project

Planning a move to, from or between Moodle sites?

Tell us where the site lives now, roughly how many users and courses it has, and where it needs to go. We reply within one business day, and the quote is free.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Prefer to talk first? Book a call WhatsApp wwc@worldwincoder.com
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.