D2L Brightspace cost vs self-hosted Moodle: where the money actually goes
A renewal or a pricing change is usually what starts a cost review of Brightspace, and the first thing to get straight is that Moodle carries no license fee. Moodle is licensed under GPL-3.0 and is free to download and run. What you pay for instead is hosting, database and storage, administrators, migration, plugins and support, and the total depends on your user count, your data volume and how much of this your own team can already do. Moodle can also be self-hosted, or run as managed hosting through MoodleCloud or Moodle Partners, so the hosting line can be filled in different ways. Treat the comparison as a set of components to price, not a single number to swap in for the subscription.
Start with the platform requirements, because they set the baseline for hosting. Moodle 5.1 requires 64-bit PHP 8.2 or later (8.3 and 8.4 are supported) and one of PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 raises the floor to 64-bit PHP 8.3 or later (8.4 supported) and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Check which database engine your team can patch and back up on schedule, because that choice drives the database hosting and the DBA time you need. Also confirm your upgrade path: sites must already be on Moodle 4.4 or later to move to 5.3, and 4.2.3 or later to move to 5.1. If you are behind, the upgrade work itself is a one-time cost to include in the quote.
Ask any provider, including your own infrastructure team, for a quote that lists each component separately: compute and storage for the web and cron tiers, the database service, backups, monitoring, the number of administrator hours per month, the plugins you need and who maintains them, and the migration effort from Brightspace. Ask which costs are one-time (migration, initial hardening, plugin selection) and which recur (hosting, patching, upgrades, support). The biggest variables are user count and how much course media you keep, since both drive storage and backup size. Compare these figures with the subscription and its add-on modules, and make sure the Brightspace side is priced on the same user count and the same term.
Which cost components change when you move from Brightspace to Moodle
This table compares each cost component of a Brightspace subscription with the matching cost of running Moodle yourself. Read each row for who gets paid, whether the cost is one-time or recurring, and what drives it up or down. Most of the difference sits in people time and migration effort, not in the software licence, so ask your vendors and partners to price those items separately.
| Cost component | Brightspace (commercial side) | Self-hosted Moodle (open-source side) |
|---|---|---|
| Subscription or licence | Recurring contracted subscription, with terms set by D2L in your order form. Confirm renewal, uplift and term-length clauses before signing. | No licence fee. Moodle is GPL-3.0 software, so the recurring cost is the infrastructure and people that run it. |
| Add-on modules | Recurring charges for extra tools or modules that your contract lists separately. Check which features you use are included in the base plan. | Core features ship in Moodle. Optional plugins are free to install, but each one needs testing, updates and sometimes a paid developer or partner. |
| Hosting and compute | Usually included in the SaaS subscription, with D2L operating the servers. Ask what peak-season capacity and data location terms apply. | Recurring. Your cloud, data centre or partner bills for web, cache and background job servers. Load during enrolment and exam periods drives sizing. |
| Database and storage | Included within the subscription, with storage limits and overage terms in the contract. Confirm how Data Hub exports and archives are counted. | Recurring. PostgreSQL 17 or MySQL 8.4 (or MariaDB 11.4) is free to license, but you pay for hosting, backups, replicas and file storage for course content. Moodle 5.3 requires PostgreSQL 17 among its listed options. |
| Migration | One-time cost from exporting courses, rebuilding release conditions and calculated grades, and archiving learner records before the contract ends. | One-time. Covers Common Cartridge export and import, rebuilding gradebook logic, SSO and SIS cutover, and parallel running. Effort depends on course count and customisation. |
| Plugins and integrations | Usually covered by D2L's LTI and partner marketplace. Confirm which third-party tools are supported under your contract. | Recurring maintenance. Each plugin needs review against each Moodle release. Core authentication options include LDAP, LTI, OAuth 2 and Shibboleth; SAML2 needs a plugin. |
| Support | Included in the subscription at the support level you purchased. Ask about response targets and escalation paths in writing. | Recurring if you buy a partner or managed hosting retainer. Otherwise, the Moodle community and your own staff handle issues. Get support scope in a written quote. |
| Upgrades and version management | Handled by D2L on the SaaS release cycle, with little action from your team. | Recurring. Moodle ships major releases in April and October, and you must check PHP, database and web server requirements each time. Moodle 5.1 changed the web root to the /public directory. |
| Internal administrators | Smaller internal team focused on configuration, users and reporting, with D2L running infrastructure. | Recurring staff time for system administration, security patching, backups, monitoring and incident response. Usually the largest ongoing line, so confirm headcount in the quote. |
What moves the comparison most for your organization
Six factors shift the Brightspace versus self-hosted Moodle comparison more than any others. Each one changes hosting, staffing or upgrade effort, so price the components against your own numbers rather than a generic estimate.
User count and concurrent peaks
Active users and the number of people logged in at the same time drive the size of web, PHP and database capacity you must provision and pay for. Peaks matter more than averages, because exam weeks, enrollment windows and mandatory compliance deadlines concentrate logins. Ask your team to measure peak concurrency from current Brightspace reports, then size Moodle hosting for that peak plus headroom, not for the yearly average.
Course and media volume
Stored course files, embedded video and uploaded SCORM or H5P packages grow storage and backup costs every year, and they are usually the fastest-growing line item. Heavy video libraries push you toward object storage or a CDN, which adds components to run. Inventory total course storage and media hours in Brightspace before you estimate Moodle file storage, backup size and restore time.
Add-on modules and integrations
Brightspace features such as analytics, portfolio or advanced assessment may be licensed separately, so each add-on is a recurring line in the D2L quote. Moodle covers many of these needs through core and plugins, but each plugin you adopt needs testing, patching and a maintenance owner after every upgrade. List every integration in use, including SIS, SSO, video and publisher content, and mark which Moodle core features or maintained plugins already cover it.
Availability and disaster recovery targets
The uptime and recovery times you commit to decide how much redundancy you build. A hosted D2L subscription moves most of that engineering to the vendor, while self-hosted Moodle needs you to design replicas, failover, tested restores and off-site backup copies. Higher targets raise hosting, licensing for database clustering, and on-call effort. Confirm the recovery objectives with your business owners before you choose an architecture.
In-house Linux, PHP and database skills
Your existing staff decide whether you hire, train or contract for operations. Moodle runs on a Linux web stack with PHP and a supported database, so teams without these skills pay for training, a managed hosting partner or added headcount. Check whether your staff already run similar stacks, and price the gap as one-time training plus recurring on-call time, not as an afterthought.
Number of Moodle releases you absorb
Moodle ships major releases twice a year and point releases every two months, and each upgrade requires testing custom themes, plugins and integrations against the new version. The minimum PHP and database versions also change between major releases, so you may need to upgrade the server stack as well as Moodle itself. Decide whether you will follow every release or only LTS branches, and budget upgrade testing time for the path you choose.
Costs on the Moodle side that people underestimate
The Moodle licence costs nothing, but the platform around it is where the budget goes. Moodle is licensed under GPL-3.0, so the question is never what the software costs to acquire. It is who pays for the PHP and web server hosting, a supported database, file storage that grows with every course upload, backups and restore testing, and the people who patch the site. Each of these is a line item you have to name in a comparison with a D2L subscription, and each recurs every year. Ask whether your hosting team will carry the cost on their own budget or whether it will be charged back to the LMS owner.
The database and runtime versions set the floor for your hosting spend. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and PostgreSQL 15 or later. 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. Confirm these against the release notes for the exact version you plan to run, then check whether your current servers, managed database service and operating system images support them. From Moodle 5.1, the web server document root must point to the /public directory rather than the main Moodle folder, or the site may expose directory listings or show errors. That change belongs in the deployment runbook and in the test plan, not in a post-go-live fix.
Upgrades add a cost that many comparisons leave out. Moodle 5.1 requires an existing site to be on Moodle 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. If a legacy Brightspace migration target is running an older Moodle, you need an intermediate upgrade path, with a test copy of the database, plugin compatibility checks for every third-party plugin, and a rollback plan for each step. Ask your Moodle partner or internal team to list each hop, the environments it needs and the staff time it consumes, and treat that list as a one-time cost that recurs with every major release. Ongoing security support windows for each release are published on the Moodle releases page, so check them before you choose a version to standardize on.
How to build the cost model with your own numbers
This sequence turns a vague sense that Brightspace is expensive into a five-year cost comparison built from your own contract, user counts, storage and written quotes, so every line can be checked before a decision.
Pull the current Brightspace contract and invoices
Finance or procurement collects the current D2L Brightspace agreement, every order form, renewal notice and add-on invoice for the last full billing period. Record each line item separately: base platform, each add-on module, integrations, support tiers, data or storage charges and any usage-based fees. Confirm the renewal date and the notice period in writing. The step is done when every recurring charge sits in one sheet with its source document and billing frequency, and anything you cannot find is marked as a question for D2L.
Measure users, concurrency and course volume
The LMS or training owner counts active and annual users by group: learners, instructors, administrators and external partners, if any. Pull peak concurrent sessions from the existing platform or web server logs for a normal teaching week and an exam or enrollment peak. Count active courses, archived courses and average enrollments per course. The output is a small table of user numbers and peaks that the hosting quotes will be requested against, so every vendor prices the same load.
Size course and media storage
Your learning technology team measures the current Brightspace content footprint: course files, embedded video, uploaded documents, learner submissions and backups that you must retain. Separate content you will migrate from records you must archive, because they follow different retention rules. Note growth per year from the last two or three years of usage. The result is a storage estimate in gigabytes, with a projection for each year of the model, that feeds directly into the hosting and object storage quotes.
Request hosting quotes for each Moodle option
Compare three routes: self-managed Moodle on your own cloud account or data center, Moodle Partners, and MoodleCloud. Send each provider the same written specification: user counts, peak concurrency, storage, required database engine, backup retention, data location and uptime expectations. Ask for one-time setup, recurring hosting, backup, support tiers and any charges for additional storage or environments. The output is a comparable quote for each option. Do not assume a figure from a marketing page, because providers price differently and several will need the scope to be fixed first.
Scope and price migration and plugin work
Write a migration scope that lists the course export format, the content types you must move, the components that will need rebuilding by hand, the learner records to archive, the single sign-on and SIS integrations to re-establish, and the LTI tools to reconnect. Each scoped item then goes to one or more implementation partners, including DeployOpen if it fits, for a fixed-scope quote. Ask separately for any plugins you need, their licensing, and the upgrade effort they add. The step is complete when each quote matches the same written scope and the differences are explained.
Add staff time for administration and upgrades
Estimate the people who will run the platform after go-live: system administration, database and backup operations, security patching, plugin maintenance and the Moodle release upgrades that arrive twice a year. Identify whether these duties are absorbed by existing staff or require new roles, and record the fraction of time each role will spend. Staff time is usually the largest recurring cost in a self-hosted model, so the output should show salary cost per role, and whether a support retainer would replace some of that time. Ask each partner to state what its retainer covers.
Compare five-year totals side by side
Build one sheet with the same five columns for each option: Brightspace renewal and add-ons, Moodle hosting, database and storage, migration, plugins, support and staff time. Mark which lines are one-time and which recur each year, then add an annual price growth assumption only if it comes from a written vendor notice. Run a sensitivity check on user growth and storage growth. The model is finished when a reviewer can trace every number to a contract, a log, a quote or a named internal estimate, and any gap is listed as an open question for the vendor.
Self-managed, managed Moodle or a partner: which model changes the math
Running Moodle on your own cloud account or data center means your organization pays for every layer. The GPL-3.0 licensed code costs nothing to download, but the server, database, storage, backups, monitoring and the staff who keep them running are all yours. Upgrades follow Moodle's release cadence, so you need a test environment and a plan for each major and point release.
- Infrastructure: compute, PostgreSQL or MySQL-compatible databases, object or file storage and backups, all billed by your cloud or hardware costs.
- Staff time: administrators and a developer or two for plugins, theme work and integrations, which recur every year.
- Upgrades: each major release has its own PHP and database minimums, so budget testing time in advance.
- Security: you own patching of the operating system, PHP, the web server and Moodle itself.
- Support: community forums are free, but any contractual response time comes from a paid agreement you must buy separately.
Ask your team to confirm which PHP, database and web server versions the chosen Moodle release requires, and who on staff is accountable for each upgrade.
MoodleCloud and Moodle Partners run Moodle for you as a managed service. The subscription or service fee covers hosting, updates and some support, and the provider decides the infrastructure. You trade direct control of the stack for a predictable recurring fee and a smaller internal operations team.
- Included items: confirm whether hosting, backups, upgrades, storage limits and security patching are inside the fee.
- Recurring fee: typically billed per year or per user tier, so ask how it scales with enrollments and storage growth.
- Plugins: check which third-party plugins and LTI tools the provider allows, since restrictions can affect the course tools you use.
- Data location: confirm the regions where data is stored and backed up, and whether that fits your residency rules.
- Exit terms: ask how you export courses, files and user data if you leave, and in what format.
Compare the provider's quoted service with the internal cost of the same functions if you ran Moodle yourself, and ask for the exit terms in writing before signing.
A fixed-scope implementation partner, such as DeployOpen, plans, installs, hardens and documents Moodle inside your own cloud account, data center or air-gapped network. You keep the platform and the data in your environment, while the partner delivers a defined scope for a written price. Ongoing support, upgrades and testing can be bought as a separate retainer.
- Project fee: one-time work for design, installation, integration with identity and SIS, data migration and handover, agreed in writing before work starts.
- Retainer: optional recurring support for upgrades, patching, backup testing and incident response.
- Your infrastructure costs: cloud or hardware costs stay with you, so ask the partner to show which resources the design assumes.
- Internal staff: you still need someone accountable for the platform after handover, so confirm the skills and time that requires.
- Deliverables: ask for runbooks, backup and restore evidence, and upgrade procedures as named items in the scope.
Request a quote that lists each deliverable, the assumptions behind it, and what is excluded, so you can compare it fairly with the other two models.
Questions buyers ask before comparing Brightspace and Moodle costs
How much does running Moodle cost compared with a Brightspace subscription?
Moodle's license is free, so the cost sits in components you pay for: hosting, database and storage, backups, plugins, migration, support and the administrators who run the site. Brightspace is priced through a subscription and add-on modules that D2L does not publish as list prices, so the comparison only works when you total each component on both sides. Ask every bidder for a line-item breakdown covering one-time setup and recurring run costs, and state the user count, course volume and storage growth you plan for. Those inputs drive most of the difference.
How long does a Brightspace to Moodle migration take?
The timeline depends on how much content you move, how much of it needs rebuilding, and how many integrations must be re-established. Common Cartridge exports carry course structure and resources well, but release conditions, calculated grades and some quiz features often need manual rebuilding. Learner records held in Data Hub also need a separate archiving plan. Ask any provider for a timeline tied to a written scope with named deliverables, and ask which items they have classed as rebuild work versus import work.
What does the migration need from our own team?
Your team usually supplies decisions and access rather than build effort. Expect to name owners for course content, grading policy, SIS and identity integration, and the sign-off on cutover. Registrars or training leads check that courses and grades match what learners and instructors expect, while IT provides hosting, network, SSO and database access. Ask the provider which of these tasks they need from you, how many people, and at which stages, so the schedule does not stall waiting for an approval.
Can our own staff run the Moodle migration without outside help?
Yes, if you have people with Linux, PHP, database and web server skills, plus instructional designers who can rebuild course logic. Moodle runs on standard stacks, and the official documentation covers installation and upgrades. The risk lies in the parts that are unfamiliar: cutover of identity, backup and restore testing, and the first upgrade cycle. Estimate the internal hours against your own staff capacity and ask whether a fixed-scope engagement would cover only the parts you cannot staff.
How often do we need to upgrade Moodle, and what does that mean for staffing?
Moodle ships major releases every six months, in April and October, and minor point releases every two months in February, April, June, August, October and December, according to the Moodle releases page. Security support windows differ by version, so plan which release you run and when you move to the next one. Staffing should cover a recurring upgrade task, plus testing of plugins and the PHP and database versions each release requires. Moodle 5.1 requires PHP 8.2 or later and sites must be on Moodle 4.2.3 or later to upgrade, so older installations may need a staged path. Confirm the current support dates on the releases page before you commit to a plan.
Does the license saving still hold once we add hosting and support?
The license saving is real, but it is only one line in the total. Moodle's code is licensed under the GNU General Public License version 3, so there is no per-user license fee, yet hosting, storage, backups, monitoring, plugin maintenance, a support contract and staff time all recur. Whether the total falls below a subscription depends on your user count, peak load and the staffing model you choose. Compare a three-year total of both options, including the one-time migration cost, instead of comparing the license lines alone.
What should we ask for in a Moodle implementation quote?
Ask for a written scope with deliverables, assumptions and exclusions, so you can see what is included. Request the cost split between one-time work (installation, hardening, migration, integrations, testing) and recurring work (hosting, backups, upgrades, plugin updates, support). Ask how the provider handles the Common Cartridge export, learner records, SSO and SIS cutover, and what they need from your team. Confirm the Moodle version and PHP and database versions in the proposal, and ask which backup and restore tests will be documented before go-live.
When Moodle is the cheaper option and when it is not
Self-hosted Moodle tends to cost less when the Brightspace subscription and its add-on modules form a large annual line and your organization already employs administrators who can run a LAMP-style stack with PHP, a supported database and a web server. In that case the recurring cost moves from a vendor invoice to salaries you already pay, hosting, storage and backups. The biggest variable is the administrator time you can absorb without hiring. Ask D2L for a written quote covering every module you use today, then price each Moodle component separately: compute and database hosting, object or file storage for course media, backup retention, plugin licensing where a plugin is paid, and the share of a platform engineer's time for patching. Moodle itself is free under GPL-3.0, so the license line disappears, but that does not make the total cheaper by default.
Self-hosting tends to cost more where the team is thin, uptime obligations are high, or integrations are heavy. A single administrator covering upgrades, PHP and database version changes, and security patches leaves no slack for an exam week outage, and one-time migration work for courses, gradebook history and single sign-on can take longer than expected. Moodle major releases arrive twice a year, and the supported PHP and database versions change with each one, so plan an upgrade calendar and check the requirements for your target release before committing. Integrations with a student information system, identity provider or proctoring tools are often the largest hidden cost, because each connector needs build, test and support effort. Before deciding, confirm Moodle's feature fit against your current Brightspace use separately, using the Brightspace vs Moodle comparison as a starting point, since a cheaper platform that lacks a workflow you rely on is not a saving.
How DeployOpen scopes a fixed-price Moodle implementation
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a Brightspace exit, we turn the cost components in this comparison into a written scope with agreed deliverables and timelines before any work starts.
How we scope
- We inventory your Brightspace subscription, add-on modules, integrations and user populations before proposing a Moodle target design.
- The written scope names hosting location, database, storage, authentication, plugins and the cutover approach for your environment.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins, and a quote follows from that scope.
How we build
- We deploy Moodle on your cloud account, data center or air-gapped network, with the web server document root set to the /public directory.
- We configure authentication, such as SSO and LDAP, and LTI connections for the tools your courses already use.
- We test course packages, gradebook behavior, quizzes and release conditions against a staging copy before any learner sees the new site.
How we hand over
- You receive architecture notes, runbooks, configuration records and the test results that support each deliverable in the scope.
- We document the course rebuild list, including components that must be recreated by hand, so your administrators can see the remaining effort.
- Knowledge transfer covers backups, restore testing and the upgrade path between Moodle releases, so your team can run the platform.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, so the platform keeps pace with new Moodle releases.
- A retainer can cover security patching, backup verification and plugin updates, with the scope agreed in writing.
- Ask for a quote that lists each cost component, the parties paid for each one and which items recur after go-live.
