Migrate your Moodle without a blind cutover.

A Moodle migration goes wrong in the gaps — an untested plugin, a forgotten integration, a DNS cutover with no rollback. This checklist is the sequence we use to move a live Moodle without a blind cutover. Work through it in order; nothing should reach production until it has been validated in staging and signed off.

1. Inventory what you actually run

Most migration surprises come from things nobody documented. Before touching anything, capture the full picture of the source site.

• Moodle version and exact point release, plus the current PHP and database versions
• Every installed plugin and its version — including ones added years ago and forgotten
• Active theme(s) and any custom theme code or overrides
• Integrations: SSO/SAML/OIDC, LTI tools, SCORM/xAPI, student-system or HRIS sync, payment or reporting connectors
• Any custom code, hacks to core, or local plugins
• moodledata size, database size, and the largest file/course
• Scheduled tasks and cron behaviour, and any external services they depend on

Write it down. The inventory becomes the checklist you validate against later.

2. Prepare and reduce risk

• Take a full, verified backup of the database and moodledata — and confirm you can read it back
• Agree a low-traffic change window and communicate it to staff and learners
• Lower the DNS TTL a day ahead so the eventual cutover propagates quickly
• Decide your rollback trigger and who makes the call
• Freeze risky content changes during the migration window

3. Rebuild in staging and validate

Rebuild the site in an isolated staging environment — never validate against production. Then check it against the inventory, not just the front page.

• Database and moodledata restored; site loads and admins can log in
• Every plugin installs/upgrades cleanly; note any that warn or fail
• Theme renders correctly across key pages and on mobile
• Integrations reconnect: SSO login works, LTI tools launch, sync runs
• Spot-check real courses: activities, quizzes, assignments, grades, files
• Cron and scheduled tasks run without errors
• Run smoke tests for the journeys that matter most to your users

Where a plugin is abandoned or incompatible, decide now: upgrade it, replace it, or retire it — not during cutover.

4. Produce a validation report and get sign-off

Record what was tested, what passed, and any known issues with their mitigation. A named owner reviews and approves before you schedule the cutover. This is the gate that turns a hopeful migration into a controlled one.

5. Cut over — with rollback retained

• Take a fresh backup immediately before cutover
• Put the source site into maintenance mode to stop new writes
• Promote the validated environment and switch DNS
• Verify login, a real course, and a key integration on the live domain
• Keep the previous environment and backups until you are confident

Be honest about database rollback. Once users write to the new site, rolling the database back means losing anything created since cutover. Plan the window so that risk is small, and keep the option to restore only as a genuine emergency.

6. After cutover

• Watch logs and error rates for the first hours and days
• Confirm cron, backups and scheduled tasks are running on the new site
• Re-raise the DNS TTL once propagation has settled
• Decommission the old environment only after a safe retention period

Done in this order, a migration stops being a leap of faith. If you would rather not run it yourself, that is exactly what we do — staging-first, validated, with rollback retained.