How to Moodle

How to Moodle

How to Moodle

How to plan your LMS migration

Migrating your Moodle to ELD servers can have a turnaround timeframe as short as 24 hours (M-F) if you don’t have planned user activities to accommodate; if you do, once signup is complete, we’ll coordinate a suitable day/time instead.

Of course, as installation sizes and circumstances can differ, no singular pathway will suit all migrations, so we’ve categorised the most common (and covered the basics of each) so you’ve got a fair idea of what to expect.

Downtime requirement

All sites (no matter the pathway) will need to be in maintenance mode for the duration of backup/migration. They will be completely inaccessible to any user, but you can customise the ‘maintenance’ message in advance, as well as give users a warning.

A backup is a ‘snapshot’ of your site it stands and everything in the backup is migrated as-is to our servers. This is why your site needs to be in maintenance mode for the duration of the backup/migration process – there must be no risk of new data being added and then lost.

Start-to-end downtime depends on how long it takes to get a full backup, but once that’s in hand, sites are typically live on our servers within an hour.

Migrating from MoodleCloud

As MoodleCloud is a Moodle HQ-provided hosting solution, this type of migration follows a well-worn path.

  • New Moodle ‘shell’ installed on ELD servers

  • Backup requested from MoodleCloud

  • Migration started, URL assigned, and plugins installed

  • Course and site setup configuration applied

  • Site tested and made live

You can find the full process here.

Migrating an existing Moodle installation

Backup/migration speeds are based on GB/file size volumes, but start-to-finish timelines are also influenced by how the backup is provided. While there are no hard and fast rules, to give you a general idea of potential pathways:

Shared hosting migrations

A backup will be a file (or files); the higher the shared hosting level, the longer it will take to complete the backup, and the longer it will take to restore that backup to our servers.

On the day of migration, whoever maintains your server/has access puts your site into maintenance mode, takes a full backup, and passes it over once complete. We would then restore this backup onto our servers, and once that’s complete, apply any upgrades that are required or have been requested.

Dedicated server migrations

Access (preferably) will be direct from your current server, via SSH. This allows us to sync files server to server, so we can ‘seed’ your site without needing downtime before the agreed day of migration, which significantly reduces downtime overall.

On the day of migration, we’d put your site into maintenance mode, fully sync to catch any new data since seeding, then apply any required/requested upgrades.

Migrating to Moodle from a different platform

If you’re moving to Moodle from a completely different system, then the process starts with a Moodle site ‘shell’. Rather than backup/restore a site as it stands, we would follow the standard new site timeline (within 24 hours of written Quote acceptance), and once live, you can start to recreate your LMS in Moodle.

If your current platform has comparable functionalities for learner journeys, it would then be a case of replicating anything relevant (including scaffolding), using any compatible course materials (e.g., SCORM content, videos, PDFs, etc.) to populate where possible, then recreating natively where necessary.

There’s a full breakdown of all areas to consider here, and some guidance on calculating a project budget here.

What happens next?

This page covers all the steps to calculating your budget, and this page walks you through our signup process. After that, it’s simply a matter of coordinating a day to make the move.

LMS Migration FAQs

We need a ‘connection’ between your current server and ours to be able to transfer your data. SSH (Secure Shell protocol) authenticates and encrypts the connections between devices, so it’s a safe way to migrate your site (we can provide a dedicated IP to accommodate firewalls or VPN if preferred), and the most efficient way to transfer large amounts of data.

In non-technical terms, it’s like moving house in stages and unpacking as you go (seeding). On your final walk-through, you grab anything left (syncing) and close the door behind you for good. To complete the process, you just need to tell everyone you’ve moved (DNS).

No – it’s a background activity that quietly copies your data over, but allows for new data to be added at the same time.

On the day of migration, your site is put into maintenance mode so no more data can be added, and the final ‘snapshot’ captures absolutely everything, compares that information to what’s been transferred already, and scoops up (syncs) anything outstanding so your site is identical on both servers.

We use Linux as our operating system, so a shell access pathway needs to be compatible with a Linux client. If that’s not possible, control panel access will be sufficient, but migration will be slower (and downtime much longer) as we won’t be able to seed.

Moodle versions have associated operating system (OS) version parameters (PHP/MySQL, etc.), so if your version is particularly old, you’ll need to upgrade to be brought into line with our standard builds.

Additionally, bug fixes for functionality and security issues are provided for all in-support Moodle versions. If your version is no longer supported by Moodle HQ, your site is at risk of reported security issues (which have been fixed in newer versions) being exploited.

Typically, we use a seeded environment as a UAT to test everything in advance of migration. This includes any required code changes, upgrades, patches, etc. that might be required. It also allows clients to see how their own data will look in the new environment without impacting users.

NB: A UAT will have an ELD domain/URL, which may cause issues with hardcoded links during testing, but the DNS changes required to complete migration will org-associate the domain once live.

Got general questions about how things work? Our FAQ page covers the basics.

Want to ask something specific? You can raise a ticket directly in our Helpdesk system.

Prefer a contact form? Fill in the details, and a ticket will be raised automatically.