Migrating Moodle to a new server is always a daunting prospect. Many moving parts have to align, and care needs to be taken that all of the requisite decisions have been considered. However, with good planning it is a fairly low risk process. Below, we unpack some of the key steps in the planning and execution phases of Moodle server migrations.
PHASE ONE: PLANNING
Why organisations move Moodle to a new server?
From outgrowing current hosting to performance issues, there are various reasons why you may need to migrate your Moodle to a new server, and possibly a support partner. The most common questions organisations ask, and reasons they move include:
Cost: By moving, will you get greater value for your money, even when changing to the same or a higher price point? Moving servers or providers may provide a financial benefit.
Service: By moving, is there an increase in the service being delivered? This could be performance, integrations, or secondary services such as analytics, provided or done better by one vendor vs another
Access: By moving, do you have better access to your system? Some vendors may provide more access to configuration options than others. This often comes into play when considering integrations, such as with a business intelligence system, that needs (you to have?) direct access to the application database.
Some of the more technical questions and considerations in the planning phase are:
Software licensing: Could operating system, database server, or other miscellaneous licensing, be replaced with open source alternatives? Examples of this may include moving from a Red Hat Enterprise Linux server onto an Ubuntu or Debian based system, or moving from Microsoft SQL Server to PostgreSQL for the underlying database.
Existing technology landscape: Moving servers may allow you to better utilise other tooling and technology present in your organisation. This may include integration with existing enterprise authentication patterns, load balancing, or certificate management.
Scale into the future: What will your performance needs be in 2 years? Do you expect to have double the students you do now?
The question of scale will guide decisions around clustering your Moodle, the amount of compute hardware you purchase or reserve, and how resources are managed on the system.
Note: this also applies to things used within Moodle. High-resolution video can quickly chew up terabytes of disk for a relatively small set of learners, so plan for your content as well as your users.
The above questions form the foundation of the planning phase, as the best time to do any significant changes to a system is when it is being built fresh on a new server.
Before you migrate: What to prepare?
When designing a migration, make sure that all of your technical dependencies are satisfied.
- Check that the versions of the database and PHP on the target system are correct for the version of Moodle you are using.
- Also ensure that any required PHP extensions for Moodle are available and installed on the target server.
- Some Linux distributions don’t always ship all required extensions, such as PHP-Sodium, so plan ahead to use a community source if required.
- Create backups of all of your configuration, the Moodle database and Moodle sitedata directory, and store them in a secondary location, such as a shared network drive; or cloud blob storage bucket, to ensure that in the worst case, all of your data is still available.
- Prepare a runsheet of all of the planned activities, and check them off as you go. Checklists ensure that a critical step like updating a DNS address doesn’t get lost in the bustle of performing the migration.
PHASE TWO: EXECUTION
The Server Migration Process
Now that the key questions have been addressed, you are ready to start the process of migration.
The three key things for a smooth migration are to:
- Do as much as you can ahead of time
- Utilise a non-production environment to validate your ideas
- Make your rollback as smooth as possible
1. Do as much as you can ahead of time
This seems obvious, and it largely is, but there are subtle things you can do to incur less downtime as you migrate. Let’s look at what they are.
Moodle files directory
One of the major slow points during a migration is the process of migrating the Moodle files directory, which can often be in the terabytes. Using a tool that allows for difference-based file copies can greatly speed up your migration on the day. Linux rsync is a fantastic tool which can copy all of your files onto your new server, and then on the day of migration, running rsync again will only copy the small delta of files that have been added, greatly increasing migration efficiency.
Moodle database
Another slow point is the copying of the database, which is often a multi-step process, involving a database dump, transfer, and then upload into a new database server. Although these are only a few steps, putting together a script to be run that handles the process can improve efficiency. Utilise compression during your dump to improve transfer speeds across the wire.
config.php file
Put slow moving configuration items into your config.php file, instead of configuring them manually. During migrations and upgrades, there are likely many settings that need to change in the site administration menu to support the new environment. Moving these into the configuration file instead of manually entering them reduces the opportunity for human error, and provides a simple way to apply all your new configuration at once, which can be developed and tested ahead of time, rather than during a maintenance window.
DNS records
DNS is an often overlooked component of your migration. If you need to change DNS records for your Moodle to point at your new server after migration, make sure you tune down the Time to Live (“TTL”) ahead of time, so that the DNS can be updated in minutes instead of hours for your users.
2. Utilise a non-production environment to validate your ideas
Having a test environment is critical to the success of any migration. Outside of setting up the Moodle dependencies (webserver, PHP, file storage), there are many things operating on a server for security, auditing, or monitoring purposes, which can interact with your Moodle installation.
Some of the key things to watch out for are server and gateway firewall rules, which can interrupt connection to external resources like an external database server, or security policies such as SELinux, which can restrict your application from running correctly. These fixes can take time, and they aren’t ones you want to find out about on the day.
3. Make your rollback as smooth as possible
Sometimes things won’t go smoothly, so planning for that is critical to a well handled migration. Often the easiest measure here is to rely on DNS. Keep the old system up and running, so if you need to roll back, it’s as simple as pointing your DNS record for the Moodle instance back to the old server. Ensure that if you are running in a virtualised environment, utilise virtualisation tools like snapshoting at key points during the upgrade, so that if something goes wrong, you can rollback to a previous step, rather than having to start again.
PHASE THREE: VERIFICATION
Common issues to check after the migration
The migration has gone smoothly, the new system is up, running, and serving user traffic. Now we need to ensure that everything is working as expected. Using a series of quick stability checks, and utilising the comprehensive tooling with Moodle, you can verify things are working as intended.
File permissions
Ensure that the webserver user (apache, nginx, www-data) has appropriate permissions to read your Moodle sitedata. This can quickly be tested with `sudo` to quickly run a command as the webserver user. Also ensure that the webserver itself has permission to read the Moodle code directory, and the SSL certificate files on disk, to ensure the site can be accessed and function securely.
Caching
Ensure that any cached data is cleared using the Moodle “Purge caches” function. This will ensure any data that is cached from the previous configuration is updated. Also ensure any disk based caching is using the correct paths on the new server.
Status checks
/report/status/index.php – System Status Report
This page within Moodle provides key information to ensure the health of your system, including monitoring for task failures and for authentication method health. Anything not green in this report should be addressed as soon as possible to ensure a stable system. Common points of issue are plugin compatability, or incorrect cron scheduling.
Security Checks
/report/security/index.php
This report shows you any potential security issues that have been detected, based on the configuration of the webserver and PHP installation. Similar to above, anything not green in this report should generally be investigated and addressed.
Mail sending
An often overlooked part of a migration is ensuring that mail is still sending correctly and being delivered to end users. Utilise Moodle’s “Send Test Email” functionality to send mail out for testing, and ensure that your mail is received, and that it passes SPF, DKIM, and DMARC. Any of these being misaligned can lead to mail being undelivered to your users.
Synthetic Monitoring
It’s not enough that the system is operating well now; you need to ensure it continues to stay that way. Set up synthetic application monitoring to ping your site every minute, and ensure you get a 200 OK return code back. Use tools like tool_heartbeat to provide a Nagios compliant monitoring endpoint, using many of the same checks as the status reports above, to deeply monitor the health of your system in real time.
When to bring in managed support
There are sometimes challenges that may require expert support to get resolved. Issues with Single Sign On (SSO), scheduled task performance and tuning, or load balancing across multiple servers, are topics that usually need an experienced hand to get right.
Catalyst have a wide range of support models to help you every step of the way, from consulting, guidance and support, all the way through to a complete managed service for your Moodle, removing all of these challenges so you can get on with the work of educating.
Considering moving your Moodle to a new server and hosting partner? Enquire today to see how we can help.
Frequently Asked Questions
Can I migrate Moodle to a new server without downtime?
Migrating Moodle to a new server without downtime is an advanced process, involving real-time database replication, and advanced load balancing to transfer without interruption. Catalyst can assist with this process.
What’s the safest way to back up Moodle before migrating?
Take a complete copy of your Moodle’s sitedata directory, and a full dump of your Moodle database contents, and store them in a seperate location, for use if a rollback or data corruption occurs.
Do all Moodle plugins work the same after a server migration?
No, some Moodle plugins may rely on additional software on a server, such as document management, or media tools. While best practice aims to have consistent behaviour across deployments, you should always test thoroughly to catch the edge cases with your setup.
How do I migrate a Moodle database to a new server?
See our upcoming blog on managing this process effectively.
Can Catalyst manage the whole server migration for us?
Yes, Catalyst staff are experienced in all of the challenges that come from migrating, from on-premises to on-premises, or from an on-premises system into a cloud system. We’ve seen it all and are happy to help.
