Migrate Moodle to a New Server: No Data Loss, No Downtime

Migrating Moodle to a new server seems like the simplest task in the world until the first attempt: copy three things, point the DNS, and you're done. In practice, that's precisely where student submissions, entire semester grades, and a morning of classes are lost. I've worked with Moodle since 2008, and this is the roadmap I use to move an LMS from one server to another without data loss or operational disruption.

TL;DR — The Essentials

• A migration moves three independent components: the Moodle code, the moodledata folder, and the database. Forgetting one is the #1 mistake.
• The downtime window doesn't have to be hours. With incremental copy and reduced DNS TTL, the actual cutover is in minutes.
• Don't migrate and upgrade the version in the same move. The official documentation is explicit: one variable at a time, or you won't know what broke.
• By September 2026, the calendar impacts the decision: Moodle 5.0 loses even security support by October 5, 2026, and 5.3 LTS arrives on the same day, with security support until October 1, 2029.
• Migrating Moodle to a new server without prior rehearsal is a gamble. Rehearsal costs a few hours; an improvised rollback costs the semester.

What Actually Changes When Migrating Moodle to a New Server

Moodle isn't just a website. It's a system with state spread across three locations that must arrive at the destination intact and consistent with each other. Anyone migrating Moodle to a new server needs to capture all three components at the same point in time — understanding this prevents half of all accidents.

1. The Code

The application folder: Moodle core, plugins, theme, and customizations. It's the easiest part to move and the easiest to underestimate — third-party plugins installed years ago often have no record anywhere. Generate the actual list in Site administration → Plugins → Plugins overview and save it off-server.

2. The moodledata Folder

This is where files uploaded by teachers and students, course backups, and caches reside. It's located outside the public web folder, and its path is defined in the $CFG->dataroot variable in config.php. It's the heaviest component: in an LMS with a few years of operation, it's often dozens of times larger than the code.

The official documentation recommends not copying the cache, localcache, sessions, temp, and trashdir subdirectories. They are ephemeral; Moodle recreates them, and ignoring them cuts hours off transfer time.

3. The Database

Everything else: users, enrollments, grades, logs, configurations, course content. This is the component that requires a freeze — if someone submits an assignment after the dump, that file will be in the new moodledata, but its record won't be in the new database. Result: orphaned file, invisible submission for grading.

When to Migrate Moodle to a New Server — and When to Postpone

Migrating just for the sake of it solves nothing. The reasons supporting the decision to migrate Moodle to a new server are four:

• The server can't handle peak load. The LMS bottleneck is seasonal: exam week and the first week of the semester concentrate access. If the system crashes precisely then, the problem is scaling.
• The stack is too old for the next version. Moodle 5.0 already requires PHP 8.2 minimum, the sodium extension, and max_input_vars greater than or equal to 5000. A server stuck on PHP 7.4 won't get a new version — period.
• No one manages the infrastructure. A server without a defined owner lacks tested backups, security updates, or monitoring. It's not a technical risk; it's an institutional risk.
• The cost doesn't add up. A large VPS sitting idle 10 months a year, or a managed cloud plan that doesn't allow installing the plugin the institution relies on.

And when not to migrate? Three situations where the right answer is to wait:

1. Mid-semester, with open activities and deadlines approaching. The ideal window is during breaks, semester transitions, or weekend early mornings.
2. Along with a version upgrade. The official migration documentation asks for one change at a time: if something breaks, you need to know what caused it. Migrate, stabilize, and only then upgrade.
3. Without a successfully restored backup at least once. An untested backup is a hypothesis, not a guarantee — the same reasoning I detailed in the case of content deletion in UFOP's Moodle (a Brazilian university).

Which Version to Migrate to by September 2026

This is the decision that most impacts the outcome because it defines the destination requirements. Anyone migrating Moodle to a new server now needs to consult the official calendar before choosing the version:

Version	Release	End of General Support	End of Security Support	LTS
4.5	10/07/2024	10/06/2025	10/04/2027	Yes
5.0	04/14/2025	04/20/2026	10/05/2026	No
5.1	10/06/2025	10/05/2026	04/19/2027	No
5.2	04/20/2026	04/19/2027	10/04/2027	No
5.3	10/05/2026	10/04/2027	10/01/2029	Yes

Source: Moodle Developer Resources release table.

Two practical takeaways emerge. First: those still running 5.0 have a short deadline — by October 5, 2026, not even security patches will be released. Second: 5.3 is the next LTS, with security support until October 2029. If the migration is now, the smart destination is a server that already meets the requirements of 5.3, even if you deploy 5.1 or 5.2 today and upgrade later, in another window.

And the requirements have truly increased:

Requirement	Moodle 5.0	Moodle 5.3 (LTS)
Minimum PHP	8.2 (8.3 and 8.4 supported)	8.3 (8.4 supported)
MariaDB	10.11	10.11
MySQL	8.4	8.4
PostgreSQL	14	16
SQL Server	—	2019
Oracle	Not supported	Not supported

The discontinuation of Oracle support from 5.0 onwards and the jump of PostgreSQL to version 16 in 5.3 are the details that often derail migration plans made 'by eye' (without thorough checking). Also check the table prefix length: the limit is now 10 characters. I've written about this type of pitfall when analyzing the versions and LTS cycle of a large institutional LMS (at a Brazilian university).

The Step-by-Step Guide That Reduces Risk to Nearly Zero

Pre-Flight (Days Before)

Before migrating Moodle to a new server, determine the exact Moodle version, PHP and database versions, plugin list, moodledata size, database dump size, and external integrators (SSO, automatic enrollment, payment gateway, mobile app). Provision the destination with the correct stack and test a clean Moodle installation on it: if the clean installation fails, the migration would also fail — just later and with data inside.

Rehearsal (The Step Almost No One Does)

Rehearse migrating Moodle to a new server once completely, without a cutover, with the new site responding at a temporary address and in maintenance mode. It's during the rehearsal that incompatible plugins, incorrect permissions, and non-running cron jobs appear. Time each step: this number becomes the actual window you'll announce to the institution.

Execution

The day has arrived. This is the order I follow to migrate Moodle to a production server — each item on the list exists because it was once overlooked somewhere.

1. Activate maintenance mode on the old site. Without this, there's no consistency between the database and files.
2. Generate the database dump with the native tool (mysqldump, pg_dump) and check the file size — a truncated dump is silent.
3. Copy the moodledata with rsync, skipping cache, localcache, sessions, temp, and trashdir.
4. Copy the code with plugins and theme.
5. Create an empty database at the destination with the correct collation (normally utf8mb4_unicode_ci) and restore the dump.
6. Adjust config.php: $CFG->wwwroot, $CFG->dataroot, and database credentials.
7. Correct ownership and permissions for the code and moodledata — the web server needs read and write access to moodledata.
8. Run cron manually once and monitor the output; then schedule it.
9. Test with the site still in maintenance mode: admin login, a course with an activity, upload, email sending, grade report.
10. Perform the DNS cutover, exit maintenance mode, and monitor logs for 48 hours.

The complete roadmap is in the official Moodle migration documentation — it's worth reading before, not during.

How to Reduce Downtime from Hours to Minutes

The time-consuming part of migrating Moodle to a new server is copying files, and old files don't change. Use this to your advantage.

Two-pass copy. Days before, run an rsync with the site live — it transfers the entire volume without rush. On the day of migration, with the site in maintenance mode, run the same rsync again: it copies only the delta, and what took hours now takes minutes.

Reduced DNS TTL. Lower the record's TTL to 300 seconds 24 to 48 hours in advance. Without this, some students will continue to hit the old server for hours after the cutover — and, worse, upload files that will become orphaned there.

Old server in maintenance mode, not offline. Anyone reaching it via DNS cache sees "in maintenance" instead of an error, and won't record anything.

Validation with the new site still in maintenance mode. If you need to redo the restoration, no one has lost work.

In practice, with this sequence, the announced window is usually 30 to 60 minutes, much of which is testing — not transfer.

New Domain: The search and replace That Saves (or Destroys) Your Site

Anyone migrating Moodle to a new server and changing domains in the same move has an extra task. If the address changes, the database content still points to the old one: links within labels, pages, questions, and resources. Moodle provides the tool at /admin/tool/replace/index.php, with a command-line version:

php admin/tool/replace/cli/replace.php --search=//old.example.com --replace=//new.example.com --shorten --non-interactive

Three precautions the documentation itself highlights — and a fourth I learned the hard way:

• Database backup beforehand. The tool rewrites text in bulk and has no "undo".
• No trailing slash and no fixed scheme. Searching for //old.example.com covers both http and https at once.
• Run it only once, with the site in maintenance mode. Two executions with different patterns lead to a mess that's hard to audit.
• reCAPTCHA and integrations need new keys. A new domain invalidates Google keys used for email registration; the same applies to SSO and payment gateway callbacks, which point to the old URL.

Seven Pitfalls That Break a Moodle Migration

These seven have appeared in environments I've been called to fix after someone hastily migrated Moodle to a new server.

1. Copying moodledata with the site live and without a second pass. Everything that came in after the copy disappeared.
2. Incorrect permissions. The site opens, but no uploads work. It's almost always the moodledata owner being different from the web server user.
3. Different collation between source and destination. Corrupted characters in thousands of records — and fixing it afterward is expensive.
4. Cron not configured at the destination. Without cron, Moodle stops notifying, processing queues, and indexing — silently, without visible errors.
5. Missing plugins. Moodle starts up complaining about non-existent plugin tables, and entire activities disappear from courses.
6. Migrating and upgrading at once. When it breaks, you have two suspects and no quick way back.
7. Not keeping the old server for a week. Shutting it down the next day is betting that nothing was forgotten.

The Cost of Migrating Moodle to a New Server — and the Cost of Not Migrating

There are three paths, with very different costs.

Official Cloud (MoodleCloud). Standard plans range from AUD 230 per year (50 users, 1 GB storage) to AUD 3,000 per year (750 users, 50 GB), according to the official plan table. It's predictable but comes with a hard limit: no plugins or integrations can be installed, and a custom domain is only included in the highest plan. For institutions relying on enrollment plugins, certificate issuers, or academic system integration, the conversation ends there.

Self-managed VPS. The rental is cheap; the real cost is the administrator's time. PHP updates, certificates, database tuning, tested backups, monitoring, and incident response during exam week — this is a role, not a task.

Specialized Managed Hosting. The server comes tuned for Moodle, and someone is responsible for its operation. This is the model we offer for managed Moodle hosting, and it makes sense for those with students relying on the environment and no dedicated sysadmin.

The cost of not migrating is the easiest to underestimate: an LMS outside of security support is a known attack surface. With 146,693 Moodle sites registered worldwide, according to the official statistics dashboard, a disclosed vulnerability is exploited at scale — and doesn't pick targets.

How Agathas Web Solves This

Migrating Moodle to a new server is a service, not an off-the-shelf product. What we do, in order:

• Current environment diagnosis. Version, plugins, moodledata and database size, integrations, and what's out of support. From this, an honest estimate of the migration window emerges.
• Destination provisioning. Server already with the stack compatible with Moodle 5.x — PHP 8.2 or higher with sodium, database at the minimum required version, Redis for cache and sessions, certificate, firewall, and cron.
• Full rehearsal before D-Day. New site live at a temporary address, to validate plugins, theme, SSO, email sending, and performance before any cutover.
• Cutover with incremental copy and low TTL, with the old server preserved in maintenance mode for one week as a real rollback option.
• Post-migration operation. Automated daily backup with tested restoration, monitoring, point-version updates, and technical support in Portuguese. This is included in managed Moodle hosting — the initial migration is included in the onboarding process, with no separate charge for environments within the plan's scope.

We are Moodle-certified, have administered critical online learning environments since 2008, and develop integrations when an off-the-shelf plugin doesn't exist — from synchronization with academic systems to student notification via the official WhatsApp API, to announce deadlines and grades without relying on emails that no one opens.

To get started, the process is simple: through the managed Moodle hosting page, you request a diagnosis, receive an assessment of your current environment, and a proposed migration window that doesn't disrupt your academic calendar.

Conclusion: Plan the Cutover, Not the Rush

Securely migrating Moodle to a new server is less about commands and more about sequence: freezing, copying in two passes, validating in maintenance mode, cutting over DNS with a low TTL, and keeping the old server as a safety net. The three components — code, moodledata, and database — must arrive together and consistently, and the version upgrade is left for another day.

If your environment is stuck on a stack that doesn't support Moodle 5.x, or if your server has reached its end-of-life, the next step is to assess your current setup before choosing a destination. Request a diagnosis through the managed Moodle hosting page and make the move in the right window — not in the middle of exam week.