Managed Moodle hosting should bring server hosting, Moodle application maintenance and expert support together under one accountable service. A working installation is only the beginning. Your provider also needs to keep it secure, support your integrations and prepare it for the times when learners need it most.
Two proposals can both say managed hosting and cover very different work. Use this checklist to compare who owns the whole service, what support is agreed in writing and whether the team has the software engineering expertise to support your operation.
Bring infrastructure hosting and Moodle support together
It is easy to end up with one supplier who installs Moodle, another who hosts the server and nobody responsible for the complete learning platform. When something breaks, your team has to work out whether the problem belongs to the hosting company, the Moodle specialist or an integration supplier.
Ask whether your Moodle provider takes responsibility for both the infrastructure and the application. That means knowing how the servers, database and storage support Moodle, as well as understanding plugins, enrolment, course access and the workflows your team relies on. The provider may use a cloud infrastructure partner; the important point is that it manages that relationship and owns the investigation across both layers.
Get the responsibilities written into one service scope, with a clear escalation route. You should know who coordinates a fix, who communicates progress and which work is included. Your programme manager should not have to diagnose a server problem before getting help.
Make updates someone’s responsibility
Agree who monitors Moodle and plugin updates, assesses compatibility and schedules the work. Ask how changes are tested and how users will be told about planned interruption. A heavily customised site may need a different approach from a straightforward installation.
Useful questions include:
- Is there a staging environment for testing significant changes?
- Who checks the plugins and theme against a planned Moodle upgrade?
- What happens if an update causes a problem?
- Which upgrades are included in the ongoing fee?
The answer should describe a process you can rely on, with clear ownership.
Ask about restoring a service as well as making backups
Moodle’s site backup guidance identifies the database, uploaded files and Moodle code as the main parts of a full site backup. A course export alone is not a substitute for a complete site recovery plan.
Ask how often backups run, how long they are retained, where they are held and whether restores are tested. Also agree how much recent work could be lost and how long recovery is expected to take. Those requirements should reflect your operation: a high-stakes assessment period may need different arrangements from a small self-paced course library.
Look for engineering expertise at peak demand
A total learner count is not a capacity plan. Explain the likely peaks: a new intake signing in together, a compulsory training deadline or a timed assessment. Include what those learners will be doing. Reading a lesson, submitting a quiz and joining a live external tool place different demands on the service.
Look for Moodle specialists with software and infrastructure engineering skills. They should be able to investigate slow database queries, configure caching, manage background jobs and identify bottlenecks in plugins or external services. Moodle’s performance guidance covers these dependencies and the additional considerations involved in scaling a site.
Ask the provider to explain how it would test your expected peak, monitor the learner experience and increase capacity when needed. Request a relevant example of a performance problem it diagnosed and fixed. A useful answer connects the technical work to your teaching calendar, with a plan for preparation, monitoring and incident response during critical periods.
Require a structured service level agreement
For a platform your organisation depends on, require a structured service level agreement (SLA). A block of support hours or an informal promise to help does not define what happens during an outage. A retainer can fund the work, but it needs explicit service commitments alongside it.
The SLA should set out:
- Scope and ownership: the infrastructure, Moodle components and integrations covered, plus customer responsibilities and exclusions.
- Support access: how to raise an issue, support hours and time zone, and the arrangements for critical incidents outside those hours.
- Incident handling: severity definitions, initial response targets, restoration objectives, escalation and progress updates.
- Availability: how it is measured, what exclusions apply, maintenance notification and the agreed remedies if commitments are missed.
- Recovery and review: backup and recovery arrangements, incident reporting, and how service performance and changes are reviewed.
Keep response and recovery separate. An acknowledgement means an issue has been received; it does not mean service has been restored. Agree any additional cover needed for an assessment window or major launch before that event.
For WebbLMS, read the Terms of Service alongside the Service Availability & Support overview. Together they describe the service scope, responsibilities, support approach, maintenance and recovery arrangements. Formal commitments and remedies sit in the accepted service agreement and supporting technical documentation; the public overview does not replace those documents.
Use these documents as the basis for a procurement conversation. Confirm the commitments for your proposed environment, including what is covered by ongoing support and what needs separate scope. Course administration, learning design and new development should be named explicitly if you need them.
Check security and access arrangements
Security needs ongoing ownership across the hosting environment and Moodle itself. Ask who manages administrator access, software patches, plugin reviews, monitoring and incident communication. Discuss where data is hosted, who can access it and how access is removed when someone leaves.
Ask how the provider assesses changes and connected systems. For an external AI service, for example, establish what learner or course data is sent, how access is restricted and who maintains the configuration. Software specialists should be able to explain these boundaries in terms your team can assess.
The free WebbLMS Moodle Security Scanner is a useful starting point for a site you own or are authorised to assess. It performs read-only external checks for issues such as HTTPS configuration, security headers, exposed files and visible version information. Bring the findings to your provider and ask who will investigate and address them.
The scanner cannot inspect authenticated permissions or internal server configuration. A good score is not a security certification or a substitute for patching, monitoring, tested recovery and a fuller assessment. Its value is in giving you specific findings to discuss and follow up.
Check integration expertise and your ability to leave
List the systems Moodle depends on: sign-in, student records, enrolment, payments, reporting, video and custom learning tools. Ask whether the provider can design, test and maintain those connections, rather than only install a plugin. Agree which system owns each record and who investigates failed synchronisation or missing access.
Ask how integration changes are tested, how failures are detected and how credentials and permissions are managed. The provider should coordinate with the other system’s owner when a problem crosses the boundary. These responsibilities belong in the agreed service scope.
Also agree how you would leave. Establish ownership of your data and custom work, the available exports, migration assistance, notice periods, charges and retention arrangements. Open-source software gives you options; usable backups and documented dependencies make those options practical.
A useful proposal gives you one accountable service, a clear SLA and evidence that the team can engineer and maintain the platform. Compare those commitments alongside price, with your busiest teaching periods and operational risks in mind.
Explore WebbLMS managed Moodle hosting or request service-level and technical documentation. Bring your teaching calendar, expected peak usage, plugins and integrations. We can work through the hosting, Moodle support and service commitments your organisation needs.
