What does an LMS cost when the software is free?
The license fee is zero. Moodle is licensed under GPL-3.0, Canvas LMS under AGPL-3.0 and the Open edX platform under AGPL-3.0, so a budget holder comparing them with a hosted subscription is not comparing a fee with a fee. The total cost of ownership is what you pay for hosting, setup and theming, integrations with identity and HR or student systems, content migration, upgrades and support. Those costs recur or arrive in predictable phases, and they are the lines a quote should break out. The total depends on learner count, peak concurrency (for example, a compliance deadline that puts thousands of learners into the system in the same week, which is an illustrative case), and how many systems the LMS must connect to. DeployOpen does not publish a price list. A quote follows from a written scope that fixes those variables.
Ask each vendor, and each implementation partner, to separate one-time work from recurring work. One-time items include installation, theme and plugin work, single sign-on configuration, initial course and record migration and staff training. Recurring items include production hosting and capacity for peak load, backups, security patching, Moodle point releases, major upgrades and the support window you choose. Moodle's own release schedule shows why upgrades are a standing cost: Moodle 5.1 requires sites to be on Moodle 4.2.3 or later, and Moodle 5.3 requires sites to run Moodle 4.4 or later, so an older install may need intermediate steps before it can move forward. Confirm the current requirements with Moodle's release notes before you size the budget.
On the subscription side, compare what the subscription price includes against what you would otherwise buy separately: hosting, backups, uptime commitments, storage, support hours, and whether integrations and custom plugins are extra. Ask the SaaS vendor which identity protocols and HR connectors are included, what it charges for additional environments, and how exports of completion records work if you later leave. Ask the open source options the same questions, then request a written scope that lists hosting size, integration count, migration volume and support hours as separate line items. That document lets you compare like with like and see which cost will move if your learner count or integration scope changes.
Cost components for build, partner and SaaS
This table compares in-house build, an implementation partner and a commercial hosted LMS across the cost components that shape an LMS budget. Read each cell for who pays and whether the cost is one-time or recurring, then check the quote against the same rows. The main takeaway is that Moodle, Canvas and Open edX remove license fees but move hosting, upgrades and integration effort onto your side or a partner's, so the recurring cost is the one to model first.
| Cost component | In-house build | Implementation partner | Commercial SaaS |
|---|---|---|---|
| Software license | No license fee for Moodle (GPL-3.0) or Open edX (AGPL-3.0). Canvas is AGPL-3.0 licensed for the open source code, so confirm which hosted or commercial terms apply. | Same open source license terms. Partner fees cover scoping and delivery, not the software itself. | Recurring subscription, usually per learner or per seat. Confirm the metric, tiers and renewal terms in writing. |
| Hosting and peak load | Recurring infrastructure paid by you. Sizing for exam or certification peaks is your responsibility. | Recurring infrastructure paid by you or the partner, passed through. Confirm who holds the cloud account and who pays for burst capacity. | Included in the subscription, with capacity limits set by the vendor. Ask how concurrency spikes are priced or throttled. |
| Setup and theming | One-time internal effort for installation, configuration and branding, plus ongoing theme maintenance. | One-time fixed-scope fee for installation, configuration and theme work, agreed in writing before work starts. | Usually one-time configuration by the vendor or reseller. Custom theming and plugins may carry separate fees. |
| Identity and HR or student system integration | One-time build of SSO, enrollment feeds and provisioning, then recurring maintenance when identity or HR systems change. | One-time integration scope, plus support for identity and HR changes under a retainer if you choose one. | Vendor-supplied connectors are often one-time setup, but custom feeds or SIS integrations may be billed separately. Confirm what is standard. |
| Content migration | One-time internal effort to move courses, SCORM packages and completion history, including validation. | One-time migration scope, priced by content volume and complexity. Ask how records are verified after the move. | Vendor migration tools or services, often one-time. Ask who validates completion history and whether exports are complete. |
| Upgrades and maintenance | Recurring internal effort to apply Moodle or Open edX releases, plugin updates and security patches on the vendor's schedule. | Recurring retainer or project fee for planned upgrades, testing and rollback. Confirm the support window covered by the contract. | Included in the subscription. Upgrade timing and downtime windows are set by the vendor, so ask for the release calendar. |
| Support and administration | Recurring internal staff for learner support, admin tasks and incident response. | Optional recurring support contract covering learner help desk, admin support and incident response. Confirm hours and escalation paths. | Vendor support tiers, often recurring and tied to the subscription level. Confirm response commitments in the contract. |
| Training and enablement | One-time internal effort to train administrators, course designers and instructors, plus ongoing staff turnover costs. | One-time or recurring fees for admin and instructor training, depending on the agreed scope. | Vendor onboarding and training, sometimes one-time and sometimes bundled with the subscription. Ask what is included per year. |
What moves the LMS cost up or down
Moodle, Canvas and Open edX carry no license fee, so the cost of a self-hosted LMS comes from the work around the software. The six drivers below decide how much of that work your organization pays for, and each one is worth pricing separately in any quote before you compare the total with a hosted subscription.
Peak concurrency and hosting topology
Your peak load sets the size of the environment you must run and keep running. A fixed compliance course rollout and an annual exam or certification window can produce very different peaks from the same learner count, so ask the partner to model both. Ask whether the quote includes load testing, a database and cache tier, backups, and a standby environment, and who pays for capacity you use only a few weeks a year. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, so confirm which database services are in scope.
Number of integrations
Each connection to your identity provider, HR system, student information system or external LTI tool is a build, test and maintenance item. Single sign-on, automated enrollment from HR data and grade passback are common examples, and each one needs its own mapping, error handling and monitoring. Ask for a written list of integrations with the data direction, the owner of each system and who fixes a break after go-live. Moodle core already includes authentication plugins for LDAP, OAuth 2, Shibboleth and web services, which can reduce custom work if they match your identity design.
Content volume and migration format
Moving existing courses is often the largest one-time cost in a switch from a hosted LMS. Count the packages and their formats, because SCORM 1.2, SCORM 2004, xAPI and LTI content each import differently, and some legacy packages make external calls that must be removed. Ask whether the quote covers test imports, mapping of completion rules and records, and a reconciliation of learner history against the old system. Records that must be kept as evidence usually need extra checks, so price that work explicitly.
Theming and plugin count
Every custom theme, plugin and local modification becomes code that must be tested and updated with each release. A standard theme with minimal branding costs far less to maintain than a heavily customized interface with several third-party plugins. Ask the partner for a list of plugins with their source, license, maintainer and last update date, and for a plan that says which customizations are retired at each upgrade. Moodle 5.3 removes the Classic theme from core, which is an example of a change that forces theme work during an upgrade.
Upgrade cadence and support windows
Upgrades are a recurring cost, and the release model sets how often you pay. Moodle 5.3 has security support until 1 October 2029, while Open edX supports only its latest named release, so an Open edX deployment must move to each new release to stay supported. Ask for the planned upgrade calendar over your support term, the testing scope for each upgrade, and whether the quote covers a rollback path. Confirm the minimum version your current site must reach before upgrading, since the Moodle 5.3 notes require Moodle 4.4 or later.
Accessibility remediation
Accessibility work recurs whenever content, themes or plugins change, and it is often underpriced in an LMS quote. Public bodies in the United States must meet WCAG 2.1 Level AA under the ADA Title II rule, with compliance dates that depend on population size. Ask who owns remediation of theme output, third-party plugins and instructor-made content, and whether testing covers keyboard use, captions and screen readers after each release. Clarify whether accessibility audits are part of the scope or billed separately.
Why upgrade timing is a recurring cost line
Upgrade timing is a recurring cost line because every LMS on this list ships on a fixed clock, and the clock does not care whether the license costs anything. Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and it requires the web server document root to point to the new /public directory instead of the main Moodle folder. Sites that skip this change can show directory listings or errors, so the web server configuration is part of every upgrade, not just the code. Moodle 5.3 goes further: it requires PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and a site must already run Moodle 4.4 or later to upgrade to it.
Each of those steps has a cost that recurs. Someone must confirm the database and PHP versions on the hosting stack, test the custom theme and third-party plugins against the new release, and schedule a maintenance window that fits academic or training calendars. Ask any partner quoting a Moodle engagement which Moodle release the quote assumes, which PHP and database versions it includes, and whether the quote covers the /public document root change and a test restore before production cutover.
Open edX works on a different clock. It supports only the latest named release, so a site running Verawood, published 30 July 2026, will need to move to Willow when it is released, currently planned for December 2026, and then to Xylon, planned for June 2027, if it wants vendor-supported code. The project states it cannot support more than one release at a time, which means there is no long support window to wait out. Confirm the planned dates against the Open edX release notes before you budget, because a named release that slips will move the upgrade work with it. Either way, the upgrade effort lands on your budget every cycle, and it should be priced into the total cost of ownership from the start.
How to build your own LMS cost estimate
This sequence turns a vague LMS budget into a list of sized, one-time and recurring cost lines that a partner or SaaS vendor can price against. Work through it in order, because each step supplies the inputs the next one needs.
Define peak and average concurrency
Start by estimating how many learners sign in on an ordinary day and how many sign in at the busiest moment, such as a compliance deadline, exam week or a product launch. Your training or academic team owns the numbers and your platform owner checks them against enrollment and calendar data. The step is done when you have one average figure and one peak figure, each with the time window it applies to. Peak load drives hosting size, so this is the most expensive input to guess.
List course types and content formats
Inventory every course type you will run, such as instructor-led sessions, self-paced modules, assessments, certifications and video, and note the packaging each one uses, including SCORM, xAPI or LTI tools. Content owners and the instructional design team usually hold this list. Each format changes storage, third-party licensing and setup effort, and external tools can add integration work. The step closes when every course type has a format and an owner.
List identity and HR or SIS integrations
Record every system that must connect to the LMS for sign-in, enrollment and record keeping, such as your directory, single sign-on provider, HR system, student information system or certificate tools. Identity and security teams should confirm the protocols each connection supports. Each connection is a build item with its own testing and support cost, so a longer list means a larger first-year estimate. The step is complete when each integration has a named system, a protocol and an owner who will approve it.
Size the content and record migration
Estimate how much existing content, user history and completion records must move into the new platform, and which of it needs to be kept as evidence. Your training operations team should count courses, learner records and attachments, and your legal or compliance team should mark which records have retention duties. Migration effort depends on data quality and format, so ask a partner to confirm how it will test a sample before committing to a full move. The step ends with a volume estimate and a list of records that must be preserved.
Choose the hosting model
Decide whether you will run the platform in your own cloud account or data center, use a managed hosting service from the platform's maintainers or a partner, or subscribe to a hosted LMS. Your infrastructure and security teams should compare where learner data may reside, who operates the servers and how capacity scales to the peak figure from the first step. Self-hosting shifts cost toward infrastructure and operations staff, while subscriptions shift it toward recurring fees. The step is done when one model is chosen with a written reason.
Set the support and upgrade cadence
Agree how often the platform will be upgraded, who applies security patches, and what support learners and administrators receive. Moodle publishes major releases in April and October and point releases every two months, and each long-term support release has defined support windows, so your plan should match those dates to your change calendar. The platform owner and the support provider should document the cadence in writing. The step closes with a schedule of upgrades and a named support tier.
Separate one-time from recurring cost lines
Sort every item from the previous steps into one-time costs, such as setup, theming, integrations, migration and testing, and recurring costs, such as hosting, licenses for paid plugins, support, upgrades and subscription fees. Finance and the platform owner should review the split together, because recurring lines usually decide the total cost over several years. Note what drives each line up or down, such as peak concurrency or the number of integrations. The step is done when a table shows both groups with a driver for each line.
Request a written, fixed-scope quote
Send your sized inputs and cost table to each candidate partner and to SaaS vendors, and ask each to price against the same scope. Request line items for setup, integrations, migration, hosting, support and upgrades, along with the assumptions behind each one. DeployOpen works from a written fixed scope, so its quote follows from the scope you agree, and it does not publish a price list. The step is complete when every bidder has priced the same written scope and you can compare the lines directly.
When build, partner or SaaS fits best
Building in-house means your own engineers install, configure, theme, integrate and upgrade Moodle, Canvas or Open edX. The license is free for Moodle (GPL-3.0) and Open edX (AGPL-3.0), so the cost sits in people, infrastructure and time. This model suits organizations that already run containers, databases and identity services at scale and want the platform treated like any other internal product.
- Staff cost: Platform, DevOps and application engineers are paid continuously, including for on-call support and upgrades.
- Upgrade load: Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, and sites must run Moodle 4.4 or later to upgrade, so upgrades are a planned project each cycle.
- Open edX support model: The maintainers recommend a service provider or Tutor for production, and bare-metal installs receive limited community support, so in-house teams must accept that burden.
- Ownership: You control plugins, data location and release timing, and you carry every security patch.
Before choosing this path, ask whether your team can staff the platform through a long-term support window and whether leadership will fund that headcount each year.
An implementation partner plans, installs, hardens, integrates and documents the LMS in your cloud account, data center or private network, then hands over the running system with runbooks. Cost is mostly a fixed-scope project fee for setup and handover, plus any retainer for upgrades, support and testing. Your team keeps operational control, and the partner brings repeatable deployment and hardening work.
- Fixed-scope setup: Scope, deliverables and timelines are agreed in writing before work starts, so the one-time portion is visible up front.
- Hosting stays yours: Infrastructure is billed by your cloud or data center provider, not bundled into the partner fee.
- Handover: Confirm what documentation, access, backup tests and training you receive at the end of the project.
- Recurring work: Upgrades, LTS moves and continuous testing usually run under a separate support arrangement, so ask how it is priced.
- Integration scope: Identity, HR or student systems and LTI tools are often the largest variable, so define them in the statement of work.
Ask the partner which parts of the work are included in the fixed scope, which are optional, and who owns the code, configuration and evidence when the engagement ends.
A hosted LMS subscription has the vendor run the application, infrastructure, upgrades and much of the support. Pricing is typically recurring per user or per contract, which makes the first year fast and predictable on paper. The trade-off is less control over plugins, data location, retention settings and the timing of changes you did not request.
- Fast start: Hosting, backups and routine patching are handled by the vendor, which shortens the path to first learners.
- Recurring fees: Subscription costs continue for as long as you use the service, and they often scale with learner count.
- Plugin limits: Confirm which integrations, authentication methods and LTI tools the vendor supports without custom code.
- Data location: Confirm where learner records, backups and logs are stored and which sub-processors can access them.
- Exit terms: Ask how you export course content, completion records and audit logs if you leave.
Before signing, ask the vendor for its contractual uptime commitments, its upgrade calendar, its support hours and its data export format in writing.
LMS cost questions buyers ask before hiring help
Is open source LMS software really free to use?
The code carries no license fee, but that is only one line in the budget. Moodle is licensed under GPL-3.0, and the Open edX platform under AGPL-3.0, so you can install and run them without paying a license fee to the project. Canvas LMS by Instructure is also licensed under AGPL-3.0, so the code itself is open. What you still pay for is hosting sized for your peak load, setup and theming, integrations with your identity provider and HR or student systems, content migration, upgrades and support. Those costs are paid to your cloud provider, your staff and any implementation partner. Ask every bidder to list each of these as a separate line so you can see what recurs and what is one-time.
How much effort does self-hosting an LMS take?
Effort depends on the platform, the number of learners and how much you change. Moodle has a fixed release rhythm: major releases every six months in April and October, and minor point releases every two months. Moodle 5.3 was released on October 5, 2026 and is the next long-term support release, with security fixes until October 1, 2029. Open edX is different. The maintainers recommend running it in production through a service provider or with Tutor, and they note that bare-metal installation is complex. Ongoing effort covers patching, backups, monitoring, plugin compatibility checks and upgrades. Ask any partner to show the expected recurring hours per month for your environment and the upgrade path they would follow.
Can our internal team run an open source LMS alone?
A small team can run Moodle if it has someone who understands PHP web applications, a database administrator for PostgreSQL or MySQL, and an owner for identity integration. 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 sites must run Moodle 4.4 or later to upgrade. Open edX needs more specialist skill because it depends on Python, Node.js, MySQL, MongoDB and Memcached, and multi-node deployments also need a shared cache such as Redis. Be honest about who will be on call for an exam period. Ask a partner which tasks they would hand over to your team and which they would keep, and write that split into the scope.
How long does LMS setup take, and what makes it longer?
Setup time is driven by scope, not by the installer. The main drivers are the number of identity and HR integrations, how much theming and custom work you need, how much content you migrate from an existing system, and whether you need validated or accessibility-audited output. A basic installation with standard authentication can be quick, while SAML or Shibboleth single sign-on, LTI tools and SCORM content migration each add test cycles. Moodle 5.1 also changed the web server document root to the new /public directory, which a site setup must handle correctly. Ask for a timeline built from written deliverables and agreed milestones, and ask which items are fixed in scope and which are priced as change requests.
What does the LMS project need from our IT and HR teams?
The biggest dependencies usually sit outside the LMS. IT must provide hosting accounts, network paths, DNS, certificates, backup storage and a change window for upgrades. Identity teams must agree how learners authenticate, and Moodle core ships authentication plugins for LDAP, OAuth 2, LTI, Shibboleth and others, so the choice affects test effort. HR or student information teams must supply the source of truth for enrollments and role changes, along with a decision on how often data syncs. Security teams should review logging, access roles and data location. Ask each partner to list these dependencies in writing with the name of the person who will supply each one.
When is a SaaS LMS subscription cheaper than self-hosting?
A hosted subscription is often cheaper when you have a small learner base, standard course types and no need for custom integrations, data residency controls or a long-term support plan. Self-hosting tends to make sense when you need control over hosting location, have many learners, want to avoid per-user fees at scale, or must run the platform on private networks. The comparison should be made over several years, not one year. Subscription fees recur per user or per tenant, while self-hosting costs recur in infrastructure, staff time and support contracts. Ask a SaaS vendor for its per-learner pricing at your expected volume, its data residency options and its exit terms, then compare those against a written self-hosted quote.
How do we compare LMS quotes fairly?
Compare quotes on the same written scope, not on the total figure alone. A useful comparison lists each cost component separately: hosting, setup and theming, integrations, content migration, testing, documentation, upgrades, and recurring support. Note whether each item is one-time or recurring. Check the platform version each bidder proposes and whether it matches a supported release, such as Moodle 5.3 or the current named Open edX release, which Open edX says is the only supported one. Ask how peak exam or enrollment load is tested, what happens at the next LTS upgrade, and which deliverables are fixed. Lower quotes often leave out testing, migration or upgrade work, so ask each bidder to confirm what is excluded.
Which cost items are most often missed in an LMS budget?
Teams most often miss recurring work rather than the initial build. Common gaps include staging environments for testing upgrades, backups and restore tests, monitoring, plugin compatibility checks after each release, and accessibility audits of themes and plugins. Content migration is also frequently underestimated, especially when SCORM packages, videos or instructor-made pages need cleanup. Upgrade planning matters because Moodle's security support windows and Open edX's single-supported-release policy both require regular movement to newer versions. Ask any bidder to show a yearly cost view covering these items, and confirm whether support for learners and administrators is included or sold separately.
How DeployOpen scopes and delivers a fixed-scope LMS implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source LMS platforms inside your own cloud accounts, data centers or air-gapped networks. For LMS cost: build, partner or SaaS, that means turning a cost comparison into a written scope with named cost lines, so you can compare a self-hosted quote with a hosted subscription on the same terms.
How we scope
- Inventory learner counts, peak concurrency and exam or certification windows, since these drive hosting size for Moodle, Canvas or Open edX.
- List every integration to identity, HR and student systems, plus content migration volume, so each cost line is visible in the written scope.
- Record the upgrade policy and support hours you need, then price one-time setup separately from recurring hosting, upgrades and support.
How we build
- Install the chosen platform in your environment, with theming, plugin selection and integration work described as named deliverables.
- Test identity login, enrollment sync, grade and completion reporting, and peak-load behavior against the scope before go-live.
- Migrate courses and training records in agreed batches, and confirm counts and completion dates with your owners at each stage.
How we hand over
- Deliver architecture notes, runbooks, backup and restore procedures, and configuration records that your team can keep using after the project.
- Provide a cost model that shows which lines recur, such as hosting, plugin licenses where they apply, and upgrade effort for each release cycle.
- Walk your administrators through daily operations, upgrade steps and the support handover, so the in-house or partner split is explicit.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, priced from the scope you agree in writing.
- Plan platform upgrades around the release calendar, confirming which support window your chosen version falls into before each change.
- Ask us to document what a retainer covers, including response expectations and the boundary between platform work and course content work.
