LMS migration & restore — moved without losing a quiz attempt
Migrations go wrong because they're done once, live, on Friday afternoon. We rehearse them on sandbox copies first — sometimes twice — before anyone touches production.
The number-one reason migrations fail is that nobody rehearses them. Our process is the opposite: we restore your site into a sandbox at the target host first, upgrade and test, then run the production cutover only once everything is green.
The result: most clients see under 15 minutes of read-only mode at cutover, and zero loss of quiz attempts, forum posts or files — even those submitted while the rehearsal was running.
What's included
- From any host: cPanel, Plesk, raw VPS, AWS, Azure, GCP, Hetzner, on-prem
- From any version of Moodle™ 3.x or 4.x — yes, including ancient sites
- Optional version upgrade during the migration (e.g. 3.11 → 4.4 LTS)
- Database engine change supported (MySQL → MariaDB, MariaDB → PostgreSQL)
- PHP version upgrade with deprecation sweep
- Custom plugin compatibility audit before cutover
- Theme customisations preserved (or rebuilt for the new version)
- Sandbox dry-run rehearsal, with full sign-off before production cutover
- DNS cutover plan with low-TTL warm-up and rollback procedure
- Final delta sync at cutover — typically <15 minutes of downtime
- Post-migration smoke-test checklist, signed off together
- Old environment kept read-only for 30 days as a safety net
Questions, answered.
We've already lost our hosting account — can you still recover the site?
Often, yes. If you have any recent backup — even one provided by the old host in its native format — we can restore it. We've recovered sites from cPanel backups, Plesk packages, Moodle™ course backups, raw DB dumps, and even from server snapshots delivered as a tarball on a USB drive.
Can you migrate and upgrade at the same time?
Yes, and it's often the right call — you do the disruptive work once instead of twice. We do the version upgrade in the sandbox so you can verify everything before going live.
How long does a typical migration take?
From kickoff to live: usually 2–3 weeks for a clean migration with no version change, 4–6 weeks if we're also upgrading across major versions. The downtime window itself is under 15 minutes for most sites.
What if a plugin is incompatible with the new version?
You'll know weeks before cutover, when we deliver the plugin report. Options: find a maintained equivalent, pay us to port the plugin, drop the feature, or stay on the older Moodle™ version. We help you decide.