Moodle Hosting RFP: A Requirements Checklist for UK Buyers

The short answer is that a good Moodle hosting RFP gives every bidder the same service boundary, workload facts, required outcomes, evidence requests, pricing format and acceptance rules. It makes proposals comparable without dictating an architecture that only one supplier can provide.

Do not start with a long feature list. Start with the learner journeys that cannot fail, the responsibilities you want to transfer and the risks your organisation will retain. Mark genuine pass-or-fail requirements, score the rest, and require bidders to identify assumptions and exceptions beside every answer.

This guide is for UK learning, IT and procurement teams preparing a request for proposal, invitation to tender or structured quote for managed Moodle. It complements our questions for a UK Moodle hosting provider: that article helps with supplier conversations; this one shows how to build the procurement pack those suppliers must answer.

What Should a Moodle Hosting RFP Include?

A priceable and scorable RFP needs eight connected sections:

1. organisational context and procurement objectives;
2. a factual baseline for the current Moodle service;
3. outcome-based hosting and support requirements;
4. migration, transition and acceptance scope;
5. service levels, recovery and governance;
6. security, data protection and assurance evidence;
7. a common commercial response and exit model; and
8. the evaluation method, timetable and contract documents.

Swift Learn's judgement is that the baseline and responsibility matrix do more to improve proposal quality than pages of generic technical questions. If bidders cannot see the present estate or who owns each task, they must either price a large contingency or submit an attractive figure built on assumptions.

1. State the Outcome and Procurement Boundary

Open with the reason for the procurement. Are you replacing an expiring host, moving from self-hosting, consolidating several sites, improving resilience or combining infrastructure with Moodle application support? State the planned contract term, target start date, procurement contacts and approval route.

Describe the outcomes in operational language. Examples include keeping mandatory training available during shift changes, completing a migration before an academic intake, reducing internal on-call dependency or gaining a tested recovery service. These outcomes help a bidder make sensible trade-offs when several designs could meet the requirement.

Then draw the boundary. Say whether the procurement covers production only or also staging, test and training environments. Identify whether you expect hosting, Moodle administration, updates, plugin support, service desk, development, learning design or content work. Do not use “fully managed” as a substitute for this list.

2. Give Bidders a Reliable Moodle Baseline

Provide the same discovery information to every supplier. At minimum, include:

• current Moodle edition and exact version, plus the intended upgrade position;
• registered, monthly active and peak concurrent users, with known seasonal peaks;
• database and Moodledata size, file growth and retention needs;
• theme, plugins, custom code and ownership or licence constraints;
• authentication, email, HR, student-record, ecommerce and virtual-classroom integrations;
• scheduled tasks, reporting workloads and other unusually heavy processes;
• present environments, hosting regions, monitoring and backup arrangements; and
• known defects, unsupported components, performance concerns and fixed deadlines.

Use ranges where forecasts are uncertain, but explain the scenario behind each range. “Twenty thousand users” is not a sizing profile: twenty thousand registered accounts with 300 active in a normal hour differs materially from a compliance launch that sends thousands of people to one quiz.

Attach an anonymised architecture diagram, plugin inventory and recent usage evidence where available. Offer a controlled clarification or discovery stage for shortlisted bidders if the estate is poorly documented. Concealing complexity rarely protects the buyer; it moves uncertainty into price or change control.

3. Write Requirements as Outcomes, Priorities and Evidence

Give every requirement an identifier and ask bidders to respond in a fixed format: compliant, partially compliant, not compliant or alternative proposed. Require an explanation, evidence reference, dependency, exception and price impact for each response.

Separate three classes clearly:

• mandatory — failure excludes a bid because the need is legal, operational or genuinely non-negotiable;
• scored — stronger evidence or service earns more points; and
• informational — useful for due diligence but not scored.

Keep the mandatory list short. Making every preference mandatory hides the decisions you actually need to make and can remove credible suppliers for no reduction in risk.

Avoid specifying fashionable infrastructure components unless interoperability or internal policy demands them. “Restore the agreed learner service within four hours after a qualifying disaster” describes an outcome. “Use a particular orchestration product” prescribes a solution and transfers design judgement back to the buyer.

Include the Supported Moodle Stack

Require the provider to state the proposed Moodle branch, PHP and database versions, the support lifecycle for each, and how it tests upgrades. Moodle's official 5.3 release requirements, checked on 26 October 2026, identify Moodle 5.3 as an LTS release dated 5 October 2026 and set minimums including PHP 8.3, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or Microsoft SQL Server 2019, depending on the chosen database.

Those figures are a dated compatibility reference, not a reason to demand Moodle 5.3 from every bidder. Your current plugins, upgrade path and change window may justify another supported branch. The RFP should ask the supplier to reconcile its proposed stack with Moodle's live requirements and to own a supported route forward.

4. Add a Responsibility Matrix

List the recurring and incident tasks, then make the bidder assign responsible, accountable, consulted and informed roles. Cover at least:

• infrastructure, operating system, database and certificates;
• Moodle core, plugins, theme and custom code;
• vulnerability review, patching, upgrades and regression testing;
• monitoring, scheduled tasks, capacity and performance;
• user administration, course configuration and administrator guidance;
• identity, integrations, email and third-party escalation;
• backups, restores, disaster recovery and incident communications; and
• privacy requests, security incidents, audit evidence and service exit.

Test the matrix with scenarios. If a quiz becomes slow, who determines whether the cause is course design, PHP capacity, database behaviour or a plugin? If single sign-on fails, who gathers evidence and contacts the identity supplier? A matrix that cannot answer those questions is not yet a service boundary.

5. Define Migration and Acceptance Before Pricing

Ask for discovery, test migration, remediation, rehearsal, final synchronisation, cutover, rollback, communications and hypercare as separate activities. State which content and records must move, how long the legacy service remains available and who owns fixes to current data or plugins.

Create acceptance criteria before contract award. These can include reconciled user, enrolment, completion and grade counts; successful access to sampled files and courses; authentication and integration tests; completion of critical scheduled tasks; representative performance tests; accessibility-sensitive journeys; backup verification; and administrator handover.

Name the evidence that closes each criterion and the treatment of minor defects. A vague promise to “migrate the site” invites disagreement about completion, while an unnecessarily exhaustive test suite increases cost and delays launch. Focus acceptance on material learner, administrator and reporting journeys.

6. Make Service Levels and Recovery Measurable

Specify learner-facing availability, agreed service hours, monitoring method, maintenance rules and exclusions. For each incident priority, distinguish skilled response, update frequency, service restoration and permanent resolution. Our Moodle hosting SLA buyer's guide explains how to make these measures auditable.

State recovery point and recovery time objectives for realistic incident classes rather than requesting “daily backups”. Require the supplier to explain backup scope, retention, separation, encryption, monitoring and restore testing. Use our Moodle backup and disaster-recovery guide to define the evidence behind those commitments.

Tighter targets cost more and may require reserved capacity or out-of-hours specialists. Ask bidders to price a base requirement and clearly described options where the business has not yet valued the difference. That exposes the cost of risk reduction without encouraging suppliers to quietly dilute the target.

7. Request Security and Data Evidence, Not Assurances

Turn security statements into evidence requests proportionate to the service. The NCSC's 14 Cloud Security Principles, version 2.1 reviewed 7 June 2023 and checked on 26 October 2026, cover areas including data protection, resilience, customer separation, operational security, supply chains, identity, administration and audit information. Use the relevant principles to structure the response, but let bidders explain how their controls meet the goals.

Ask for the scope and current validity of certifications or independent tests, not just their names. Request hosting and backup locations, privileged-access controls, logging, vulnerability and change processes, incident notification, the sub-processor list and the evidence customers receive.

Where the provider processes personal data, include a data-processing schedule. The ICO's processor contract guidance, checked on 26 October 2026, lists minimum Article 28 terms covering documented instructions, confidentiality, security, sub-processors, rights assistance, end-of-contract provisions, audits and inspections. The ICO also says this guidance is under review following the Data (Use and Access) Act, so obtain current legal or data-protection advice before signature.

8. Normalise Price, Assumptions and Exit

Provide a pricing schedule that separates implementation, migration, recurring service, usage bands, optional environments, premium support, storage or traffic growth, change work and exit assistance. Require VAT treatment, indexation, minimum commitments and third-party licence costs to be explicit.

Ask for a three- or five-year scenario using the same growth assumptions. This is not a prediction; it is a comparison tool. A low first-year fee can be poor value if routine growth, staging, upgrades or essential support sit outside the price.

Define exit deliverables: a consistent database and Moodledata handover, the matching code and configuration you are entitled to receive, customer-owned customisations, documentation, credential transfer, secure deletion evidence and transition support. State the required format, timing and pricing basis. Portability has to exist in the contract before you need it.

Use a Transparent Evaluation Model

Publish the high-level method and use it consistently. One reasonable starting point is:

Adjust the weights to your risks and procurement rules. Score only what bidders were asked to provide. Use anchored definitions—for example, zero for no evidence, a middle score for a credible documented process and the highest score for service-specific evidence with clear ownership.

Run clarification meetings against the same scenarios and record any answer that changes the bid. Commercial value should be evaluated after scope is normalised; otherwise a missing responsibility can look like a saving.

Moodle Hosting RFP Red Flags

Pause before award if a proposal:

• accepts every requirement but records no assumptions or dependencies;
• prices user numbers without asking about concurrency or workload;
• calls the service fully managed but leaves Moodle application tasks unassigned;
• promises migration without discovery, rehearsal or acceptance evidence;
• offers response times without restoration targets or escalation;
• states recovery objectives without recent restore-test evidence;
• names certifications without their scope or validity;
• hides essential services in undefined change charges; or
• promises easy exit without specifying a recoverable handover.

An exception is not automatically a weakness. A bidder that identifies a conflict and proposes a safer alternative may be more credible than one that marks every line compliant. Evaluate the effect on your outcome, risk and whole-life cost.

The Swift Learn Verdict

The best Moodle hosting RFP is not the longest specification. It is the one that lets capable providers understand the same problem, expose their assumptions, price the same boundary and prove how their service will work.

Give suppliers facts rather than guesses. Separate mandatory outcomes from scored preferences. Make ownership, migration acceptance, service levels, security evidence, total cost and exit visible before award. That produces a decision you can defend and a stronger starting point for the contract.

Need Help Shaping a Moodle Hosting RFP?

Bring us your current platform inventory, learner-critical periods, draft requirements and procurement constraints. Swift Learn can help you map the service boundary, identify migration and support risks, and turn them into a managed Moodle specification providers can answer clearly.