Course platform cost: build, partner or SaaS

Hosting and upgrades are the costs that keep arriving after launch, and they differ sharply between Moodle and Open edX. Moodle ships major releases every six months, and each release carries its own support window. Moodle 5.3 is the next long-term support release, with security fixes until 1 October 2029, while Moodle 5.1 general support ends on 5 October 2026. A team running 5.1 today should plan its move to a supported line before general support lapses, not after. Confirm with your partner which Moodle line the platform will sit on at launch and how long that line stays covered.

Open edX takes a different position. The project supports only its latest named release, so an installation has to keep pace with each release. Verawood is the current release, Willow is planned for December 2026 and Xylon for June 2027. Each move means testing custom themes, plugins, identity integrations and the analytics pipeline against the new version. Ask a partner to describe how they will track release dates, how many environments they will use for rehearsal, and whether the upgrade effort is priced into a retainer or quoted separately each time.

Upgrade effort is rarely just a version bump. Moodle 5.1 requires that the web server document root point to the new public directory rather than the main Moodle folder, so a server configuration that worked before can show directory listings or errors after the move. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and it can only be upgraded from Moodle 4.4 or later. Those requirements can force operating system, database and PHP changes on the same schedule as the application. Ask for a written list of prerequisites for each target release and a hosting plan that covers the infrastructure changes, not only the application.

A SaaS course platform usually costs less when your catalog is small and standard, your sales volume is modest, and you need few integrations beyond checkout and a login. You pay a subscription, or the vendor takes a share of each sale, and the vendor carries hosting, upgrades and most of the operating work. For a single team selling a handful of courses with stock branding and a basic email tool, that trade is often sensible. The cost question changes when the platform has to do more than the vendor's template allows. Confirm in writing the subscription tiers, any per-learner or per-seat charges, the revenue share and whether it applies to bundles, refunds and coupons, the fees for custom domains and single sign-on, and what happens to your fee rate as volume grows.

Self-hosting changes the economics in four places. First, data residency: if learner records, payment-related data or identity data must stay in a particular jurisdiction or inside your own cloud account, a shared SaaS tenant may not meet that rule without contractual and technical work. Second, owned integrations: when the platform must write completion and enrolment data into your CRM, HR or student information system, your own code and its maintenance cost stay with you, but so does control over the interface. Third, custom identity: federating with your corporate directory or a government login through SAML 2.0, OAuth 2 or LTI is possible on Open edX and Moodle, but a SaaS vendor may charge extra for it or restrict which providers you can use. Fourth, high sales volume: a percentage revenue share grows with every sale, so a platform that is cheap at launch can cost more than a fixed-cost deployment once revenue is large. Model both paths with your own sales forecast, not the vendor's example.

Before you compare totals, confirm the vendor's fee structure, data location and export terms in writing. Ask where learner and transaction data is stored and processed, whether you can export complete course content, enrolments, certificates and analytics in an open format, what happens to them on termination, and how long the export takes. Ask which upgrades are included and which are charged separately. A self-hosted option carries its own recurring costs, including hosting, upgrades to the named Open edX or Moodle release, and support, so the comparison should cover both sides with the same assumptions.

A comparable quote should break the work down by component, not present one lump sum. Ask for separate lines for the Open edX or Moodle hosting environment, the ecommerce and payment layer, theming, video delivery, the analytics stack, identity integration, and the marketing site if it sits outside the learning platform. For each line, the quote should name the environment it runs in (your cloud account, a data center or an isolated network), the named release it targets, and the upgrade path to the next one. Open edX supports only its latest named release, currently Verawood, with Willow and Xylon listed for December 2026 and June 2027. Moodle 5.3 is the next long-term support release, so ask which branch the quote assumes and who carries the work when a minor point release or the next major version lands.

Ask for one-time and recurring costs listed separately. One-time items typically include discovery, configuration, theming, integrations, migration of existing content and learner records, load testing and handover training. Recurring items include hosting, managed database and cache services, video storage and bandwidth, support retainers, security testing and upgrade cycles. For payments and tax, the quote should state who holds the merchant account, which payment provider or gateway is integrated, whether tax calculation and invoicing are included, and how cardholder data is kept out of your systems. Ask for learner volume assumptions in writing, because concurrent viewing, video traffic and database sizing change the hosting line more than almost anything else.

Before work starts, confirm the acceptance criteria. Each deliverable should have a test the buyer can run, such as a completed test purchase, a successful single sign-on login from your identity provider, a certificate issued and verified, or a restore of the database from backup. Also confirm handover terms: who receives admin credentials and infrastructure as code, what documentation is delivered, what the support hours and response expectations are, and what happens to the platform if the engagement ends. Engagements at DeployOpen are fixed-scope and agreed in writing, so any assumption missing from the quote is a change request later. Ask the partner to restate every assumption in its own sentence and to flag which ones you would need to verify with your own team or vendors.