Server Migration Checklist for E-Learning Platforms (2026)

A server migration checklist for e-learning platforms is the difference between a quiet weekend cutover and a Monday morning full of locked-out learners. Whether you run Moodle, Open edX, Canvas self-hosted, or a custom LMS, moving to a new server means relocating code, a database, and a very large pile of course files, all while students, instructors, and integrations expect the platform to behave as if nothing happened.

This guide gives you a practical, evaluation-ready checklist built around how learning platforms actually behave: term-time traffic peaks, gradebook integrity, SCORM and video content, single sign-on, and scheduled jobs. Use it to plan the move yourself, or to judge whether a migration provider has thought about the same things. If you would rather hand the work over, our server migration service covers Linux and Windows moves end to end.

Why LMS Migrations Are Different From a Normal Website Move

A brochure website can usually be copied and repointed in an afternoon. A learning platform cannot, because it is a stateful application that is being written to constantly. Quiz attempts, forum posts, grades, and completion records change every minute, and a copy taken at the wrong moment produces data that is quietly inconsistent.

Three characteristics make e-learning moves harder than most:

• Two data stores that must stay in sync. A platform such as Moodle keeps its application code, its database, and a separate file area (moodledata) for uploads and caches. A migration has to carry all three and keep them consistent with one another.
• Seasonal traffic. Enrolment week, exam periods, and assignment deadlines create load spikes. A cutover in the wrong week is a risk you can avoid entirely.
• Many connected systems. SSO, student information systems, video conferencing, plagiarism checkers, payment gateways, and mobile apps all hold references to your hostname, IP address, or API credentials.

Phase 1: Pre-Migration Audit Checklist

Most migration failures are discovered at cutover but caused during planning. Spend real time here before touching the new server.

Inventory the current environment

• Record the OS version, web server (Apache or Nginx, or IIS on Windows), PHP or runtime version, and database engine and version.
• Note every PHP extension, cron job, and systemd or scheduled task the LMS depends on. The LMS cron is often forgotten and its absence breaks notifications, grade aggregation, and backups.
• Measure database size, file storage size, and the number of files. File count often affects copy time more than raw gigabytes.
• List all custom plugins, themes, and patches, and confirm each is compatible with the runtime versions you plan to use on the new server.
• Document reverse proxies, CDN rules, SSL certificates, firewall rules, and email relay settings.

Map integrations and dependencies

• SSO and identity providers (SAML, OAuth, LDAP) and any callback URLs tied to the current hostname.
• Student information system or HR feeds that push enrolments on a schedule.
• LTI tools, virtual classroom providers, and proctoring or plagiarism services that whitelist your IP.
• Outbound email: SPF, DKIM, and the SMTP relay, so notifications do not land in spam after the move.
• Payment gateways and webhooks, if you sell courses.

Choose the migration window

Pick a low-activity period, ideally outside exams, enrolment, and grading deadlines. Communicate the window to instructors and learners well in advance, and agree in writing who can approve a rollback.

Phase 2: Preparing the Target Server

• Provision the new server with equal or better CPU, RAM, and disk IOPS than the current one. Learning platforms are database and disk heavy, so storage performance matters as much as core count.
• Install matching or deliberately upgraded versions of the web server, PHP, and database. If you are upgrading versions at the same time, treat that as a separate risk and test it separately.
• Configure database collation and character set exactly as the application expects. For Moodle on MySQL or MariaDB, the documentation recommends a UTF-8 multibyte setup such as utf8mb4.
• Set up caching (Redis or Memcached), PHP opcache, and session storage the same way as production.
• Harden the server: firewall, SSH key access, automatic security updates, and fail2ban or equivalent.
• Install a clean, blank copy of the LMS first to confirm every requirement is satisfied before moving real data. This is a low-cost check that catches missing extensions early.

Phase 3: Backup and Rehearsal

Never begin with the live system as your only copy. Take a verified backup of the database and the file area, store it off-server, and prove you can restore it.

• Take a full database dump and a full copy of the file area, and record checksums.
• Restore both onto the new server as a rehearsal and time each step. That timing becomes your downtime estimate.
• Run a pilot with a realistic subset: log in as a learner, complete a quiz, play a SCORM package, submit an assignment, and view a grade.
• Use rsync or an equivalent tool for the initial bulk copy of course files, then run it again at cutover to send only what changed. This shrinks the final downtime window considerably.
• Write a rollback plan with a clear trigger, such as a failed login test, and rehearse it.

Phase 4: The Cutover Checklist

On migration day, sequence matters. A typical order for a self-hosted LMS looks like this:

• Lower DNS TTL values 24 to 48 hours beforehand so the switch propagates quickly.
• Announce the start of the window and place the platform into maintenance mode so no new data is written.
• Pause scheduled tasks and cron jobs on the old server.
• Take the final database dump and run the final incremental file sync.
• Restore the database on the new server and confirm row counts on key tables such as users, courses, and grades.
• Update configuration for the new environment, including the database credentials, the data directory path, and the site URL if it changed. If the domain changes, use the platform's search-and-replace tool to fix internal links stored in the database.
• Purge caches and rebuild any search indexes.
• Point DNS to the new server, install SSL certificates, and lift maintenance mode once smoke tests pass.

Phase 5: Post-Migration Validation

Do not declare victory when the home page loads. Work through a structured verification list.

• Log in through every authentication route: local accounts, SSO, and mobile app.
• Confirm scheduled tasks are running by checking the last-run timestamps in the admin area.
• Send a test notification and confirm it is delivered and passes SPF and DKIM checks.
• Open large files and videos, and test uploads to make sure PHP upload limits and web server body size limits match the old server.
• Verify grades and completion data against the pre-migration snapshot for a sample of courses.
• Test every LTI tool, video conferencing link, and payment webhook.
• Watch error logs, database slow queries, and CPU and memory for at least the first week, especially at the next traffic peak.
• Keep the old server intact, but offline from users, until you are confident no rollback is needed.

Linux vs Windows Considerations

Most open-source LMS deployments run on Linux, but some organisations run .NET or IIS-based learning systems on Windows Server. The checklist is the same in principle, but the details differ.

Evaluation Checklist: Is Your Migration Plan or Provider Ready?

If someone else is doing the work, ask these questions before you sign. A good provider answers them specifically, without vague reassurance.

• Do they run a rehearsal migration and give you a measured downtime estimate, not a guess?
• Do they migrate the database and the file area together, and verify consistency afterwards?
• Is there a written rollback plan with a defined trigger and the old server preserved?
• Do they audit integrations such as SSO, email, and LTI tools before the move?
• Can they schedule the cutover around your academic calendar, including nights and weekends?
• Is post-migration monitoring included, and for how long?
• Are pricing, scope, and exclusions written down, and is there any lock-in to their hosting or support?
• Do they hand over documentation of the new environment when finished?

What Does an LMS Server Migration Cost?

Pricing depends on data volume, number of integrations, downtime tolerance, and whether the move includes version upgrades. The ranges below are rough estimates for planning only, not quotes, and vary widely between providers.

Hourly or flexible billing can be a good fit when scope is uncertain, since you pay for the work actually needed instead of a padded fixed fee. Always ask what is excluded, such as third-party licences or extended monitoring.

Common Mistakes to Avoid

• Skipping the rehearsal. The first time you restore should never be on migration day.
• Forgetting the file area. Restoring only the database leaves courses with missing files and broken media.
• Ignoring PHP and web server limits. Upload size, execution time, and memory limits that differ from the old server cause confusing failures on large assignments.
• Leaving DNS TTL high. Some learners see the old server for hours, submitting work into a system that is no longer live.
• Migrating during peak weeks. A rollback during exams is far more damaging than a delayed migration.

Why E-Learning Teams Choose CloudHouse for Server Migration

CloudHouse Technologies provides Linux and Windows server migrations with 24/7 coverage, so cutovers can happen when your learners are offline, at night or on weekends. Billing is hourly or flexible rather than locked into a long contract, and we do not tie you to our hosting or support once the move is complete. You can review the scope on our server migration page and ask for an assessment based on your own environment.

Conclusion

A successful e-learning server migration comes from preparation: audit the environment, rehearse the restore, sequence the cutover carefully, and validate against real learner workflows afterwards. Keep the old server available until you are confident, and schedule the move outside your busiest academic weeks. Follow the checklist above and you can move your platform with minimal disruption, whether you do it in-house or with a specialist partner.