Why an on-premises Blackboard alternative now needs a new platform decision
If your institution must keep its learning management system in its own data center, Blackboard Learn is no longer a self-hosted option you can simply renew. Blackboard Learn Managed Hosting has not been supported since December 31, 2022, and the latest Learn self-hosted release listed on Blackboard's release schedule is v3900.84.0 from February 15, 2024. Staying on premises therefore means changing platform. The two open-source options that run in your own data center are Moodle and self-hosted Canvas LMS, and the decision in front of you is which of them your team can operate well for years.
Treat this as a decision about operating burden, not feature parity alone. Both platforms cover the core needs of most institutions, from course delivery and gradebooks to LTI integrations. What changes is the work your staff takes on: applying upgrades, keeping the database and web tier current, testing plugins against each release, running backups and restore tests, and meeting availability targets for students during exams. Moodle publishes a six-monthly release cadence with long-term support releases, and its major releases raise PHP and database requirements, so your team needs a dated upgrade plan. Canvas LMS is AGPLv3 code with Quick Start and Production Start guides, but self-hosting puts those upgrades and support on your staff or a partner.
Before you choose, confirm the staffing model, the database and PHP versions your infrastructure team can support, the authentication and SIS integrations you must keep, and who carries the on-call duty for the platform. Ask any partner to put patching, backup, restore testing and availability responsibilities into a written scope. Those answers will show whether Moodle or Canvas fits your data center better than either fits a feature checklist.
What an in-house LMS must cover that a SaaS vendor used to carry
Moving the LMS into your own data center moves every operating duty that a hosted vendor handled onto your team or partner. The cards below cover the decisions that most often get underestimated: where data sits, which PHP and database versions the platform needs, how backups are restored, how the web server is set up, and how sign-in connects to your directory.
Hosting and data location
Owning the platform means you choose the data center, storage layout and network path for course content, grades, submissions and student records. Confirm where backups and logs are copied, who holds administrator access to the database and file store, and which records retention rules apply to each location. Write these answers down before procurement, because they shape the hardware and staffing estimate.
PHP and database version support
Each Moodle release sets its own minimum PHP and database versions, so an upgrade can require a PHP or database upgrade first. Moodle 5.1 requires 64-bit PHP 8.2 or later, while Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17. Plan the runtime and database upgrades as part of each release cycle, and test them on a copy of production before any change.
Patching and upgrade paths
Moodle ships major releases in April and October and point releases every two months, so the team needs a standing patch calendar rather than occasional projects. Check the support end date of the version you run, and confirm that your current site meets the minimum version for the next upgrade. A site that falls behind may need several steps to reach a supported release.
Backups and restores
An LMS backup has two parts that must be captured together: the database and the moodledata file store that holds uploads and submissions. Test a full restore on a separate server at a set interval, and record how long it takes, because that figure drives your recovery commitments to faculty and students. Confirm that course backup files and archives are kept under the same retention rules as the live data.
Web server configuration
Moodle 5.1 changed the web root, so the server must point the document root to the public directory in the Moodle folder. If it does not, the site can show directory listings or errors. Include this setting in your build notes, your configuration management and your change checklist, so that a new server or a version change does not expose the code folder.
Authentication integration
Your directory and sign-in service now connect to the LMS directly, so this integration is your responsibility. Moodle core ships plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, and SAML2 comes from a separate marketplace plugin. Confirm which plugin your identity provider supports, test account provisioning and deprovisioning, and document how sign-in is restored if the directory is unavailable.
Which open-source LMS fits an on-premises mandate
This table compares Moodle, self-hosted Canvas LMS and Open edX against the requirements an institution faces when the LMS must stay in its own data center. Read each row as a question to answer with your own infrastructure team and your Blackboard course inventory in hand. The main takeaway is that Moodle has the broadest published self-hosting path and documented requirements, while self-hosted Canvas trades that breadth for a simpler migration path from Blackboard but leaves support to the community.
| Requirement | Moodle | Self-hosted Canvas LMS |
|---|---|---|
| Licence and source access | GPL version 3, with source code in the public Moodle GitHub repository | AGPLv3, with source in the canvas-lms repository and Quick Start and Production Start guides in its wiki |
| Fit for on-premises hosting | Downloaded and run on your own servers, or through MoodleCloud or Moodle Partners if you choose managed hosting | Run on your own infrastructure using the repository guides, with your team owning installation and operations |
| Database support (Moodle 5.1) | PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later | Confirm current database versions in the Production Start guide before sizing your database tier |
| PHP and web server requirements | 64-bit PHP 8.2 or later (8.3 and 8.4 supported). From 5.1, the web server root must point to the /public directory | Ruby and Node-based stack described in the repository wiki; confirm required versions with Instructure documentation |
| Authentication options | Core plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services, plus SAML2 via a marketplace plugin | Authentication and SSO configuration is documented in the project guides; confirm LDAP, SAML and LTI options for your identity provider |
| Blackboard course migration | Common Cartridge export and rebuilding of items that do not carry over, such as grading and question blocks | Built-in importer for Blackboard 6 to 9 and Ultra exports, with manual rebuilding of items after import |
| Support model | Community forums plus commercial support from Moodle Partners, which you select and contract | Community support only for self-hosted installs, so your team or a contracted partner carries all incident response |
| Upgrade path | Major releases in April and October, with long-term support releases; upgrades require a minimum prior version (4.2.3 for 5.1) | Upgrade cadence and process set by the project; plan a staging rehearsal before each production change |
What running the LMS in-house adds to patching, backups and availability
Moodle ships major releases in April and October and point releases every two months, in February, April, June, August, October and December. Your institution decides which line to run and when to apply each update. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.1 has security support until 19 April 2027. Moodle 5.3 is the next LTS, with security support until 1 October 2029. Staying on a release past its security window means carrying known vulnerabilities into a system that holds student and grade data.
- Release selection: Choose an LTS line and set a calendar for moving to the next one before security support ends.
- Version prerequisites: Moodle 5.1 needs PHP 8.2 or later and specific database versions, and sites must already be on Moodle 4.2.3 or later to upgrade. Check each jump against the release notes.
- Web root change: From Moodle 5.1, the web server document root points to the
/publicdirectory, so server configuration changes with the upgrade. - Plugin compatibility: Local plugins, themes and LTI integrations each need their own check before an upgrade.
- Test environment: A staging copy that mirrors production is the only reliable place to rehearse an upgrade.
Effort rises with the number of plugins, custom code, and the number of releases you skip. Ask any implementation partner to quote upgrade rehearsals and post-upgrade testing as separate line items, and confirm your team's on-call coverage for an out-of-window security fix.
An LMS is a database, a file store and a code base, and each one needs a restore path. Moodle keeps course content, submissions and gradebook data in the database and uploaded files in its data directory, so a backup has to capture both at the same point in time. Without that consistency, a restored site can show grades that point to missing files. Your institution owns the backup schedule, retention rules, off-site copies and proof that a restore works.
- Database dumps: Schedule consistent dumps of PostgreSQL, MySQL or MariaDB, with the version checked against the Moodle requirements for your release.
- File store: Back up the Moodle data directory, which holds uploads and course files, on the same schedule as the database.
- Retention and records: Set retention periods that match your records policy for grades, submissions and attendance.
- Restore tests: Restore into a separate environment on a regular schedule and time how long it takes.
- Off-site and immutable copies: Keep a copy outside the primary data center that ransomware on the main network cannot reach.
Effort grows with database size, the number of courses and attachments, and how strict your recovery time requirements are. Confirm with your backup vendor or the open-source tool you choose how it handles application-consistent snapshots, and ask for restore evidence in any quote.
Availability for an LMS depends on the tier you build, not on a single server. Exam weeks, enrollment deadlines and course starts produce short peaks in logins, quizzes and file uploads. A single node may be enough for a small deployment, but larger institutions usually add load-balanced web servers, a shared file store, a database with failover and a cache layer. Your team owns monitoring, capacity planning and the runbook for each failure mode. Moodle's own documentation on performance and scaling should guide the design, and you should confirm the topology with the people who will run it.
- Topology: Decide between a single node, a load-balanced pair or a clustered deployment, and document the failover steps.
- Peak planning: Measure concurrent users during the busiest weeks of the academic calendar and size for those peaks.
- Monitoring: Track response times, queue depth, database connections and disk growth, with alerts routed to a staffed on-call group.
- Maintenance windows: Agree on a window that avoids assessments and communicate it to faculty well in advance.
- Disaster recovery: Define how long the LMS can be down and where it fails over to.
Effort rises with the number of concurrent users, the number of integrations that depend on the LMS, and the uptime you promise students. Ask for a written architecture and a failover test as part of any scope.
Authentication is part of availability. If the LMS depends on a directory or single sign-on service that fails, students and staff cannot log in, even when the LMS itself is healthy. Moodle core ships authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Institutions that use SAML sign-on typically add the SAML2 Single sign on plugin from the Moodle plugin marketplace. Your team owns the connection to the identity provider, the account lifecycle, and the emergency access path for administrators.
- Identity source: Choose the authoritative source for accounts, usually a directory or the student information system, and document it.
- Plugin choice: Compare core options such as LDAP and Shibboleth with the SAML2 plugin for your identity provider.
- Account lifecycle: Define how accounts are created, changed and removed when students graduate or staff leave.
- Break-glass access: Keep a local administrator account that works when the identity provider is down, and store its credentials securely.
- Certificate and secret rotation: Plan renewals for signing certificates and client secrets used by SSO connections.
Effort rises with the number of identity sources, custom attribute mappings and the number of external tools that rely on the same sign-on. Confirm which identity provider you will connect to and ask any partner to quote the identity work as its own scope item.
How to deploy Moodle in your own data center step by step
This sequence takes an institution from a chosen Moodle release to a tested, backed-up, piloted installation in its own data center, with each step producing a checkable result before the next one begins. Confirm the version and prerequisites first, because every later decision depends on them.
Confirm the target Moodle release and support window
The platform owner and the academic leadership choose the release line before any hardware is ordered. Compare the candidate with the Moodle releases page: Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next LTS with security support until 1 October 2029. Note that Moodle 5.1 has general support only until 5 October 2026 and security support until 19 April 2027. Your existing site also sets the path: to upgrade to Moodle 5.1 your site must already be on Moodle 4.2.3 or later, and to upgrade to Moodle 5.3 it must run Moodle 4.4 or later. Done when a written decision records the target release, its end-of-security date and the upgrade starting point for your current installation.
Provision PHP, database and web server versions
The infrastructure team builds the application servers to the requirements of the chosen release. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and 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 (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Confirm each version against the release notes before installation, since a mismatch blocks the install or upgrade. Done when a test host reports the correct PHP build and the database engine responds to a connection from the application tier.
Point the web server at the public directory
From Moodle 5.1 onward the web server document root must point to the new /public directory rather than the main Moodle folder. Configure the virtual host accordingly and confirm that the site loads without directory listings or errors. A misconfigured root is one of the most common causes of a blank or exposed site after a fresh install, so verify it on a test URL before opening the service to users. Done when the front page loads over HTTPS from the document root and the main Moodle folder is not served directly.
Connect identity with LDAP, Shibboleth or SAML2
The identity team wires Moodle to the directory the institution already uses. Moodle core includes authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Where the institution uses a SAML identity provider, the SAML2 Single sign on plugin from the Moodle plugin marketplace is the usual route, and it needs to be checked against the chosen Moodle release before installation. Test with a small set of accounts, including a suspended account and a staff account with a teacher role. Done when test logins map to the correct roles and a disabled directory account can no longer sign in.
Set up backups and prove restores work
The operations team defines what is backed up: the database, the moodledata directory with uploaded files, the code tree and the configuration. Schedule these backups separately so each can be restored on its own, and store copies off the primary host. A backup that has never been restored is not a backup, so run a restore into an isolated environment and confirm that a course opens, a quiz loads and a file downloads. Record the time the restore takes so the recovery expectation is based on evidence. Done when a documented restore has been completed and signed off by the operator.
Run a pilot with imported courses
Choose a small set of courses that represent different teaching styles, and import them into the pilot site using the export path agreed for your source LMS. Expect that some content, such as gradebooks, question banks and LTI links, will need rebuilding rather than arriving intact, so list these gaps per course. Ask a few instructors and students to complete typical tasks, and log every defect. Confirm that the LTI tools and the student information system connections behave as expected in this environment. Done when the pilot owner has a signed list of open defects, each with an owner and a fix or an accepted workaround.
Cut over and confirm the production state
Schedule the cutover in a window agreed with academic and support staff, freeze changes on the source system, run a final export and import, and point users to the new address. Keep the source system readable until the institution has confirmed that all required records are in place. After go-live, check the logs, the cron job status, scheduled backups and the security update process for the chosen release. Done when the production site passes a smoke test, the first backup after cutover has been verified by a restore, and the operating team has a named owner for patching and upgrades.
How course content moves from Blackboard without losing the archive
The first decision is which path carries the content. Canvas's Course Import Tool accepts Blackboard 6, 7, 8, 9 and Ultra exports directly, as well as Common Cartridge ZIP and IMSCC files, so an institution moving to self-hosted Canvas LMS can import from the Blackboard export itself. Moodle has no equivalent direct importer in this comparison, so the usual route is a Common Cartridge export, and Common Cartridge does not carry grading, random question blocks or discussion threads. Those elements need to be rebuilt or exported separately. Confirm the import behavior for your specific Blackboard version and export type with the vendor documentation for both platforms before committing to a schedule, and run a test import of a representative course from each department.
Archives need a separate plan from the working course. A full course archive can contain student submissions, grades and attendance, which makes it personal data under most records retention rules. Decide before import who owns the archive, where it will be stored, how long it must be kept and who may open it. Keep the original package in encrypted, access-controlled storage under your own retention schedule, and import only the course content that teaching staff need. Set the access rules in Moodle roles or Canvas permissions so that archived learner data is not visible to instructors of later terms. Confirm with your records office and data protection lead what the retained copy must include.
Integrations are where migrations most often stall. LTI tools are registered against the course or institution, so each tool needs its consumer key, secret and launch URLs reissued for the new platform, and grade passback must be retested. Authentication is set in Moodle by enabling plugins such as LDAP, Shibboleth or SAML2 through the SAML2 Single sign on plugin, and Canvas handles this through its own authentication settings. Enrollment and grade feeds to the student information system must be reconnected and checked against a term that has already closed. The companion topics on migrating to Moodle and on the Canvas import path cover the step-by-step work, so use them as the next read for each route.
Evidence that an auditor or records office will ask for
An in-house LMS leaves the institution holding every record an auditor, accreditor or records office may request. The cards below cover the records that show the platform was patched, backed up, locked down, located and changed under control. DeployOpen prepares this evidence as part of implementation and support, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Patch cadence against Moodle releases
Keep a dated record of every Moodle upgrade and point release applied, with the version in place before and after. Moodle ships major releases in April and October and minor point releases every two months, so the log should show whether each site stayed on a version that still receives security support. Moodle 4.5 receives security support until 4 October 2027, and Moodle 5.1 until 19 April 2027. Check these dates against your own schedule and record any version that ran past its support window.
Backup and restore test records
A backup that has never been restored is not evidence of recoverability. Keep dated restore tests that rebuild the database, the moodledata directory and the code on separate hardware, then record how long the restore took and which courses and grades were checked afterward. Retain the backup job logs as well, so the records office can see that backups ran on schedule and that failures were handled.
Access control and identity configuration
Document how staff and learners sign in, including the authentication plugins enabled, such as LDAP, Shibboleth, OAuth 2, LTI or SAML2 single sign-on. Keep a record of administrator role assignments, who holds site administrator rights and when those rights were last reviewed. Export the authentication settings on a set schedule, so a change to the identity source can be traced back to a named approval.
Data location and retention documentation
Write down where the database, uploaded files, backups and log stores physically sit, which data centers or regions they reach, and who can administer each one. Record the retention period for course archives that contain student submissions and grades, and the procedure for deleting them at the end of that period. Ask your legal and records teams to confirm which retention rules apply to course archives in your jurisdiction before you set the periods.
Change and configuration records
Keep a change record for each plugin installation, theme change, configuration edit and web server change. Moodle 5.1 requires the web server document root to point to the /public directory, so that move belongs in the change log with the date, the approver and the rollback steps. Tie each change to a ticket so an auditor can follow the request from approval through testing to production.
Questions institutions ask before running an LMS in-house
How does running Moodle in-house compare with SaaS on cost and effort?
Self-hosting moves cost from a subscription to the people and infrastructure that run the platform. The recurring costs are server or data center capacity, storage, database and backup systems, staff time for patching and upgrades, monitoring, and any partner support you buy. Moodle itself is licensed under GPL-3.0, so there is no license fee to pay for the software. Costs go up with user numbers, concurrent exam sessions, the number of integrations (SIS, LTI tools, single sign-on) and how many environments you keep for testing. Ask any quote to separate one-time items (installation, integration, course migration, hardening) from recurring items (hosting, support, upgrades), and to state which party owns each line.
How long does a move to self-hosted Moodle usually take?
The timeline depends on the scope you agree in writing, not on a standard duration. The main drivers are the volume and condition of courses to migrate, how many integrations must be rebuilt or reconnected, the depth of your identity and SIS work, the hosting environment you provide, and how many approval gates your institution requires before go-live. Plan for a parallel run with Blackboard until the archive and gradebook checks are signed off. Ask any proposal to list milestones, the testing window and the acceptance criteria so you can compare plans on the same basis.
What does our team need to provide before an LMS project starts?
Your team needs to supply access and decisions, not just budget. Typical inputs include a hosting environment in your data center or cloud account, with the PHP, database and web server versions the chosen Moodle release requires; a named owner for the LMS; identity provider access for single sign-on; SIS and roster data formats; and a list of LTI tools and integrations to keep. You also need to define retention rules for student records and archives, and who approves accessibility and assessment settings. Confirm these responsibilities in the statement of work so that delays do not become disputes.
Can our own staff run Moodle without outside help?
Yes, many institutions run Moodle with internal staff, but the work is continuous. Staff must apply point releases, plan major upgrades, maintain the database and cron jobs, manage backups, restore tests and capacity, and respond to security advisories. Moodle's support calendar differs by release, so the team must track which version is in general or security support. Check whether you have people with PHP, Linux, database and identity skills, an on-call rota for exam periods, and a tested restore procedure. If these gaps exist, a retainer or partner can cover them while your team builds skills.
How do we choose between self-hosted Moodle and self-hosted Canvas LMS?
Choose based on your course content, integrations and support model. Moodle is GPL-3.0 licensed, widely deployed, and includes core authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, so it fits many identity setups without extra licensing. Self-hosted Canvas LMS is AGPLv3 licensed, and its Course Import Tool reads Blackboard 6 through 9 and Ultra exports, which can shorten content moves. Self-hosted Canvas has community support only, so weigh that against your need for vendor-backed help. Test both with a sample of your real courses, LTI tools and gradebook exports before deciding.
How is the Blackboard course archive handled in a move?
The archive is handled as a records task, separate from the course content. A Common Cartridge export carries course materials but does not carry all grading, question and discussion data, so archives with student submissions and grades need their own retention plan. Decide which records must be kept, in what readable form, for how long, and who may access them. Keep the original archive under your retention policy, and confirm with your registrar and legal team whether exported grades must be stored outside the LMS. Validate a sample restore before the Blackboard environment is retired.
What does ongoing support look like after go-live?
Ongoing support is usually a retainer that covers the work that recurs after launch: applying Moodle point releases, planning and rehearsing major upgrades, monitoring, backup and restore testing, security patch review, and help with new integrations. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and scope is agreed in writing. Ask any provider which Moodle versions they support, how they handle emergency changes during exam periods, what response expectations apply, and how documentation and runbooks are handed over to your team. Confirm whether support covers your hosting environment or only the application.
What the cost of an on-premises LMS is made of
The Moodle software licence is free under GPL-3.0, so the cost of keeping the LMS in your own data center is almost entirely the infrastructure and people around it. Budget for hardware or virtualization capacity, the database server (Moodle 5.1 supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 and Microsoft SQL Server 2017 or later, so confirm which engine your team already runs and can patch), file storage for course content and uploads, backup storage and recovery testing, and the staff time to run upgrades. Those items recur every year. Integration work for your SSO, SIS and LTI tools, along with the migration of courses and archives, is largely one-time, though integrations need rework at each major upgrade.
Upgrade effort is the component most often underestimated. Moodle ships major releases in April and October, minor point releases every two months, and each major version has its own PHP and database minimums. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, for example, and upgrades are only supported from specific earlier versions, so an institution on an older Moodle may need intermediate steps. Ask any partner or internal team to estimate that work per upgrade cycle, including test environments, plugin compatibility checks and the change to the web server document root for /public introduced in Moodle 5.1.
When you request a written quote, ask for each component to be priced separately: infrastructure with its monthly or annual run cost, database and backup licensing (if any), named roles for patching and on-call availability, the upgrade approach and its test cycle, integration scope, and the migration of archives that contain student records. Ask whether support is retainer-based or per incident, what the response expectations are, and who owns recovery objectives. Confirm each figure with the vendor or partner in writing before comparing it with your current Blackboard invoice.
How DeployOpen deploys an on-premises LMS under your constraints
DeployOpen plans, implements, customizes, hardens, backs up and documents self-hosted open-source platforms inside your own data center, cloud account or air-gapped network. For an on-premises Blackboard alternative, that means a Moodle or Canvas LMS deployment you run, with the operating runbooks your team needs to keep it patched and available.
How we scope
- Written scope fixes which platform, hosting environment, integrations and course content are in and out before work starts.
- We confirm PHP, database and web server versions against the target Moodle release before any build begins.
- Engagements are fixed-scope, and ongoing support, upgrades and testing are available as a retainer.
How we build
- We install and configure Moodle or Canvas LMS on your servers, including the web server document root for the /public directory.
- We set up SSO, LTI and SIS connections and test them against your identity provider and student records systems.
- We run the Blackboard course import and document which content, grades and attachments need manual rebuilding.
How we hand over
- You receive architecture, configuration, backup and restore, and upgrade documentation written for your operations team.
- We test backup restores and a point release upgrade with your staff so the procedure is proven before handover.
- Compliance evidence is prepared for your assessors, though independent auditors and certification bodies issue any reports.
How we support
- Retainers cover patching, upgrades, backup monitoring and continuous security testing of the LMS after handover.
- Support scope, response expectations and upgrade cadence are written into the retainer, so you can confirm them before signing.
- Ask any partner to confirm which Moodle release line and security support window your deployment will follow.
