How to run an LMS RFP with open-source platforms
A team that needs a learning platform it controls has to choose between Moodle, Canvas and Open edX, and then pick an implementation partner. This section gives the questions to put in that RFP, what a good answer looks like, and the red flags that should slow a decision down. The core rule is simple: compare partners on evidence, such as named architecture decisions, upgrade records and written support terms, rather than on the quality of a demo environment. Moodle is licensed under GPL-3.0, Open edX under AGPL-3.0 and Canvas LMS under AGPL-3.0, so none of the three carries a license fee to negotiate. The comparison is therefore about implementation, hosting, integrations and support, and the RFP should say so in its first pages to keep bidders from pricing around software licensing.
Issue the RFP with a short description of learner numbers, peak periods, content types (SCORM, LTI, video and any xAPI sources), identity sources, data residency rules and the accessibility standard your organization must meet. Ask each bidder to name the people who will answer for architecture, security, support and migration, and to confirm that those individuals will be on the engagement. Ask for the proposed platform and version, the upgrade policy and the hosting model in writing. Most engagements are fixed-scope, so a quote follows from the written scope and from the deliverables and timelines agreed before work starts. DeployOpen does not publish prices, so ask every bidder, including DeployOpen, for a quote built from the same scope document.
Which questions to ask each partner, and what a good answer contains
Should we choose Moodle, Canvas or Open edX for our LMS?
The right platform depends on your learner volume, content types, integrations and who will own administration, so ask each partner to recommend one and justify it against your requirements. A complete answer names the exact version proposed, explains the licensing model (Moodle and Open edX are both open source, and Canvas LMS is licensed under AGPL-3.0), and addresses your support window. Ask for the reasons a platform was rejected, not only the one recommended. Request a written comparison covering content formats, plugin needs, hosting and staffing. Moodle 5.3 is the next long-term support release, with security fixes until October 1, 2029. Open edX supports only its latest named release, so a partner should explain how that cadence fits your budget cycle.
How will existing courses and training records be migrated?
A credible partner separates course content, learner accounts, enrollments, grades and completion records, because each moves differently and carries different evidence risks. Ask for the source platform and version, the export method, a field-level mapping document, and a sample migration run on a copy before cutover. The answer should state who validates completion dates and grade totals after import, and how discrepancies are logged. Confirm which SCORM packages are tested on the target version and what happens to content that depends on external calls. Request the rollback procedure and the retention approach for the legacy system.
Which LTI tools and content standards are supported, and how are they tested?
A strong answer lists each LTI tool by name, the LTI version it uses, and the test result on the exact platform version you will run. Ask whether LTI Advantage is supported and how grade passback is verified. Open edX Verawood lists LTI Advantage Complete certification, but your tools must still be tested against your own configuration. For SCORM, request the version (1.2 or 2004) and a list of packages that were run end to end. Ask for xAPI handling through a learning record store if you need it. Request a written test matrix and the owner of any tool that fails.
How do Moodle 5.1 and 5.3 requirements affect our hosting and upgrade plan?
Ask the partner to state the PHP version, database engine and web server configuration for the exact Moodle release. Moodle 5.1 requires 64-bit PHP 8.2 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17 or MariaDB 11.4 and sites on Moodle 4.4 or later. From Moodle 5.1, the web server document root must point to the /public directory, otherwise the site may show directory listings or errors. A good answer includes a server build sheet, a configuration checklist and a test of the document root change. Confirm the cost of each component and who pays for licenses, if any apply.
For Open edX, do you deploy with Tutor or through a service provider, and who supports production?
The edx-platform maintainers recommend production deployments through a service provider or with Tutor, and they note that bare-metal installation is complex with limited community support. Ask whether the partner uses Tutor, which runs on Docker and supports Kubernetes, and which plugins are included. Request the Open edX release, the Tutor version, the infrastructure diagram, and the list of services such as MySQL, MongoDB, Redis or Memcached. The answer should explain who patches the platform each time a new named release ships and who is accountable if an upgrade fails. Ask for a written support boundary.
How is peak exam load tested and handled?
A complete answer gives the expected concurrent learners at the busiest point, the load test scenarios, the tooling used, and the results on the platform version you will run. Ask how caching is configured, since multi-node Open edX deployments need a shared Django cache backend such as Redis or Memcached. Request the autoscaling or capacity plan, database connection limits, and the monitoring and alerting setup. The partner should name who runs the test, how often it is repeated after upgrades, and what changes if an exam window grows. Ask for the cost drivers in writing, including hosting for peak capacity that may sit idle the rest of the year.
What learner and admin support is included, and what is excluded?
Most engagements are fixed-scope, so the written scope should state which support tasks are delivered, which are optional, and which are outside the agreement. Ask for the hours covered, the channels, the response categories and the escalation path to the platform vendor or community. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and a quote follows from the written scope. Request a runbook for common learner issues such as password resets, enrollment errors and certificate failures, and confirm who writes and maintains it. Ask for the exclusions in writing, including instructor-made content and third-party plugin defects.
Partner answers that should stop the evaluation
Vague answers to LMS RFP questions usually share one cause: the partner has not inventoried the platform, the content, the tools or the support scope. Each card below names an answer that should slow or stop the evaluation, why it matters, and what to ask for instead.
No named platform version or upgrade path
A proposal that says "latest Moodle" or "our open source LMS" without a version gives you no way to plan. Moodle 5.1 and 5.3 have different PHP, database and upgrade prerequisites, and Open edX supports only its latest named release at a time. Ask which exact version is proposed, why it was chosen over Moodle or Open edX alternatives, which version it will move to next, and what the upgrade path from your current system requires.
Migration promised without an inventory
Promising to move courses and records without first listing them is a common source of lost completion history. Ask for an inventory of course types, SCORM packages, question banks, user records, grades and completion logs, with owners and retention rules for each. A credible answer describes how the partner will test a sample migration, reconcile record counts and sign off on what did not move.
LTI tools claimed without a list
Saying that LTI integrations work without naming them is not a test. Each external tool needs its version, LTI version, launch and grade passback behavior, and data flows checked against your own environment. Ask for a written list of every tool in scope, a test plan that covers launch, grading and deep linking, and a note on which tools the partner cannot support or has not tested.
Peak load answered with uptime
A generic availability percentage says nothing about exam-day concurrency or a mandatory training deadline. Ask for the expected peak concurrent sessions, the hosting design for web, database, cache and file storage at that peak, and the results of a load test run against that profile. Ask also whether the test covers quiz submission and video delivery, since those drive the heaviest peaks.
Upgrades treated as an annual event
When upgrades are scheduled once a year with no named owner, security patches and plugin compatibility lag behind. Moodle issues point releases on a bimonthly cadence and the Moodle 5.1 release notes require the web root to change to the public directory, so an upgrade is a technical change, not a calendar item. Ask who owns patching, who tests plugins before each release, and how staging and rollback are handled.
Support without response scope
"24/7 support" is not a service definition. Ask which issues are covered (platform defects, plugin conflicts, content errors, learner account problems), which are excluded, who answers learners versus administrators, and what response windows apply for each severity. Ask also whether support extends to third-party tools and to content your instructors or training teams author.
Compliance outcomes guaranteed
No implementation partner can guarantee an accessibility audit result or a regulator's acceptance of training records. Accessibility under the ADA Title II rule and records under regulations such as 21 CFR Part 11 depend on your content, your procedures and independent assessment. Ask for the evidence the partner prepares, such as WCAG 2.1 AA test results, theme and plugin audit reports and configuration records, and confirm with your auditor which of those artifacts they will accept.
How to score partner responses
This table turns partner answers into comparable scores across eight criteria that matter for an LMS rollout. Score each criterion from 0 to 3 using the evidence the partner provides, then weight the criteria to match your own priorities before comparing bids. The main takeaway is that a high score should require tested evidence, such as a migration sample or a recorded LTI launch, not a confident written answer.
| Criterion | What a score of 3 looks like | Evidence to request |
|---|---|---|
| Platform fit and reasoning | Partner ties Moodle, Canvas or Open edX to your learner volume, content types, integrations and staff skills, and names trade-offs | Written rationale, named alternatives considered, and a reference to your requirements list |
| Migration method and evidence | Repeatable process for courses, SCORM packages and completion records, with validation counts and a rollback path | Sample migration report from a comparable dataset, reconciliation method, and sign-off steps |
| Integration coverage and tested flows | LTI tools, identity providers and HR or student systems are listed with test results, including launch and grade return | Test scripts, recorded LTI Advantage launches, SSO test logs and a named integration owner |
| Peak load and hosting design | Concurrency targets are sized from your exam or training calendar, with load tests and scaling settings written down | Load test plan and results, sizing assumptions, database and cache design, and monitoring thresholds |
| Upgrade and LTS plan | Written path to each supported release, with a test environment, a change calendar and a rollback plan | Upgrade runbook, support window for your chosen release, and plugin compatibility review method |
| Support model | Defined learner, admin and developer support hours, escalation levels and response targets stated in writing | Support catalog, sample ticket workflow, staffing model and any retainer terms |
| Security and evidence practice | Hardening baseline, access control design, audit logging and an evidence pack mapped to your compliance duties | Hardening checklist, sample evidence set, vulnerability handling process and data location statement |
| Commercial clarity of written scope | Scope, deliverables, exclusions, acceptance criteria and timelines are agreed in writing before work starts | Draft statement of work, itemized assumptions, change request process and named owners |
Steps to run the LMS RFP with a shortlist of partners
This sequence moves a shortlist from written answers to a fixed-scope statement of work, with each step producing evidence your team can check before any contract is signed. It keeps platform choice, migration, integrations, load and upgrades in view from the first round.
Issue requirements and the question set
Your project lead sends the requirements and the RFP question set to each shortlisted partner at the same time, covering the platform choice (Moodle, Canvas or Open edX), learner and peak concurrency, content types such as SCORM or LTI, identity, HR or student system links, reporting, and hosting. Ask each bidder to state which platform version they would deliver and why. The step is done when every bidder has confirmed receipt and a named contact for questions.
Collect written answers with named versions
Partners return written answers that name the exact platform version, PHP and database versions, and plugins they propose. Compare answers against the release facts: for example, Moodle 5.3 requires PostgreSQL 17 and sites must run Moodle 4.4 or later to upgrade, and Open edX supports only the latest named release. Your security and procurement leads sign off on the answer set, and any answer without a version is returned for correction.
Run a technical session on the migration sample
Give each shortlisted partner a sample export of courses, enrollments and completion records, then hold a working session where they walk through how they would map content, users and grades into the target platform. Ask them to show how SCORM packages and LTI tools would behave after the move and what they would not migrate. The output is a written migration method and a list of known gaps, signed off by your learning operations owner.
Confirm integrations in a live review
Ask each partner to demonstrate or document the identity method (for example LDAP, SAML, OAuth 2 or Shibboleth), the LTI tools in scope, and the data flows to HR or student information systems. Confirm which items are core platform features and which need third-party plugins, and who maintains each plugin after go-live. Your identity lead signs off on the integration list and the open risks.
Request a load test plan and upgrade walkthrough
Request a written load test plan that uses your peak exam or training window, the hosting design for that peak, and an upgrade plan that covers the next long-term support release and how the partner would stage it in a test environment first. Ask for the procedure for the web server document root change that Moodle 5.1 requires and for the handling of lapsing release support. The step closes when your infrastructure owner has reviewed the test plan and the upgrade path.
Check support scope in writing
Ask each partner to state, in writing, what learner support, administrator support, incident response hours, patching, backups and upgrades are included, and what is charged separately or sold as a retainer. Confirm how exam-period support is handled and who answers the phone or ticket at the learner level. Your service owner signs off on a support matrix that a contract can reference.
Convert chosen answers into a fixed-scope statement of work
Turn the accepted answers into a fixed-scope statement of work that lists the platform and version, migration scope, integrations, load test, upgrade approach, support terms, deliverables and acceptance criteria. Agree the timeline and payment milestones in writing before work starts, since most engagements are fixed-scope. The step is complete when your legal, procurement and business owners have signed the statement of work and the partner has confirmed the same version list.
What to confirm with your own team before sending the RFP
Before the RFP goes out, establish the inputs that every vendor answer depends on. Start with learner counts and peak concurrency: the number of enrolled users is not the number that matters for hosting. Work out how many learners will sign in during the same hour, especially during exam windows, certification deadlines or mandatory compliance rounds. Record these figures as ranges with the dates they apply to, because a vendor sizing for average load will answer differently from one sizing for an exam peak. Also confirm the identity provider in use (Azure AD, Okta, an LDAP directory or a SAML federation) and who owns it, since SSO, provisioning and deprovisioning questions cannot be answered without it.
Next, document the systems that feed the LMS. Identify the HR system or student information system that is the source of truth for enrollment, role and job changes, and decide whether accounts are created by SCIM-style sync, scheduled file imports or manual upload. Inventory the content types you already own: SCORM packages and their version, xAPI statements, LTI tools, and video files with their hosting location. Ask which of these must keep working after migration. Content that only runs on a retired authoring tool is a migration cost that belongs in the scope, not a surprise after award.
Then settle the non-technical constraints. Confirm where learner records may be stored and who may access them, because data residency and sovereignty rules will determine whether a managed host in another region is acceptable. Write down your accessibility obligations and the standard they reference, and whether the content owners or the platform owner are responsible for remediation. Finally, define your internal upgrade policy: how long you can stay on a release, who approves a major version change, and how much testing time you can allocate. Ask each vendor to state their assumptions on all of these inputs in their response, so that quotes and support commitments can be compared on the same basis.
How the questions shift for education, enterprise training and government
Schools and universities ask the same platform questions as everyone else, but student records and accessibility duties move several of them to the top. Learner data may be education records, and course content, themes and plugins must meet accessibility expectations that apply to the institution's own web content. Peak load also arrives in predictable bursts during enrollment and exam periods, which makes load planning a central question rather than a footnote.
- Student data privacy: Ask which learner data the platform stores, who can access it by role, and whether the partner can act under the institution's agreements for student data.
- Accessibility ownership: Confirm who remediates instructor-made content, and ask for a theme and plugin accessibility audit scope in writing.
- Exam-period load: Ask how concurrency is tested for the heaviest week of the term and what scaling changes are made before it.
- LTI tool ecosystem: List the tools faculty use today and confirm each one supports LTI and the data it exchanges.
- Student information system links: Ask how rosters, enrollments and grades move between the SIS and the LMS, and who owns those mappings.
Check these questions against the education sibling topics on FERPA, ADA Title II accessibility and academic delivery before you finalize the RFP.
Banks, insurers, healthcare providers and energy companies use the LMS as evidence. Completion records, certification expiry dates and the link between a course and a role or policy matter as much as the learning experience. These buyers should ask how records are kept, how they are retained, and how an auditor can confirm who completed what and when.
- Audit evidence: Ask which completion records the platform keeps, whether they can be exported with timestamps and version history, and how the partner prepares them for an assessment.
- Retention: Confirm the retention period your regulator or policy requires and how the platform and backups will enforce it.
- Role-based assignment: Ask how courses map to job roles, how reassignment happens after a role change, and how recertification is scheduled.
- HR and identity integration: Ask how the platform receives joiner, mover and leaver data and how single sign-on is configured.
- Change control: Ask how upgrades and plugin changes are documented so that training records remain consistent across versions.
For specific regimes, compare these questions with the sibling topics on financial services, healthcare, energy and utilities, and PCI DSS or NIS2 training. Ask the partner which controls it prepares evidence for and which remain your responsibility.
Government workforces and public-facing learning programs carry accessibility law, sovereign hosting expectations and budget cycles that shape the platform choice. Procurement often runs on fixed budget periods, so support windows and the upgrade path become as important as the first build. Large citizen or staff populations also bring identity integration at scale.
- Support windows: Compare the published support periods for each candidate release. The Moodle releases page lists general and security support dates for each version, so match them against your budget cycle. Open edX supports only its latest named release, which changes the upgrade planning.
- Accessibility deadlines: Confirm which ADA Title II WCAG 2.1 Level AA compliance date applies to your entity and who owns course and theme remediation.
- Large-scale identity: Ask which authentication methods are supported and how directory synchronization handles a large user population.
- Hosting location: Ask where the platform, backups and support access run, and whether any third-party service transfers data outside the agreed jurisdiction.
- Procurement terms: Ask how the partner's fixed-scope proposal handles upgrades, support and exit, and what is included in each.
Check these items against the public sector sibling topic on accessibility, sovereign hosting and procurement before the RFP is issued.
Defense sites, critical infrastructure and organizations with strict data residency need an LMS that runs without external calls or inside a specific jurisdiction. The questions move from features to delivery mechanics: how the software arrives, how content is loaded, and how upgrades cross the gap. Each dependency on an outside service becomes a risk to document.
- Offline installation and updates: Ask how packages, plugins and security patches are transferred into the disconnected network and how each transfer is verified.
- Content without external calls: Confirm that SCORM packages, video and third-party tools do not reach outside services during delivery.
- Internal identity: Ask how local directories and authentication are configured without cloud identity providers.
- Upgrade across the gap: Ask for a written upgrade procedure that covers release notes, dependency changes and rollback, and confirm which releases can be carried across.
- Sovereign data handling: Ask which AI, analytics or video services are enabled by default and how each is disabled or hosted locally.
Confirm these requirements with the air-gapped and EU data sovereignty sibling topics, and ask the partner to demonstrate the offline update process in a test environment before you commit.
How much does an LMS implementation partner cost and how long does it take?
Moodle, Canvas and Open edX carry no license fee for the core platform, so the cost of an LMS implementation partner is almost entirely services and infrastructure. Moodle is licensed under GPL-3.0 and Open edX under AGPL-3.0, and the Canvas LMS code is AGPL-3.0, so the money goes to the people and servers that run the platform, not to the software itself. Expect the quote to break into five components: hosting sized for peak load, setup and theming, identity and HR or student information system integrations, content and record migration, and upgrades with support. Each one has a different payer and a different rhythm, so ask the partner to price them separately. DeployOpen works under fixed-scope agreements, so scope, deliverables and timelines are written down before work starts and the quote follows from that written scope rather than from a rate card.
Separate one-time work from recurring work in the written scope. One-time items usually include architecture and environment build, identity and HR integration, theme and plugin configuration, content migration and validation, load testing and cutover. Recurring items include hosting and backups, monthly or quarterly security patching, major upgrades on the vendor's release calendar, and learner and administrator support. For Moodle, ask the partner to map the upgrade path against the release dates in the Moodle releases documentation and the PHP and database minimums for the target version, since those prerequisites often change the hosting bill. For Open edX, ask how the team will follow named releases, because only the latest named release is supported. The buyer provides the identity provider, HR or SIS data feeds, legacy course exports, DNS and certificates, cloud or data center accounts, and named owners who can approve decisions quickly.
Before you sign, ask the partner which parts your team can run itself, such as content authoring, course catalog maintenance or first-line administrator tasks, and which parts must stay with the partner. Request a quote that lists each assumption, including the number of concurrent users used for load testing, the number of courses and content objects to migrate, the number of integrations, and the support hours covered. Ask for the duration in the form of named milestones with entry and exit criteria, not a single end date, and confirm how change requests are priced if the scope moves. Ask for a written statement of what is excluded, such as third-party plugin licensing, video hosting or external content services. If a figure is not in the proposal, ask the partner to state it and cite the source of its estimate.
How DeployOpen scopes, delivers and supports LMS evaluations and implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For LMS RFP questions, we turn your requirements into written answers about platform choice, migration, integrations, peak load and upgrades before any build work starts.
How we scope
- Review your RFP questions against your learner counts, peak exam or training windows and course types
- Document which Moodle, Canvas or Open edX answers are supported by the vendor's published release and support policy
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope
How we build
- Set up a hosted environment in your own infrastructure with load testing sized to the peak concurrency you specify
- Prototype migration of a representative sample of courses, enrollments and completion records and check them against the source
- Configure the LTI tools, identity connections and reporting you listed, and test each one end to end
How we hand over
- Deliver architecture notes, configuration records, runbooks and an upgrade plan written for your own administrators
- Provide test results for load, migration reconciliation, integrations and accessibility checks in the agreed scope
- Walk your team through the handover so admins can operate the platform without relying on a single person
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, priced from the agreed scope
- Plan each major and long-term support upgrade against the vendor's published support windows and document the steps
- Confirm with us during the RFP which learner and administrator support levels are included in the written scope
