When Brightspace or self-hosted Moodle fits your institution
Brightspace tends to fit institutions that want a vendor-operated platform with support, hosting and upgrades handled by D2L, and that can accept the subscription and data location terms in their contract. Self-hosted Moodle fits institutions that need the platform inside their own data center or a chosen cloud region, that have or can hire administrators who will run upgrades, and that want to own the code and its plugin choices. Many institutions land between these positions, so the decision should start with which constraint is binding: a residency rule, a renewal price, or a lack of in-house operations staff.
Three factors decide the outcome. The first is data location: confirm in writing where D2L hosts your tenant and which Brightspace data sets, including learner activity, leave that location, then check whether your residency rule covers backups and support access. The second is operations: a self-hosted Moodle install needs someone to apply point releases, which Moodle ships every two months, and to plan major upgrades, and each Moodle release sets its own minimum PHP and database versions. Moodle 5.1, for example, requires 64-bit PHP 8.2 or later and changes the web server document root to /public, so confirm your server stack before you commit.
The third is integration depth. Moodle core includes LTI, LDAP, OAuth 2, Shibboleth and web services authentication, so most single sign-on and tool links are covered without extra code, but your student information system connector and any Brightspace-specific reporting will need to be rebuilt or replaced. List every integration your institution depends on, mark which ones have a supported Moodle path, and treat the rest as scoped work.
Which platform fits which scenario
This table compares Brightspace and self-hosted Moodle across four common buyer situations and names the better fit in each. Read each row for the reason and the condition that would reverse the choice. Your own data policy, integrations and staffing matter more than general feature lists.
| Scenario | Better fit and reason | Condition where the other option wins |
|---|---|---|
| K-12 district with a strict student data policy | Self-hosted Moodle, because the district can keep student records in its own data center or approved region and control who has database access. | Brightspace wins if the district lacks staff to run a PHP and database stack with patching, backups and upgrades, and its data policy accepts D2L's hosted processing with a signed agreement. |
| University with a central IT team and existing LTI tools | Self-hosted Moodle, if the central team already runs LDAP or SSO and wants LTI and SAML2 or OAuth 2 sign-on under its own control. Core Moodle ships LTI and OAuth 2 authentication plugins. | Brightspace wins if the tool catalog depends on D2L-specific integrations or Data Hub reporting that the team cannot rebuild. Confirm each LTI tool's Moodle registration before committing. |
| Corporate training team with external learners | Brightspace or a managed Moodle host, because external access, SSO for partners and uptime support are usually bought from the vendor. Self-hosted Moodle suits teams with an in-house platform group. | Self-hosted Moodle wins when training data cannot leave the company's network, or when licensing per active learner becomes the largest cost. Ask D2L for its current learner-based pricing terms in writing. |
| Government body requiring on-premises hosting | Self-hosted Moodle, because the code runs in the agency's own infrastructure, including air-gapped networks if the agency can supply updates and packages internally. | Brightspace wins only if the agency accepts a vendor-hosted deployment and its security authorization covers that service. Confirm the authorization scope with the agency's accreditation office. |
How course tools, gradebook and analytics compare
The core question for instructors and training designers is whether Moodle's built-in course, gradebook and competency features cover how your organization actually teaches and assesses. In Moodle, course building, activities, the gradebook and competency frameworks are part of core, so they are available without buying a separate module. Brightspace also provides these functions in its base product, but its licensing and add-on structure should be confirmed in writing with D2L before you compare feature lists line by line. Ask for the exact modules, not a general feature summary.
Test both platforms with real course designs rather than vendor demos. Build one representative course from each side, including a unit with conditional release, a quiz with a question bank, a weighted category gradebook with late penalties, and a group assignment with rubric grading. Then run a sample of grading scenarios: a dropped lowest score, an excused absence, a calculated grade that depends on other items, and a learner who is re-marked after a grade has been exported. Record where each platform needs workarounds, and count those workarounds as part of the effort.
Analytics is where the gap is most likely to matter. Brightspace's analytics and Data Hub reporting may fit your institution's reporting needs, but the depth, the data sets exposed and the scheduling of exports should be checked against a specific list of reports your accreditor, funder or HR team requires. For Moodle, confirm which reports and logs you need, then decide whether the built-in reports and log store are enough or whether you need an external reporting layer. Write these reporting requirements down before the trial, so both platforms are judged against the same list.
Capability, hosting, licensing and support side by side
This table compares D2L Brightspace with self-hosted Moodle on the points that drive a platform decision: course tools, authentication, hosting, licensing and who supports each. Where the supplied research does not cover Brightspace detail, the cell tells you what to confirm with D2L before you decide, so treat those rows as a checklist rather than a verdict.
| Area | D2L Brightspace | Self-hosted Moodle |
|---|---|---|
| Licensing | Commercial subscription from D2L; source code is not available to customers for self-hosting | GPL-3.0 licensed code, free to download, run and modify under its terms |
| Who maintains the platform | D2L develops and operates the product | Moodle HQ (Moodle Pty Ltd) maintains core; partners and your team maintain your installation |
| Hosting models | Vendor cloud operated by D2L; confirm data location and any on-premises options with D2L | Self-hosted on your servers or cloud, or managed through MoodleCloud or Moodle Partners |
| Authentication in core | Confirm supported SSO and directory options with D2L for your identity stack | Manual, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services ship in core; SAML 2 needs a plugin |
| LTI support | Confirm LTI version and tool certification status with D2L | LTI is included in core authentication and tool integration; check each external tool's version |
| Gradebook, competencies and analytics | Confirm competency and analytics feature depth and any add-on modules with D2L | Core gradebook and reporting are included; Moodle 5.3 adds a learning outcomes feature; confirm fit for competency frameworks |
| Release cadence | Set by D2L; confirm update schedule and sandbox availability in your contract | Major releases in April and October; LTS releases such as 4.5 with security support to 4 October 2027 |
| Minimum technical stack | Not applicable for vendor cloud | Moodle 5.1 needs 64-bit PHP 8.2 or later and a supported database such as PostgreSQL 15 or MySQL 8.4 |
| Who supports it | D2L support under your subscription terms; confirm response commitments in writing | Your own team, a Moodle Partner or a support provider such as DeployOpen under a written scope |
Where your learner data lives and who controls it
Brightspace is a vendor-hosted cloud service, so the data location, backups and exit path are set by a contract. Self-hosted Moodle moves those decisions into your own infrastructure, along with the work and evidence that come with them.
Data location and residency
With Brightspace, learner records sit in D2L's hosted environment, and the region and sub-processors are defined by contract. With Moodle, the database, uploaded files and backups sit wherever you deploy them, whether that is your data center, a national cloud region or an air-gapped network. Ask D2L in writing which regions hold your tenant and which sub-processors can access it. Then map the same questions onto your own network diagram for Moodle.
Hosting models for each option
Brightspace is operated by D2L as a subscription service. Moodle can be self-hosted on your servers or cloud accounts, or run as managed hosting through MoodleCloud or Moodle Partners. Each model changes who patches PHP, the database and the web server. Confirm which hosting model your team can staff, and get the managed-hosting terms, data location and support hours in writing before you choose.
Identity integration through SSO and SAML2
Moodle core ships authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, and the SAML2 Single sign on plugin is available from the Moodle marketplace. Confirm that your identity provider supports the protocol you need, test attribute mapping for student and staff roles, and document who owns the plugin updates. Check how Brightspace's SSO configuration maps to the same identity attributes before cutover.
Compliance evidence and who produces it
DeployOpen prepares controls, configurations and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask D2L for its current attestation reports and the scope they cover, including whether they apply to your product tier. For Moodle, the evidence is produced by your team and any managed-hosting provider, so agree on the controls each party owns.
Backup and disaster recovery ownership
In a SaaS contract, D2L typically defines recovery objectives and backup retention. In a self-hosted Moodle deployment, your team owns backup scope, encryption, restore testing and off-site copies of the database and moodledata directory. Test a full restore before go-live, not only backup jobs. Confirm with D2L what export and backup capabilities its contract includes, since these decide how quickly you can recover your records after an incident.
Exit options and data portability
Brightspace exports take the form of course packages and Data Hub CSV exports, and learner data needs a separate plan. Moodle stores its data in an open schema on your own database, so an exit from Moodle depends on your backups and export tooling rather than on the vendor. Before signing, ask D2L what format each data set leaves in and how long exports remain available after termination.
Which Moodle release to run and what upgrades demand
Choosing the Moodle release is the first technical decision in any move off Brightspace, and it determines which PHP, database and web server settings you build against. Moodle ships major releases every six months, in April and October, and point releases every two months in February, April, June, August, October and December. Moodle 4.5 is the long-term support release from 7 October 2024, with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next LTS, with general support and security support running to 4 October 2027 and 1 October 2029 respectively. For a platform that must stay patched through a multi-year contract, the LTS line is the planning baseline, and you should confirm the current support dates on the Moodle releases page before you commit.
The requirements differ between the two targets. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and runs on PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Upgrade paths are also version-bound: a site must already run Moodle 4.2.3 or later to move to 5.1, and Moodle 4.4 or later to move to 5.3. If your current installation is older, you will need intermediate upgrades, each with its own database and plugin checks, so inventory the Moodle version and every installed plugin before you size the project. Check the exact requirements against the 5.1 and 5.3 release notes in your own environment.
From Moodle 5.1, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site may show directory listings or errors. This change affects Nginx and Apache virtual host configuration, reverse proxies and any deployment scripts that assume the old layout, so update the web server configuration and test it in staging before cutover. Also confirm that your PHP extensions, database drivers and config.php settings match the target release, and plan a rollback path with a verified database backup. Your infrastructure team, not the Moodle release notes alone, should sign off these versions against the hosts you actually run.
What each option costs to own, by component
Licensing is only one line in the total. The cards below separate what D2L charges for from what a self-hosted Moodle site requires you to fund, staff and maintain. Use them to build a like-for-like comparison, and ask every vendor and integrator to price the same components in writing.
Brightspace subscription and add-ons
D2L sells Brightspace as a subscription, and optional modules are often priced separately, so the contract may not show the full scope. D2L publishes no list prices for this comparison, so the figure must come from your own quote. Confirm which modules, learner volumes, data retention and support tiers are included, and whether renewal uplifts are capped. Recurring cost is the main driver to model over the contract term.
Moodle hosting compute
Moodle is free under GPL-3.0, but you pay for the servers, web tier, PHP runtime and backups that run it, either in your cloud account, a data center or through a managed Moodle provider. Cost rises with concurrent users, peak exam periods and high availability requirements. Ask for the sizing assumptions behind any hosting quote and whether hosting is billed monthly, annually or per learner.
Database and storage
Moodle runs on PostgreSQL, MySQL, MariaDB or SQL Server, and course files, quiz attachments and backups grow over time. Storage is a recurring line that usually expands each academic term or training cycle. Check which database versions your chosen Moodle release requires, whether the database is licensed or managed, and how backup and restore testing is priced.
Migration work
Moving courses, question banks, enrollments and grade history is largely a one-time project. Brightspace exports, Common Cartridge packages and learner records need mapping, and release conditions or calculated grades may need rebuilding by hand. Ask a provider to price the fixed scope, the test cycles, the cutover window and any data archive that must survive after the contract ends.
Plugins and integrations
Brightspace integrations are typically configured within a commercial product, while Moodle relies on core plugins such as LTI and SAML2 single sign-on, plus third-party plugins for proctoring, reporting or SIS links. Each plugin needs compatibility checks for every major release, security patching and testing. Ask who owns plugin upgrades and whether any plugin is unmaintained before you commit.
Support and the people who run it
With Brightspace, D2L operates the platform and provides vendor support under the contract. With Moodle, support comes from your own administrators, a managed provider or a support retainer, and staffing is a recurring cost that scales with the number of integrations and user groups. Ask any provider to state response commitments in writing, who holds on-call duty, and how security patches and major release upgrades are scheduled.
What a move from Brightspace to Moodle involves
The sequence turns a Brightspace estate into a self-hosted Moodle site with courses, learner records, LTI tools and sign-in working before the old system is switched off. Each step ends with a check that the institution can verify before moving on.
Inventory courses, integrations and users
Your staff list every active and archived course, the departments that own them, the LTI tools and third-party integrations attached to Brightspace, the student information system feeds, and the single sign-on setup. Ask who owns each course and which content must survive. The step is done when the inventory is signed off by academic and IT owners and every integration has a named contact.
Export course packages in Common Cartridge format
Course owners or administrators export each course from Brightspace as a Common Cartridge package, following the export options D2L provides. Confirm which content types the export carries and which it leaves out, especially learner data, which is handled separately. The step closes when every in-scope course has a package stored in your own repository and a log lists each export and its result.
Rebuild components that do not carry over
Some Brightspace features do not map cleanly to Moodle, including release conditions and calculated grades. Course designers rebuild these as Moodle restrictions, grade categories and formulas, and check quizzes and question banks against their original answers. The output is a short register per course listing what was rebuilt, what was dropped on purpose and who approved each decision.
Archive learner records from Data Hub
Export user-level grades, enrollments and activity history from Brightspace Data Hub as CSV files, and store them in a retention-controlled archive outside the new LMS. Records that must be kept for audit or accreditation should not depend on importing them into Moodle. The step is complete when a restore test confirms a sample of records can be read and the retention owner has signed off.
Stand up and harden the Moodle site
Your infrastructure or an implementation partner installs Moodle on your servers or cloud account, choosing a supported release and matching PHP and database versions from the Moodle release notes. Note that from Moodle 5.1 the web server document root must point to the new /public directory. Hardening, backups and monitoring are configured and tested. The step closes when a restore from backup has been demonstrated on a non-production copy.
Import courses and re-register LTI tools
Course packages are imported into a staging Moodle site and reviewed course by course. Each LTI tool is registered again with its new Moodle connection details, and vendors confirm the tools launch and return grades correctly. The check is a test course per tool showing a successful launch, a returned grade and a correct user role, with results recorded in the cutover log.
Cut over single sign-on and the student information system
Your identity team connects Moodle to the directory and single sign-on service, using the authentication methods Moodle ships with or a plugin such as the SAML2 plugin if your identity provider requires it. The student information system enrolment feed is pointed at Moodle and tested with a small set of accounts. The step is done when test users sign in, receive the right roles and enrolments update from the feed without manual intervention.
Run a parallel period and retire Brightspace
Both systems run side by side for an agreed period while instructors confirm content, learners test navigation and the help desk logs issues. Open issues are triaged against a defined severity list before the Brightspace subscription ends. The step closes with a written sign-off from academic and IT owners, a final archive of Brightspace data and a documented rollback plan kept until the end of the retention period.
Questions buyers ask before moving from Brightspace to Moodle
How much does a move from Brightspace to Moodle cost?
The cost depends on scope more than on the software, because Moodle itself is free under the GNU General Public License version 3. The main one-time costs are migration of course content, configuration, theme and plugin work, integrations with your student information system and single sign-on, testing, and staff training. The main recurring costs are hosting, database and storage, backups, security patching, and the administrators who keep the site running. Ask any provider for a fixed-scope quote that lists each component separately, and compare it with your current Brightspace subscription and add-on modules over the same period. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from that document.
How long does migrating from Brightspace to Moodle take?
The timeline is set by how much content and configuration you have, how many integrations must be rebuilt, and how quickly your staff can review migrated courses. Courses exported as Common Cartridge packages can usually be re-imported, but release conditions, calculated grades and some quiz features often need rebuilding by hand, which adds effort per course. Single sign-on and student information system cutover need their own test cycles and a date agreed with your identity team. Ask for a phased plan that separates a pilot of a few courses from the full cutover, and confirm which items the plan assumes your staff will review.
What does a Moodle migration require from our own staff?
Your staff are needed for decisions and validation, even when an outside team does the technical work. Expect named owners for course content review, the gradebook and grading rules, the student information system and identity integrations, and the cutover date. Faculty or trainers should check migrated courses and assessments before go-live. Your security or compliance lead should review hosting, access control and backup design. Confirm in the written scope exactly which reviews are the client's responsibility and how many review rounds are included.
Can our administrators run Moodle without outside help?
Yes, many teams run Moodle in-house, but it needs administrators who can handle the web server, PHP, the database, upgrades, plugins and backups, not only the Moodle admin interface. Moodle's major releases and point releases arrive on a fixed calendar, so someone must plan and test upgrades regularly. Assess your current team against these skills before deciding. If gaps exist, options include training, a support retainer for upgrades and security testing, or a mix of both. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer.
Which Moodle version should we start on?
Start on a version your team can keep patched, and check the support dates before choosing. 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.3, released on 5 October 2026, is the next long-term support release with security support until 1 October 2029. Each version has different PHP and database requirements, so confirm your server stack before selecting one. Also note that Moodle 5.1 requires the web server document root to point to the new /public directory.
How are learner records and grades kept after cutover?
Learner records do not move automatically with course packages. Common Cartridge exports carry course content, not learner data, so grades, enrollments and activity history must be exported separately, for example from Brightspace Data Hub as CSV files. Decide early which records you must keep and for how long under your retention policy, then archive them in a read-only store you control, and import into Moodle only the data you need for active courses. Confirm with your registrar and legal team how transcripts and historical grades will be issued after the move.
What does ongoing support look like after the move?
Ongoing support usually covers Moodle upgrades across point releases, security patching, plugin updates, backup testing, monitoring and incident response. It is typically contracted as a retainer with agreed response expectations, which you should ask each provider to put in writing, along with what is excluded. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask for the upgrade calendar, who approves changes, how restores are tested, and how quickly the team can respond to a security advisory before you sign.
How DeployOpen works on this
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Brightspace move to Moodle, we start with a written scope that fixes what is replaced, what is rebuilt and what is archived before any course is moved.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists which Brightspace courses, gradebook items, competencies and LTI tools are in and out of the migration
- We confirm the target Moodle release and its database and PHP versions against your hosting environment
- Ongoing support, upgrades and continuous testing can be added as a retainer after go-live
How we build
- We install and harden Moodle in your infrastructure, including the web server document root for the /public directory
- We configure authentication for your identity provider, including SSO and LDAP where your directory requires it
- We test course import from Common Cartridge exports and record which components must be rebuilt by hand
- We integrate LTI tools and review gradebook and competency mappings against a sample of real course data
How we hand over
- We document the installed architecture, configuration, plugin list, backup routines and upgrade steps for your team
- We prepare a cutover plan covering the SIS feed, SSO changes, learner communication and a rollback path
- We archive learner records and grade history from Brightspace in formats your records team can retain
- We provide runbooks so administrators can operate the platform without depending on us day to day
How we support
- Support after handover can be agreed as a retainer covering patching, upgrades and monitoring
- Security testing of the Moodle site and its integrations can be scoped separately as applications and APIs testing
- Compliance readiness work prepares systems, controls and evidence for your assessors, who issue any audit report
- Each change to plugins, hosting or authentication is tracked against the written scope and agreed in writing
