Moodle Migration: The Complete Step-by-Step Guide (2026)

What is Moodle migration?

Moodle migration is the process of moving a learning environment without losing data or disrupting learners. In practice it means one of two things:

• Platform migration - moving from another LMS to Moodle (for example Blackboard, Canvas, TalentLMS, LearnDash, Teachable or Thinkific). You transfer courses, users, content and records into a fresh Moodle site.
• Server / domain migration - moving an existing Moodle install to a new server or domain. The Moodle stays the same; the hosting, and sometimes the URL, changes.

This guide covers both. If you are also weighing where to host, read our Moodle deployment options guide, and if you are upgrading versions at the same time, see how to upgrade Moodle.

Why organisations migrate to Moodle

1. Open-source flexibility - customise features, modify the platform, integrate external tools and avoid licence fees.
2. Massive global adoption - 400M+ learners across 238 countries and 210+ languages make it a stable long-term choice.
3. Cost efficiency - the software is free; hosting and customisation scale with you.
4. Integrations - Zoom, Microsoft Teams, BigBlueButton, H5P, CRM and HR systems all connect.
5. Better learning experience - customisable dashboards, interactivity and gamification lift engagement.

When should you consider migration?

• Your current LMS is too expensive or licences grow with every user.
• Your platform limits customisation or integrations.
• You want full control and ownership of your data (self-hosted Moodle).
• Your LMS is outdated or cannot scale to thousands of learners.
• Your current server is running out of resources, or you are changing hosting provider or domain.

What data can be migrated?

One of the biggest fears is data loss. In a well-run migration, almost everything moves:

• Courses - structures, modules and lessons.
• Users - students, instructors and administrators, with roles preserved.
• Enrolments - user-to-course relationships so access is intact.
• Learning content - videos, PDFs, SCORM packages and HTML lessons (see SCORM in Moodle).
• Quizzes and assessments - via standardised formats or question-bank export.
• Grades and progress - gradebook data and completion records.
• Certificates - completion certificates, migrated or recreated.

Part A: Migrating from another LMS to Moodle

This is the platform migration workflow professional teams follow. Each step reduces the risk of data loss and downtime.

Common LMS platforms migrated to Moodle

• Blackboard and Canvas to Moodle - universities moving to open-source control and lower cost.
• TalentLMS to Moodle - for greater flexibility and expanded training features.
• LearnDash to Moodle - when scaling to a dedicated, enterprise-grade LMS.
• Teachable and Thinkific to Moodle - creators and businesses wanting deeper customisation and integrations.
• LifterLMS to Moodle - for more advanced capabilities and scalability.

Not sure Moodle is the destination? Compare it in Moodle vs Blackboard and our 10 best LMS in India guide.

Part B: Migrating a Moodle install to a new server and domain

This is a technical, command-line procedure. A mistake here can cause publicly visible downtime, so work carefully and keep the lead engineer available. Run the source site in maintenance mode for the whole process (budget one to two hours if all goes well).

Pre-flight checklist

• Do you have root access to both servers and Moodle admin plus database root credentials?
• Is the source site using reCAPTCHA? Its settings must be updated for the new domain or users cannot register/log in.
• Does the destination have the same post_max_size and upload_max_filesize PHP settings (else uploads cap at 2 MB)?
• Same locales installed? Check with locale -a.
• Enough free disk space? Check with df -h. Turn off heavy logging (e.g. MySQL log_bin) if possible.
• Note the web server (Apache 2.2 vs 2.4 - syntax differs) and database (MySQL) versions on both machines.

Key locations: the Moodle code in /home/<site>/public_html, and the moodledata folder (uploaded/generated files) whose path is set in config.php.

Step 1 - Recreate the user and folder structure on the destination

Match the source user's UID so file permissions transfer cleanly. Find the UID on the source, then recreate it on the destination:

# On SOURCE - find the site user's UID
id yoursite

# On DESTINATION - recreate the same user + UID, then the folders
useradd -u 1025 -m -s /bin/bash yoursite
mkdir -p /home/yoursite/public_html /home/yoursite/moodledata
chown -R yoursite:yoursite /home/yoursite

If that UID is already taken, use a different one and fix ownership after the transfer.

Step 2 - Back up the database

Find the database name in config.php, then dump it with a consistent, single-transaction backup:

grep -E "dbname|dbuser" /home/yoursite/public_html/config.php

mysqldump --single-transaction -u DBUSER -p DBNAME > /home/yoursite/DBNAME.sql

The --single-transaction flag reads a consistent snapshot without locking the whole database.

Step 3 - Transfer the files with rsync

Copy the site folder, moodledata and the SQL dump, preserving owners and permissions (-a). Run on the source:

rsync -ar --progress --partial /home/yoursite/* root@DESTINATION_IP:/home/yoursite/

If you had to use a different UID, fix permissions on the destination now with chown -R yoursite:yoursite /home/yoursite. Then import the database on the destination:

mysql -u DBUSER -p DBNAME < /home/yoursite/DBNAME.sql

Step 4 - Configure the Apache virtual host

Copy the site's .conf from /etc/apache2/sites-available/ on the source to the destination and adjust:

• ServerName (and ServerAlias) to the new domain.
• ErrorLog and CustomLog paths to the new domain name.

If the source is Apache 2.2 and the destination is 2.4, the permission syntax changed - convert allow from all to Require all granted:

# Apache 2.2 (before)
<Directory /home/yoursite/public_html>
  allow from all
</Directory>

# Apache 2.4 (after)
<Directory /home/yoursite/public_html>
  Require all granted
</Directory>

Validate and reload - a broken config takes down every site on the server:

apachectl configtest
a2ensite yoursite
service apache2 reload

Step 5 - Recreate Moodle's cron job

Moodle needs its scheduled task to run every minute. Add it to the web-server user's crontab:

crontab -u www-data -e

# one line, no breaks:
*/1 * * * * /usr/bin/php /home/yoursite/public_html/admin/cli/cron.php >/dev/null

Step 6 - Update the domain name inside Moodle (if the URL changed)

Update every internal reference, point wwwroot at the new domain, then purge caches:

# Rewrite internal references to the new domain
php /home/yoursite/public_html/admin/tool/replace/cli/replace.php \
  --search="https://old-domain.com" --replace="https://new-domain.com"

# In config.php
$CFG->wwwroot = 'https://new-domain.com';

# Purge all caches (or Site administration > Development > Purge caches)
php /home/yoursite/public_html/admin/cli/purge_caches.php

If you use Virtualmin, raise the vhost quota (often 1-2 GB by default) or you will hit the limit fast.

Step 7 - Stream a very large moodledata directory (tens/hundreds of GB)

For huge moodledata, stream a tar archive over SSH instead of copying a giant file - no temp file, no double I/O. Run inside screen so it survives a disconnect:

screen -S stream-moodledata

tar -C /home/yoursite/moodledata -cf - . \
 | pv \
 | ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=5 user@DESTINATION \
   'tar -C /var/www/moodle/moodledata -xf -'

pv shows throughput and ETA; the ServerAlive options stop half-open SSH hangs. Afterwards, fix ownership: chown -R www-data:www-data /var/www/moodle/moodledata.

Step 8 - Reinstall the SSL certificate

Reissue Let's Encrypt for the domain (and the www version if you use it):

certbot -d yourdomain.com -d www.yourdomain.com

Visit the site and confirm the certificate's validity starts today. Disable certbot for the old domain on the old server if you no longer need it.

Step 9 - Enable, then test everything

Enable the site and reload Apache, then log in at /login/ and browse courses and files. Before real emails go out, divert them to yourself in config.php:

$CFG->divertallemailsto = 'youremail@yourdomain.com';

Use Moodle's email test to confirm mail still works. Check quizzes, certificates, the gradebook and user roles like a real learner would.

Step 10 - Go live

When everything checks out, take the site out of maintenance mode (Site administration > Server > Maintenance mode), then redirect the old domain to the new one by adding this to the old vhost:

RedirectMatch ^/(.*)$ https://new-domain.com/$1

Best practices and pro tips

1. Start with a pilot - migrate a few courses first to surface issues early.
2. Clean your data - remove outdated courses, duplicate and inactive users before you move.
3. Document everything - course structures, integrations and workflows simplify mapping and rollback.
4. Train instructors early - give admins and teachers Moodle time before launch.
5. Test like a real user - walk full learner journeys, not just spot checks.
6. Plan communication - tell learners the timeline and what changes.

Troubleshooting common migration issues

• Uploads capped at 2 MB - set post_max_size and upload_max_filesize (e.g. 1000M) in php.ini; check under Site administration > Server > PHP info.
• Large DB import fails ("Lost connection to MySQL server") - lower innodb_buffer_pool_size in mysqld.cnf and restart MySQL.
• Database auth error - add default-authentication-plugin=mysql_native_password to the [mysqld] section, then ALTER USER ... IDENTIFIED WITH mysql_native_password.
• Very old Moodle (2.x) with MySQL 8 - needs code fixes (column aliases; replace @@storage_engine with @@default_storage_engine). Upgrading Moodle first is usually cleaner.
• Embedded videos break - allowlist the new domain in your video host (e.g. Vimeo) settings.
• Email stops after the move - try SMTP over port 465 with SSL; test with your own provider.
• reCAPTCHA blocks logins - update the reCAPTCHA keys/domains for the new site.

Bonus: a daily database backup script

Keep a compressed dump that your host's nightly backup will pick up:

#!/bin/bash
# /home/yoursite/db-backup/backup.sh
mysqldump --single-transaction -uDBUSER -p'PASSWORD' DBNAME | gzip -c > /home/yoursite/db-backup/DBNAME.sql.gz

# schedule it (crontab) to run nightly, before your host's backup window
@daily /home/yoursite/db-backup/backup.sh

The bottom line

Whether you are moving from another LMS to Moodle or shifting Moodle to a new server, success comes down to the same things: back up everything, map and transfer carefully, update configuration, and test like a real learner before go-live. Do that and migration is smooth and invisible to your users.

Want it done without the risk? edzlms plans and runs the whole migration for you.

Book a Free Demo →