Moodle Migration Services UK: A Buyer’s Checklist for Scope, Risk and Handover

A Moodle migration service should deliver a verified learning platform, not merely copy files to a new server. The supplier needs to understand the current site, design a compatible target, rehearse the move, control cutover, prove the data and integrations work, and leave your team with a supportable platform.

That distinction is important when comparing UK providers. Two proposals can both say “Moodle migration” while one includes discovery, plugin remediation and post-launch support and the other assumes a clean database, compatible code and a customer-managed test plan. The cheaper headline can become the more expensive project once those assumptions meet the live site.

The Short Answer

Choose a Moodle migration provider that will put five things in writing:

• exactly what data, code, files, integrations and environments will move;
• the target version and infrastructure, with every compatibility dependency recorded;
• at least one representative rehearsal and an evidence-based acceptance plan;
• cutover, communication, rollback and post-launch ownership; and
• a usable handover, including exports, documentation and unresolved risks.

Do not select on downtime or price alone. A fast cutover is valuable only if the provider can explain how it was estimated, what must remain frozen, how success will be measured and when rollback becomes safer than continuing. Swift Learn’s judgement is that a reproducible migration with a clear decision trail is a better purchase than a heroic one-off weekend move.

For the technical sequence behind those controls, read our Moodle migration guide. This checklist concentrates on buying and governing the service.

Why a Moodle Migration Is More Than a Data Transfer

A functioning Moodle site is a connected system. It includes the database, the Moodle data directory, application code, additional plugins, a theme, scheduled tasks, email, identity, storage, reporting and other integrations. Its behaviour also depends on PHP, the database engine, web-server configuration and background processing.

These components must represent the same point in time. A database captured after the matching files can leave uploaded content or submissions out of step. Code that runs on the old platform may be incompatible with the target. A successful login does not prove that grades, completion, enrolments, scheduled tasks and outbound messages remain correct.

This is why “lift and shift” should describe an approach, not the acceptance criterion. The buyer still needs evidence that important learning and administration journeys survive the move.

What the Migration Scope Should Include

1. Discovery and a Written Baseline

The provider should inventory the current Moodle version, hosting stack, database, storage volume, user and course scale, authentication methods, plugins, custom code, theme, scheduled tasks and integrations. It should also identify who owns each component and whether its source, credentials, licences and documentation are available.

Ask for the findings, assumptions and exclusions as a deliverable. Discovery should expose unsupported plugins, abandoned customisations, unusual cron jobs, hard-coded domains, data-quality problems and access dependencies before they can block a rehearsal.

A responsible supplier may refuse to give a fixed cutover price before this work. That is not necessarily evasive. A short paid discovery phase can reduce contingency and make later quotes comparable. The trade-off is modest upfront spend in return for fewer hidden assumptions.

2. Target Design and Compatibility Decisions

The proposal should name the target Moodle release and the supported PHP, database and web-server configuration. It should state whether the project is a like-for-like move, an upgrade or both. Combining migration and upgrade can avoid doing disruptive work twice, but it also makes fault diagnosis and rollback more complex.

Version requirements move. The official Moodle 5.3 release notes, checked on 31 August 2026, described 5.3 as unreleased with a planned release date of 5 October 2026. They also listed Moodle 4.5 as the minimum upgrade source, PHP 8.3 as the minimum and higher database requirements than some older sites use. Those details will age; the procurement lesson is durable: require the supplier to date its compatibility matrix and recheck it before build and cutover.

Every plugin and integration needs a decision: retain, upgrade, replace, remediate or retire. “We will test the plugins” is weaker than a register showing the installed and target versions, maintainer status, decision, owner and test evidence.

3. Rehearsal, Validation and Acceptance

Require at least one migration using representative production data in an appropriately protected environment. A rehearsal reveals actual transfer time, upgrade behaviour, storage needs and manual steps. It should produce an issue log and an updated runbook, not just a demonstration.

Agree acceptance tests before the rehearsal. Include learner, manager, trainer and administrator journeys that matter to your organisation: sign-in, enrolment, course access, submission, grading, completion, reports, email, scheduled tasks and critical integrations. Reconcile important counts and sample records, then check that files open and permissions still produce the intended access.

The supplier should distinguish three levels of proof:

• technical validation, such as services running and scheduled tasks completing;
• data validation, such as agreed counts, relationships and representative records matching; and
• business acceptance, such as real roles completing priority learning journeys.

None substitutes for the others. Make the acceptance owner and evidence repository explicit.

4. Cutover, Freeze and Rollback

The cutover plan should name every step, owner, dependency and decision point. Define when changes stop on the source site, how users will be informed, when final data is captured, how domain and certificate changes will work, and who authorises launch.

Ask what “downtime” means. A read-only site may reduce disruption but still prevent submissions or course administration. Domain caching and identity changes can also produce a period in which different users reach different environments. The plan should describe the learner experience, not only the engineer’s maintenance window.

A rollback plan needs a trigger, decision-maker and last safe decision time. It must explain what happens to activity created after the new site opens. If that activity cannot be merged back safely, the launch decision should occur before normal use resumes.

5. Hypercare and Operational Handover

Post-launch support should cover a defined period, route and severity model. Record who monitors scheduled tasks, performance, storage, email and integration queues, and how defects are separated from new requests. A vague promise to be “on hand” is difficult to operate when learners are affected.

Handover should include the final architecture, component register, configuration decisions, migration runbook, validation results, known issues, access ownership, backup and recovery procedures, and support routes. Your team should also receive the database, data files and code it is entitled to retain in usable formats.

If the migration leads into an ongoing service, compare those responsibilities with a proper Moodle support contract. Migration acceptance and managed support commencement should meet at a documented boundary.

How to Compare Moodle Migration Quotes

Ask each provider to price the same responsibility boundary. Separate discovery, migration delivery, third-party licences, custom development, additional rehearsals, out-of-hours work, hypercare and ongoing hosting. Then identify the internal time and external suppliers that remain your responsibility.

The main cost drivers are usually complexity and uncertainty rather than the number of courses alone. Custom plugins, identity and HR integrations, large file stores, weak documentation, limited source access, strict outage constraints and extensive remediation all add work or risk.

Fixed price can make budgets easier to approve, but only when scope and assumptions are mature. Time and materials can suit uncertain remediation, provided there is prioritisation, transparent reporting and a spend-control point. A sensible hybrid is fixed-price discovery followed by a delivery price based on the confirmed baseline.

If the same supplier will host the target, use our questions for a UK Moodle hosting provider and compare the whole-life responsibility boundary. Our managed Moodle hosting versus self-hosting guide can help account for the internal work that does not appear on a supplier invoice.

Data Protection and Access Belong in the Plan

A migration supplier may handle learner profiles, activity records, submissions, messages and backups. Give access only through approved, named accounts with the minimum privilege and duration required. Agree secure transfer, storage locations, retention, incident handling and deletion evidence for working copies.

Where the supplier acts as a processor, the contract needs to match the real work. The current UK GDPR Article 28 text, checked on 31 August 2026, requires a written processing arrangement covering matters including documented instructions, confidentiality, security measures, sub-processors, assistance, audit information and deletion or return of personal data. Ask your data-protection or legal lead to confirm the terms for your circumstances.

Do not let privacy review become a document-only exercise. The project plan should identify which datasets are copied into rehearsal environments, who can reach them, how they are protected and when each copy will be removed.

Questions to Ask a Shortlisted Provider

Use the same questions with every bidder:

1. What do you need to inspect before confirming scope and price?
2. Which components are included, excluded or owned by another party?
3. What is the proposed target version, and what prevents a direct move?
4. How will you assess plugins, custom code, the theme and integrations?
5. How many rehearsals are included, and what changes after each one?
6. Which counts, records and user journeys will prove the move is complete?
7. How was the cutover estimate produced, and what could extend it?
8. Who can stop or roll back the launch, and what are the triggers?
9. What support is included after launch, during which hours?
10. What exactly will we receive at handover and at service exit?

Strong answers are specific, bounded and supported by sample deliverables. Be cautious when a provider promises zero risk, treats every plugin as automatically portable, cannot explain how it reconciles data or leaves rollback until the night of cutover.

The Swift Learn Verdict

The best Moodle migration service is not the one with the shortest proposal. It is the one that turns an uncertain estate into a controlled, testable sequence and leaves the organisation able to operate what arrives.

Buy discovery where uncertainty is material. Make compatibility decisions visible. Rehearse with protected representative data, accept against business journeys and decide rollback before the pressure of launch. Finally, insist that hypercare and handover have owners, evidence and an end point.

Planning a Moodle Migration?

Bring us your current version, hosting position, critical integrations and preferred timescale. Swift Learn will help you define the migration boundary, identify discovery needs and shape a practical rehearsal, cutover and support plan.