Course platform RFP questions

A strong answer ties the choice to your course model, not to a feature list. Open edX is built for structured course authoring, cohort-style delivery and a React-based learner experience, and its code is licensed under AGPL-3.0. Moodle is a general learning platform licensed under GPL-3.0, with a long history in institutional teaching and a large plugin ecosystem. Ask the partner to name the components each option needs: for Open edX, the LMS, Studio and a Tutor-based deployment; for Moodle, the PHP stack and the database it will run on. Expect a written comparison covering authoring workflow, certificates, payments and staffing. Ask who maintains the chosen release and what happens when the named release changes, since Open edX supports only its latest named release at a time.

A strong answer names the enrolment-on-payment path and the payment provider before any build work starts. In Moodle, paid enrolment can use core payment gateway support or a plugin gateway, and a storefront such as WooCommerce can sit in front of it. In Open edX, payments are typically handled through an external storefront or a plugin, so the partner should show the exact integration. Ask for a written list covering tax calculation, invoicing, coupons, refunds and how enrolment is granted after a successful payment. Confirm who holds the payment provider contract and where card data is handled, because that decision sets your PCI DSS scope. Your team must supply tax rules, merchant accounts and the list of countries you sell to.

A strong answer separates where video files are stored, how they are delivered, and who can watch them. The partner should describe the storage location, the streaming or CDN layer, access control tied to enrolment, and the fallback when a learner is in a low-bandwidth region. Ask whether video stays on your infrastructure, moves to a managed video service, or is embedded from a provider, and what each choice does to learner data and cost. Request a written estimate of storage and egress drivers based on your hours of content and expected viewers, not a generic figure. Confirm who manages transcoding, captions and the content delivery configuration after launch, and what the buyer must provide, such as source files and caption files.

For Open edX, a strong answer describes the Aspects analytics stack: tracking logs captured through the event-routing-backends plugin as xAPI statements, stored in ClickHouse via Ralph or Vector, and presented in Superset dashboards. For Moodle, it should name the built-in reports and any reporting plugins or external warehouse it proposes. Ask which reports are delivered at launch, who defines the metrics for completion and engagement, and where the data is stored and who can query it. Confirm retention periods and access roles with your privacy and legal team before build starts. The buyer should provide the list of decisions the reports must support, such as completion for accreditation or drop-off by module.

A strong answer starts with the release policy. For Open edX, the partner should explain that the latest named release is the only supported release, that Verawood is the current named release, and that Willow (December 2026) and Xylon (June 2027) are the planned next releases. For Moodle, it should explain that 5.3 is the long-term support release, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, and state the minimum version your site must run before upgrading (Moodle 4.4 or later for 5.3). Ask for a documented upgrade runbook, a staging environment, a test plan that covers course content and certificates, and a rollback procedure. Confirm which party pays for each upgrade, and whether upgrades are included in a retainer or quoted per release.

A strong answer lists the operating roles with names: platform operations for hosting, databases and backups, application support for course and theme issues, security patching, and content or course administration done by your team. Ask the partner to state which roles it covers under a retainer and which stay with you. Confirm the hosting location, monitoring, backup schedule, incident response hours and the process for security patches. Recurring costs typically include infrastructure, video delivery, licenses for any plugins, support retainers and upgrade work; ask for each as a separate line in the quote. Clarify whether you can operate the platform yourself later, and what documentation, runbooks and access handover the partner will deliver at the end of the engagement.

Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask DeployOpen to show which parts of the platform it will build, which it will configure, and which it will leave to your team. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report.

A strong answer covers the application, its APIs, the infrastructure and the integrations. For a course platform, that means testing the learner login flow, the payment handoff, enrolment and certificate endpoints, and access controls for paid content and video. Ask whether the partner will run application and API testing, cloud and infrastructure testing, and whether it includes any AI features your platform enables. Confirm the scope in writing, the test environment, how findings are reported and retested, and who signs off before go-live. The buyer should provide the list of integrations, identity providers and payment flows that are in scope, and a named owner to accept fixes.

The written scope drives the cost more than any single product choice. The main components are the discovery and architecture work, the installation and hosting setup in your own cloud or data center, theming and customization, integrations with payments, identity and student systems, data migration, security hardening, testing, and handover documentation. Hosting and third-party services such as video delivery, email and payment gateway fees are usually billed by their providers and recur. Ask any partner to separate one-time implementation fees from recurring hosting, support and upgrade costs, and to state which third-party charges are excluded. DeployOpen does not publish a price list. A quote follows from the written scope.

The duration depends on the scope agreed in writing before work starts, so there is no standard timeline to quote here. The factors that most often extend it are the number of integrations, the number of identity providers, the amount of theming, the volume of content and learner data to migrate, the number of payment and tax rules, and the approvals needed for hosting and security review. Ask for a phased plan with named milestones, the decisions the buyer must make at each one, and the acceptance tests that close each phase. Also ask how the partner handles scope changes after signature.

A partner needs a clear picture of your environment and your decisions before design begins. Typically this includes a named business owner, access to the cloud account or data center where the platform will run, the identity provider details and metadata for single sign-on, the payment and tax requirements, the branding assets, the list of courses and content formats to migrate, and the reporting questions your leadership needs answered. Security and compliance contacts should review hosting, data location and logging decisions early. Confirm with the partner which of these items are included in the fixed scope and which the buyer must provide.

Yes, if the team has the skills and the time, but the workload is real and should be sized before launch. Open edX and Moodle both need routine work: applying security fixes, upgrading to supported releases, managing databases and caches, monitoring, backups, restore tests, plugin compatibility, and support for instructors and learners. Open edX states that only the latest named release is supported, so the upgrade path is a standing obligation. Moodle publishes support windows for each release, which set the upgrade timing. Ask a partner whether it offers handover training, runbooks, a support retainer, or both, and what the buyer's team would need to operate the platform alone.

Moodle 5.3 is the current long-term support release, released on 5 October 2026, with general support until 4 October 2027 and security support until 1 October 2029. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.1 requires PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires PHP 8.3 or later and sites must run Moodle 4.4 or later to upgrade. Confirm your current version and database engine before the partner sizes the upgrade.

Open edX supports only the latest named release, and it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026. The next releases, Willow and Xylon, are listed for December 2026 and June 2027. This means a production platform must move to each new named release within the period the buyer agrees to in its operating plan. Ask the partner how it will test each upgrade against your themes, plugins and integrations, how it will schedule downtime, and who approves the change. Confirm the upgrade method and any retainer terms in writing.

DeployOpen does not publish a price list. A quote follows from a written scope that sets out the deliverables, the assumptions, the buyer responsibilities, the exclusions and the timeline. After you share your requirements, the next step is a scoping conversation and a written proposal you can compare with other offers. Ask every bidder to quote on the same written scope, to list recurring costs separately, and to state which third-party fees, such as video hosting or payment processing, sit outside its quote. Confirm the support and upgrade options as separate line items.