Once you have decided to use managed Moodle hosting, the next challenge is choosing the provider that will carry the right responsibilities at the right standard. That decision cannot be made from storage allowances, headline uptime or a monthly price alone.
Two proposals described as “managed Moodle hosting” may cover very different work. One might include Moodle updates, plugin testing, restore exercises and administrator support. Another might provide infrastructure and monitoring while leaving most application work with your team.
The 12 questions below are designed for UK organisations preparing a shortlist, request for proposal or supplier interview. They help learning, IT, procurement and data protection teams compare evidence rather than marketing labels.
If you are still deciding whether to outsource the operation at all, start with our managed Moodle hosting versus self-hosting comparison. This guide begins at the next stage: selecting a managed provider.
Define Your Requirements Before You Request Quotes
A useful proposal starts with a clear service baseline. Give each provider the same information: active users, peak concurrent demand, current Moodle version, data volume, plugins, theme, integrations, authentication method, expected growth, support hours and any fixed launch or compliance dates.
Separate essential requirements from preferences. An organisation delivering mandatory training around the clock has a different risk profile from one running optional internal courses during office hours. Your recovery, support and availability requirements should reflect the impact of an outage, not simply the best numbers available.
If the current platform is poorly documented, commission a Moodle health check before procurement. Discovering an unsupported plugin or unusual integration after signing can change both migration risk and price.
12 Questions to Ask a Moodle Hosting Provider
1. What Exactly Is Included in “Managed”?
Ask for a responsibility matrix covering Moodle core, plugins, themes, operating system, PHP runtime, database, web server, certificates, monitoring, backups and email delivery. It should state who performs each task, who approves it and who responds when it fails.
Then test the boundary with real scenarios. Who investigates a slow quiz? Who fixes a scheduled task that has stopped? Who checks a third-party plugin before an upgrade? Who helps an administrator correct a permissions problem? The answers reveal whether you are buying a complete Moodle service or a hosted server with limited application support.
Request a list of exclusions as well as inclusions. Ambiguous scope tends to become unexpected internal work or additional charges.
2. Who Will Operate the Moodle Platform?
Find out whether support reaches people with Moodle application expertise or only a general infrastructure desk. Ask who handles first-line triage, upgrades, database issues and complex plugin faults, and how cases move between those roles.
Useful evidence includes named service roles, escalation routes and examples of the team's Moodle responsibilities. Certifications and partnerships can add context, but they do not replace an explanation of who will work on your service and what they are accountable for.
Also ask how the provider covers leave and out-of-hours incidents. Your service should not depend on one knowledgeable individual, whether that person works for you or the supplier.
3. How Will You Size and Test Our Environment?
A credible provider should ask about workload, not just registered user count. Course design, reports, quizzes, scheduled jobs, large files, integrations and concentrated login periods can all affect demand.
Ask what assumptions underpin the proposed capacity and how performance will be measured before acceptance. For a busy or seasonal service, discuss load testing with representative journeys, database and cache design, storage performance, scaling thresholds and the notice needed for capacity changes.
Agree what happens if the initial sizing proves inadequate. A low starting quote is not good value if predictable usage immediately triggers unplanned upgrades or persistent slow pages.
4. How Do You Manage Security Updates and Change?
Moodle publishes security announcements with affected and fixed versions for disclosed issues. Ask which supported Moodle branch you will run, how the provider monitors those notices, and how it also tracks advisories for the operating system, PHP, database and third-party components.You need to know how security notices are monitored, how quickly risk is assessed, when urgent fixes can be deployed and how you will be informed. For planned upgrades, ask about staging, plugin compatibility checks, testing of critical learner journeys, approval, maintenance windows and a tested recovery route. Moodle upgrades can change the database, so “rollback” must not mean reverting application code alone.
Do not accept “we keep everything updated” as a complete process. Request the responsibilities, decision points and evidence that changes completed successfully.
5. What Are the Backup and Recovery Commitments?
Backup frequency is only one part of recovery. Ask what is backed up, where copies are stored, how access is controlled, how long versions are retained and whether backup failure creates an alert.
Agree two separate targets: the maximum period of data you could lose after an incident, commonly expressed as the recovery point objective, and the target time to restore service, commonly expressed as the recovery time objective. Make sure the contract says when those targets apply and whether they are commitments or aspirations.
Ask when the provider last tested a full Moodle restore and what the exercise covered. A recoverable Moodle site needs a mutually consistent database and Moodle data directory, plus the matching application code and securely managed configuration. The recovery set must preserve the installed plugin and theme versions and any custom code. Ask the provider to prove that the restored site serves uploaded files and completes critical learner and administrator journeys.
6. How Are Availability and Incidents Managed?
An uptime percentage is difficult to assess without its measurement rules. Ask which components are measured, how downtime starts and ends, which maintenance or third-party failures are excluded, and what remedy applies if the service level is missed.
Operationally, establish what is monitored, who receives alerts and which events prompt action outside normal hours. Request severity definitions, response targets, update frequency during an incident and the escalation path available to your service owner.
After a serious incident, will you receive a root-cause analysis and tracked corrective actions? Rapid restoration matters, but preventing a repeat matters too.
7. Where Will Our Data Be Stored, Processed and Accessed?
Ask for the countries used for production, backups, support access, monitoring and service administration. “Hosted in the UK” does not by itself explain every location from which data may be processed or accessed.
The NCSC's guidance on choosing a cloud provider recommends selecting an assessment approach according to the intended use and sensitivity of the data. Use its Cloud Security Principles, or its lightweight approach where appropriate, to structure questions about encryption, customer separation, identity, operational security, supply chains, administration and audit information.
Request evidence proportionate to your risk. A certificate name without its scope, exclusions or current validity tells you little about the Moodle service you are buying.
8. What Data Protection Terms and Sub-Processors Apply?
Confirm the parties' roles for each processing activity and involve your data protection lead before contract approval. The ICO's controller-processor contract guidance describes the information and minimum terms required by Article 28 of the UK GDPR; check the live guidance during procurement because it can change.
Ask how the contract covers documented instructions, confidentiality, security, data subject requests, breach assistance, audits, deletion or return at the end of the service, and the appointment of sub-processors. Obtain the current sub-processor list and the process for notifying you of changes.
Where international transfers may occur, ask your data protection adviser to review the proposed mechanism. Provider due diligence supports your compliance work; it does not replace your organisation's own assessment.
9. How Will You Handle Our Plugins, Theme and Integrations?
List every non-core component and identify its owner, exact version, source, supported Moodle, PHP and database versions, licence, business purpose and replacement route. Ask whether the provider supports it, merely permits it or requires it to be replaced.
Cover single sign-on, HR or student systems, ecommerce, virtual classrooms, content repositories, reporting tools and outbound email. For each integration, establish who monitors failures, manages credentials, tests changes and contacts the other supplier.
Ask how requests for new plugins are assessed for security, maintainability, privacy, performance and compatibility, and who will monitor upstream releases, test updates and replace an abandoned component. A provider that approves everything without review may create future risk; one that prohibits all change may block legitimate learning requirements.
10. What Is the Migration and Acceptance Plan?
Request a written plan covering discovery, target build, test migration, user acceptance, a controlled change freeze or final data synchronisation, cutover, communications and rollback. It should assign owners, dependencies and the authoritative data cut-off rather than present migration as a single upload.
Agree acceptance criteria before work begins. Reconcile agreed record counts and test critical courses, accounts and roles, enrolments, authentication, files, submissions, grades and completion, question banks, integrations, scheduled tasks, email, reports, accessibility-sensitive journeys and representative peak performance. Our Moodle migration guide provides a fuller planning framework.
Ask which migration activities are included in the hosting quote, what could change the price and how long the legacy environment must remain available after launch.
11. How Does Support Work in Practice?
Define who may raise a case, through which channels and during which hours. Compare response and restoration targets, not a promise of “priority support” with no measurable definition.
Give providers three example tickets: a learner cannot sign in, a business-critical report is wrong and the whole site is unavailable. Ask how each would be classified, investigated, escalated and charged.
Check whether your fee includes administrator guidance, configuration changes, plugin troubleshooting, training and service reviews. Ask for hourly rates or change-control rules for anything outside scope so the total cost remains predictable.
12. How Can We Leave Without Losing Control?
Exit terms are a procurement requirement, not a sign of mistrust. Confirm that you can obtain a recoverable full-site handover: a mutually consistent database dump and Moodle data archive, the matching Moodle core, plugin and theme code you are entitled to retain, customer-owned custom code, and the configuration needed to rebuild the service, transferred securely.
Ask about export formats, lead times, assistance fees, secure transfer, deletion confirmation and support for a replacement supplier. Course backup files may aid portability, but they do not replace the full-site handover. Identify any provider-owned theme, integration or automation that cannot move with you, and require a documented replacement route.
The contract should also explain what happens if service ends unexpectedly. A technically sound exit plan protects continuity, strengthens your negotiating position and makes future migration easier.
Compare Providers on Evidence, Not Presentation
Create a scorecard before supplier meetings and weight it to your risks. A practical structure might allocate:
- service scope and Moodle expertise;
- security, privacy and governance;
- resilience, backup and incident response;
- migration and technical fit;
- support and service management;
- exit and portability; and
- whole-life cost.
For every important answer, record the evidence, the contract reference, any exception and the person accepting the residual risk. Run the same realistic scenarios with each shortlisted provider. This makes a polished demonstration less influential than operational clarity.
Price the complete term, including migration, onboarding, storage or traffic bands, premium support, additional environments, change work and exit assistance. The cheapest compliant proposal may be the right choice; the cheapest headline fee may not be.
Warning Signs During Selection
Pause and investigate if a provider:
- cannot define the boundary between infrastructure and Moodle support;
- offers recovery targets without explaining restore tests;
- avoids naming hosting regions or sub-processors;
- promises to support every plugin without assessment;
- provides an uptime figure without measurement and exclusion rules;
- has no documented escalation or incident communication process; or
- makes data export dependent on an unspecified future fee.
No single answer proves that a provider is unsuitable. Repeated ambiguity, however, prevents you from knowing what risk you are accepting.
Turn the Questions Into a Contracted Service
The best Moodle hosting provider is not necessarily the largest or the one with the longest feature list. It is the provider whose service boundary, technical approach and evidence match your organisation's actual requirements.
Swift Learn provides managed Moodle services for organisations that want application expertise alongside hosting, maintenance and support. Bring us your requirements or current platform details and we will map them to a clear scope, flag migration dependencies and explain what would sit with us and what would remain with your team.
Request a managed Moodle consultation to compare your requirements with a practical hosting and support plan.Prof. Ada Montague is Swift Learn's Moodle Specialist. She advises organisations on Moodle architecture, configuration, migration, security and reliable learning-platform operations.