Which open-source LMS fits your situation, and why Moodle, Open edX or Canvas
If your team is shortlisting open-source learning platforms for institutional courses, corporate training or MOOC-style delivery, Moodle fits course-centric teams that want a broad plugin ecosystem and predictable long-term support, Open edX fits teams building large catalogs of public online courses, and Canvas LMS fits institutions that want a Ruby-based course platform with a Canvas-style learner experience. The right choice depends less on feature checklists than on the course model you need, the license terms your legal team will accept, and how much platform engineering you can staff.
Moodle is licensed under GPL-3.0 or later, and its long-term support releases give you a clear planning window. Moodle 5.3 is the current LTS, with general support until October 4, 2027 and security support until October 1, 2029, so a multi-year institutional rollout can plan upgrades around those dates. Its PHP and database stack is familiar to many hosting teams, but each major release raises minimum versions, and from Moodle 5.1 the web server must point at the public directory. The caveat is that Moodle's strength in schools and corporate training comes from its plugin ecosystem, which also means you own the quality and maintenance of whatever you add.
Open edX is licensed under AGPL-3.0 and is built for large-scale online courses, with Studio for authoring and the LMS for learners. Its support model is the sharpest trade-off: the latest named release is the only supported release, and Verawood, published July 30, 2026, is current, with Willow and Xylon listed for December 2026 and June 2027. Upgrades are therefore a recurring program, not an occasional project. The maintainers recommend Tutor for production, which makes Docker and Kubernetes deployment practical, but bare-metal installation is complex and gets limited community support. Confirm with your team whether an AGPL network-use obligation and a six-month release rhythm suit your operations. Canvas LMS is an open-source edition of Instructure's platform under AGPLv3, and it is a strong fit for teams already comfortable with Ruby and PostgreSQL. The Production Start guide calls for PostgreSQL 14 or later, Redis 6.x or later, Apache with Passenger, a background job daemon, SMTP and at least 8GB of RAM, and it directs installation problems to the community mailing list or IRC rather than Instructure support. Its tagged release cadence is clear, but you should confirm the current support commitments and whether the feature set you need is in the open-source edition, since hosted Canvas is the path many institutions take.
Which platform fits which scenario
This table maps common scenarios to the platform that fits best and gives the reason in one line, tied to the licensing, release policy, stack and support facts for each option. Read it as a starting point: the right choice often depends on your hosting team, your upgrade tolerance and who will support the install.
| Scenario | Best fit | Why, and what to confirm |
|---|---|---|
| School or university courses | Moodle | Moodle is built for course-centric teaching and its LTS releases, such as 5.3 with security support until October 1, 2029, give a long upgrade window. Confirm your PHP and database versions against the Moodle 5.3 requirements. |
| Corporate compliance training | Moodle or Canvas LMS | Moodle's core authentication plugins include LDAP, LTI, OAuth 2 and Shibboleth, which often matter for directory-driven training. Confirm which identity protocols your IdP needs and whether Canvas's course model suits your content. |
| Large-scale MOOC-style courses | Open edX | Open edX is designed for large-scale online courses and runs on a single supported named release, so you must plan for upgrades roughly every six months. Confirm your team can absorb that cadence before committing. |
| Teams with a PHP background | Moodle | Moodle runs on PHP, so existing PHP operations skills transfer directly. Confirm the minimum PHP version for your target release, since Moodle 5.3 requires PHP 8.3 or later. |
| Teams with a Ruby background | Canvas LMS | Canvas is a Ruby application that expects PostgreSQL 14 or later and Redis 6.x or above. Confirm your team can maintain Ruby, Passenger and background jobs, and that you have at least 8GB of RAM per the Production Start guide. |
| Teams that prefer containers and Kubernetes | Open edX | Tutor, the Docker-based distribution that Open edX recommends for production, supports Kubernetes deployments. Confirm your cluster standards and plan for the Redis or Memcached cache that multi-node setups need. |
| Teams that want a managed option | Moodle or Open edX via a provider | Moodle can run as managed hosting through MoodleCloud or Moodle Partners, and the Open edX maintainers recommend a service provider for production. Confirm the plugin, data residency and upgrade terms each provider offers in writing. |
| Teams with no in-house platform operations | Depends on the team's own environment | Canvas directs installation problems to community channels rather than vendor support, and bare-metal Open edX has limited community support. Confirm who will run upgrades, backups and incident response before choosing a self-hosted path. |
How the course model separates Moodle, Open edX and Canvas
Open edX is built for large-scale online courses, so its course model starts from authoring and delivery at volume. Studio, the authoring service, is where course teams build content, and the LMS is where learners take it. The Verawood release, published July 30, 2026, added a new Studio sidebar, a redesigned instructor dashboard, and tagging and taxonomy management, all of which shape daily work for course teams. Moodle and Canvas are course-centric platforms for institutional and corporate delivery, where a course usually sits inside a program, a term or a training catalog. Moodle 5.3 adds a learning outcomes feature that fits that model. The supplied facts do not describe Canvas's authoring or instructor interface, so confirm it in Instructure's documentation and a sandbox before you rely on it.
The fastest way to separate these platforms is to run your own course workflows on each. Start with a course that reflects your operation, for example (illustrative) a 12-week cohort course reused every term with graded assignments. Time an author through a mid-term revision, then check how a learner sees the result. Ask whether instructors can reuse a course across cohorts, how enrollments and completions are managed, and whether the instructor view shows what your staff need. Moodle 5.3 removes the Classic theme from core, so confirm that the theme your staff use still works on the version you plan to run.
Reporting expectations also shape the course model. Open edX Aspects captures tracking logs as xAPI statements, stores them in ClickHouse and presents them in Superset dashboards, which suits teams that want learner-level reporting from the platform itself. If your reporting depends on an existing learning record store or LMS export, confirm each platform's options directly with the vendor or community before deciding. Record the test results in writing, because the same course will appear differently to an author, an instructor and a learner, and each of those views needs to pass before you commit.
Side-by-side: license, release policy, stack and identity options
This table compares Moodle, Open edX and Canvas LMS on license, current release and support windows, runtime and database requirements, identity options and analytics. Read each row against your own identity provider, database standards and compliance evidence needs, since the rows reflect documented minimums rather than a recommendation.
| Area | Moodle | Open edX | Canvas LMS |
|---|---|---|---|
| License | GPL-3.0 or later (GPL-3.0-or-later), maintained by Moodle HQ | AGPL-3.0, with Tutor under AGPL and its plugin system under Apache 2.0 | AGPLv3, developed and maintained by Instructure Inc. |
| Current release and support | Moodle 5.3 LTS released October 5, 2026, security support until October 1, 2029. Moodle 4.5 LTS security support until October 4, 2027 | Verawood, released July 30, 2026. Only the latest named release is supported. Willow planned for December 2026 | Release-tagged builds such as release/2026-05-20. Confirm with Instructure which tags you will track and for how long |
| Application runtime | 64-bit PHP 8.3 or later for Moodle 5.3 (8.4 supported) | Python 3.12 for development, with Node.js and MongoDB 7.x listed in the edx-platform repository | Ruby 3.4.1 or later as of the 2025-07-02 release, per the Production Start guide |
| Database and cache | Moodle 5.3 minimums: PostgreSQL 17, MariaDB 11.4, MySQL 8.4 or SQL Server 2019 or later. Oracle is no longer supported from Moodle 5.0 | MySQL 8.0 and MongoDB 7.x, plus Memcached. Multi-node deployments need a shared cache such as Redis or Memcached | PostgreSQL 14 or later and Redis 6.x or above for caching and OAuth2 |
| Core identity options | Core auth plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. SAML 2.0 via a separate marketplace plugin | Third-party auth for OAuth2 providers (Google, Facebook, LinkedIn, Azure AD by default), SAML 2.0, Shibboleth and LTI. CAS and client certificates have older, provisional support | Documented in the Production Start guide only at the level of Redis-backed OAuth2. Confirm SAML, LDAP and LTI support against the current Canvas documentation |
| Analytics | Built-in reporting and logs, with extension through plugins. Confirm the reporting needs of your program against the Moodle release notes | Aspects captures xAPI statements through event-routing-backends, stores them in ClickHouse via Ralph or Vector, and presents them in Superset dashboards | Not covered by the supplied Production Start facts. Confirm analytics and data export options with Instructure |
| Self-hosting guidance | Hosting via MoodleCloud or Moodle Partners is also available. Community support and paid partners cover self-hosted installs | Maintainers recommend a service provider or Tutor for production. Bare-metal installation is complex with limited community support | Production Start guide recommends at least 8GB RAM, Apache with Passenger, a background job daemon and SMTP. Installation help comes from the community mailing list or IRC, not Instructure support |
What each license and edition means for your organization
Moodle's code is licensed under GPL-3.0 (GPL-3.0-or-later according to the repository's COPYING.txt and source headers), and Moodle HQ (Moodle Pty Ltd) maintains the core project. The GPL governs distribution: if you give copies of a modified Moodle to others, you must license those changes under the same terms. Running a modified Moodle only for your own users does not, by itself, trigger that obligation, which is why many institutions customize it without publishing source. Moodle can be self-hosted or run as managed hosting through MoodleCloud or Moodle Partners.
- Release model: Major releases arrive in April and October, and long-term support releases carry defined general and security support windows, so you can plan upgrades around them.
- Current LTS windows: Moodle 4.5 has security support until 4 October 2027, and Moodle 5.3 has general support until 4 October 2027 and security support until 1 October 2029.
- Hosted options: MoodleCloud and Moodle Partners are alternatives to running your own servers, and the hosted plans carry their own limits, which you should confirm before you commit.
- Who pays for what: The license is free, so costs come from hosting, customization, plugin selection, upgrades and support contracts with Moodle Partners or your own team.
Confirm with Moodle Partners or Moodle HQ which hosted plan, support level and plugin rules apply to your organization, and have counsel confirm how the GPL applies to any customizations you plan to distribute.
Open edX (edx-platform) is licensed under AGPL-3.0, and the platform is built on Python, JavaScript and Django. The AGPL extends the GPL's obligations to network use: if you modify the software and let users interact with it over a network, you must make the corresponding source of your modified version available to those users. Hosting an unmodified platform carries no such duty, but any change you make to the LMS or Studio that users reach through a browser can trigger it. Tutor, the Docker-based distribution the documentation recommends for production, is also AGPL, while its plugin and hooks system is under Apache 2.0.
- Single supported release: Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. Verawood, published on 30 July 2026, is the current named release, and Willow and Xylon are listed for December 2026 and June 2027.
- Upgrade cadence: Expect to move to each new named release within its support life, because no older release receives community support.
- Plugins: Plugins built on Tutor's hooks system are under Apache 2.0, which allows a wider range of private extensions than the AGPL core.
- Vendor support: Edly maintains Tutor and offers professional support, and the edx-platform maintainers recommend a service provider for production.
Confirm with counsel whether any planned modification of the platform, including changes to Studio or the LMS, will be offered to network users and what source disclosure that requires. Confirm the upgrade effort you will need to keep pace with named releases.
The instructure/canvas-lms repository is released under AGPLv3, and Instructure Inc. develops and maintains it. Because the license is also AGPL, the network-use obligation described for Open edX applies to any modified Canvas code that users access over a network. The open-source edition is the code in the public repository. Instructure also sells a commercial hosted offering, and that offering is outside the facts this page relies on, so you must confirm its terms directly with Instructure before comparing it with a self-hosted install.
- Source and release tags: The repository publishes dated release tags, such as release/2026-05-20, which you can use to pin a deployed version.
- Stack requirements: The Production Start guide recommends at least Ruby 3.4.1 as of the 2025-07-02 release and requires PostgreSQL 14 or later and Redis 6.x or above.
- Support path: The Production Start guide directs installation problems to the community mailing list or IRC channel rather than to Instructure support, so any paid support must come from a contract you negotiate.
- Commercial boundary: Features, support levels and hosting terms in Instructure's commercial offerings are not covered here.
Confirm with Instructure what support, hosting and feature access, if any, are available to a self-hosted open-source deployment, and have counsel review how AGPLv3 network-use duties apply to your modifications.
What drives the running cost of each platform
Running any of these three platforms costs more than the software itself. The cost comes from the servers and database they need, how often you must upgrade, the skills your team already has, and whether anyone is contracted to answer when something breaks. Use the cards below to build the list of questions you put to each vendor or partner before you sign.
Infrastructure footprint and caching
Canvas's Production Start guide recommends a server with at least 8GB of RAM, and a production install also runs Apache with Passenger, a background daemon for automated jobs and an outgoing SMTP server. Open edX needs a shared Django cache backend such as Redis or Memcached once it runs on more than one node. Moodle's footprint depends on PHP workers, the web root layout and the database you choose. Ask each provider for the node count, cache layer and background job layout behind its sizing, and ask for the figure for your expected concurrent users.
Database and runtime versions
Each platform sets its own minimum database and language versions, and those minimums move with each release. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17 or MariaDB 11.4 as minimums, and Oracle Database is no longer supported from Moodle 5.0. Open edX development requires Python 3.12, MySQL 8.0 and MongoDB 7.x, and Canvas requires PostgreSQL 14 or later with Redis 6.x or above. Budget for patching and version upgrades of the database and runtime, not only the application.
Upgrade frequency and release windows
Open edX names a new release about every six months, and it states that only the latest named release is supported, so each cycle can bring upgrade work. Moodle ships major releases in April and October and offers long-term support releases, such as Moodle 4.5 LTS with security support until 4 October 2027, which spreads upgrade work across more years. Ask how many upgrade cycles your plan assumes over three years, who performs each upgrade, and whether custom plugins or theme changes must be retested each time.
Staff skills and hiring
The skills your in-house team needs decide who you pay for each platform. Moodle is built on PHP, Open edX on Python, Django and React, and Canvas on Ruby, so an internal engineer who already supports one stack will carry more of the load on that platform. Tutor simplifies Open edX operations through Docker and Kubernetes, but customizing the code still calls for Python and frontend work. Ask who on your side will own each stack, and whether the quote includes knowledge transfer and runbooks.
Support contracts and community access
Community support is free but has no response commitment. The Canvas Production Start guide directs installation problems to the community mailing list or IRC channel rather than to Instructure support, and the Open edX maintainers recommend a service provider or Tutor for production rather than bare-metal installs. Moodle hosting and support can come from Moodle Partners or MoodleCloud. Each provider can offer paid support, but the terms vary, so request the response targets, escalation path and what is included in writing before you compare totals.
How release windows change the upgrade workload
Moodle, Open edX and Canvas set very different upgrade rhythms, and that rhythm drives more of the yearly workload than most licensing terms. Moodle ships major releases every six months, in April and October, with minor point releases every two months. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027, and Moodle 5.3, released 5 October 2026, is the next LTS with general support until 4 October 2027 and security support until 1 October 2029. A team that stays on an LTS line can plan fewer major jumps, but it still has to apply point releases on schedule. Moodle 5.1 has general support only until 5 October 2026, so a site on that line has already moved toward security-only coverage. Confirm with Moodle HQ or your Moodle Partner which LTS line you will run and how they handle the 5.3 upgrade path, including the rule that sites must run Moodle 4.4 or later to upgrade to 5.3.
Open edX takes the opposite approach. Its maintainers state that the latest named release is the only supported release, so every installation is expected to track the current line. Verawood, published 30 July 2026, is the 22nd community release, with Willow planned for December 2026 and Xylon for June 2027, both roughly six months apart. Staying current here means moving to each new named release within a short window, because an older release gets no community fixes. Since the installation guide points production deployments toward Tutor, plan for a Tutor version bump alongside each Open edX release. Ask any hosting provider whether they commit to applying each named release, how long they will run a release after its successor appears, and who tests your custom theme and plugins against it.
Canvas does not use named support tiers in the same way. The instructure/canvas-lms repository publishes dated release tags such as release/2026-05-20, and the Production Start guide points installers with problems to the community mailing list or IRC channel rather than to Instructure support. The practical question is therefore which tag you deploy, how often you move to a newer one, and whether the stable branch you choose receives fixes you need. Ask Instructure or your hosting partner for their written policy on security fixes for older dated releases, and confirm how far back the PostgreSQL 14 and Redis 6.x requirements will be supported as the platform moves forward.
What implementing each platform involves, step by step
This sequence takes a team from a written requirements set to a tested, hardened and handed-over learning platform on Moodle, Open edX or Canvas LMS. Each step names what changes per platform so the effort can be compared before any scope is signed.
Define requirements and identity design
Document who the learners and authors are, whether the model is institutional courses, large-scale MOOC-style catalogs or corporate training, and which identity sources must connect. Map each need to a native feature or a plugin. For Moodle, core authentication covers LDAP, LTI, OAuth 2, Shibboleth and web services, and third-party SAML support comes from a marketplace plugin. For Open edX, third-party authentication covers OAuth2, SAML 2.0, Shibboleth and LTI. Confirm each identity connector with the vendor or community before scope is agreed. Output: a signed requirements list with an identity design the team can test.
Select the hosting model and build environments
Decide between your own cloud account, a data center or an air-gapped network, and whether the platform runs on bare metal, containers or Kubernetes. Open edX documentation recommends Tutor for production, and Tutor supports Kubernetes. Moodle runs on a PHP stack with a database, and Canvas needs PostgreSQL, Redis, Ruby and a background job process. Build separate development, staging and production environments with the same versions. Output: working environments that the team can rebuild from code.
Configure the web server and runtime
Install the runtime and database versions that the chosen release requires. For Moodle 5.1 and later, point the web server document root at the /public directory, not the main Moodle folder, or the site may show directory listings or errors. Canvas production installs use Apache with Passenger, a background daemon for automated jobs and an outgoing SMTP server, and the Production Start guide was written and tested on Ubuntu 22.04 LTS. Open edX bare-metal installs are complex and receive limited community support, so many teams use Tutor here. Output: a site that loads over the intended domain, sends mail and runs scheduled jobs.
Build configuration, plugins and theme work
Apply institutional settings, course templates, roles and any theme or plugin changes. Moodle plugins follow its plugin type model, and the Classic theme is removed from core in Moodle 5.3, so theme work must be checked against the release in use. Open edX Studio and frontend plugin slots need custom code that tracks the current named release. Canvas customizations sit on a wiki-documented codebase that the team must maintain itself. Record every change in version control so that upgrades can be reviewed. Output: a configuration repository and a list of custom code with owners.
Migrate course and user data
Move users, enrollments, course content and grades from any existing system. Test imports on a copy of production data, and check character encoding, file storage paths and course structure against the target model. Open edX Aspects analytics depends on tracking logs routed through xAPI, so confirm the reporting design before import. Canvas and Open edX have different course and content models, so a Moodle export is not a drop-in source for either. Output: a migration log with row counts and a sample of checked courses signed off by the business owner.
Test functionality, integrations and load
Run functional tests against the scripted scenarios for enrollment, assessment, certificates, reporting and each integration. Include failure cases such as expired sessions, identity provider outages and mail delivery failures. Check performance at the expected concurrency, since Canvas recommends at least 8GB of RAM and Open edX multi-node deployments need a shared cache backend. Confirm test scope and acceptance criteria in the written statement of work. Output: a test report with defects triaged and retested.
Harden, back up and document operations
Apply the hardening baseline for the web server, database, cache, identity connections and admin access. Set up encrypted backups and test a restore to a clean environment, since a backup that has not been restored is unproven. Document the runbooks for patching, rollback and incident response. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit report. Output: a restore test record and an operations runbook the client team can run.
Hand over and plan upgrades
Transfer administration knowledge, access and runbooks to the operating team, and agree who owns security patches, plugin updates and platform upgrades. Map the support window for the release in use: Moodle 5.3 has general support until October 4, 2027 and security support until October 1, 2029, while Open edX supports only the latest named release. Canvas support on the community route depends on mailing list or IRC help, so decide whether a retainer is needed. Output: a signed handover, an upgrade calendar and a support model agreed in writing.
Questions buyers ask before choosing or hiring help
How much does each learning platform cost to run?
Moodle, Open edX and Canvas can all be downloaded and self-hosted without a license fee, so the recurring cost is the infrastructure, the people who run it and any paid support. The main drivers are server size, database and cache services, outgoing email, background job handling and the staff hours spent on upgrades. The Canvas Production Start guide recommends at least 8GB of RAM, and a production Canvas install also needs PostgreSQL, Redis, Apache with Passenger and an SMTP server. Managed options such as MoodleCloud or Moodle Partners are separate subscriptions. Ask each vendor or partner for an itemized quote covering hosting, licensing, support hours and upgrade work, and confirm which items recur each year.
How long does self-hosting take to set up?
The setup time depends on the platform, the target environment and how much customization is in scope, and no reliable duration is established for any of the three. Open edX maintainers say bare-metal installation is complex and receives limited community support, so most teams start from Tutor, the Docker-based distribution. Canvas requires Ruby 3.4.1 or later and PostgreSQL 14 or later for current releases. Moodle 5.3 requires 64-bit PHP 8.3 or later, and sites must run Moodle 4.4 or later to upgrade. Treat any timeline as a function of a written scope, which DeployOpen agrees in writing before fixed-scope work starts, and ask any provider to show the steps it counts.
What skills does our internal team need to run an LMS?
Your team needs skills that match the stack, and the three platforms draw on different ones. Moodle runs on PHP with a supported database, and from Moodle 5.1 the web server document root must point to the new /public directory, so web server administration matters. Open edX is built on Python and Django, and Tutor on Docker or Kubernetes, so customization and container operations are the key skills. Canvas runs on Ruby with PostgreSQL, Redis and Apache with Passenger, plus a background daemon for automated jobs. Assess whether your team can run backups, patch the stack and handle upgrades on the vendor's schedule before choosing.
Can we self-host an LMS without an implementation partner?
Yes, a team with the right skills can self-host any of the three, but the decision depends on capacity, not on whether the software allows it. The Open edX maintainers recommend running production through a service provider or with Tutor, and the Canvas guide directs installation problems to its community mailing list or IRC channel rather than to Instructure support. Moodle has managed hosting through Moodle Partners, and Edly offers professional support for Tutor. DeployOpen can plan, implement, harden, back up, upgrade, document and support a self-hosted platform inside your infrastructure under a fixed scope agreed in writing. Compare that with an internal staffing plan before deciding.
Which LMS has the strongest vendor support?
No single answer applies to every buyer, because each platform offers a different kind of support. Moodle HQ maintains the core code and offers managed hosting through MoodleCloud and Moodle Partners, which suits buyers who want a vendor-backed contract. Open edX is community-driven, with Tutor maintained by Edly, which offers professional support for it. Canvas is developed and maintained by Instructure, but its production guide points self-hosters to community channels for installation help. Ask each vendor which contract tiers, response times and upgrade assistance are included, and get those terms in writing before you compare.
What happens when a platform release reaches end of support?
Once a release leaves support, you need an upgrade plan or accept more security risk, and the windows differ by platform. Moodle 4.5 LTS receives security support until October 4, 2027, and Moodle 5.3 has general support until October 4, 2027 and security support until October 1, 2029. Open edX states that only the latest named release is supported, with Verawood released July 30, 2026, Willow planned for December 2026 and Xylon for June 2027, so you will upgrade more often. For Canvas, check the support window for the release tag you run with Instructure and the community. Budget upgrade work as a recurring cost in every case.
Do GPL or AGPL licenses change our duties if we customize the platform?
Yes, the license can affect what you must share when you modify and host the software, so confirm the obligations with your legal team. Moodle is licensed under GPL-3.0 or later, Open edX and Tutor's core are under AGPL-3.0, and Canvas is released under AGPLv3. The AGPL includes obligations for network-accessed modified versions that the GPL does not carry in the same way, which matters if learners use a customized platform over the web. Plugin licenses can differ from core, as Tutor's plugin system is under Apache 2.0. Ask counsel to review your intended customizations and any third-party plugins before the build starts.
How DeployOpen helps you choose and run your LMS
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Moodle vs Open edX vs Canvas LMS, we start by confirming which course model, identity sources and hosting constraints actually apply to your program before any platform is chosen or installed.
How we scope
- We confirm whether your courses are institutional, corporate or large-scale open enrollment, since that shapes the platform choice.
- Written scope lists the platform version, hosting model, identity integration and data migration each option would require.
- We agree on deliverables and timelines in writing before work starts, because most engagements are fixed-scope.
How we build
- We install the chosen platform in your environment, following its documented production path such as Moodle's /public web root or Tutor for Open edX.
- We configure authentication against your identity provider, including SAML, LDAP, LTI or OAuth 2 where the platform supports them.
- We run security testing on the deployed LMS, covering the web application, APIs and the hosting infrastructure, and document the findings.
How we hand over
- You receive architecture notes, configuration records, backup and restore procedures, and the upgrade path for your chosen release line.
- We prepare the controls and evidence your compliance assessors may ask for, without issuing any audit report or certification ourselves.
- Your operations team gets runbooks for patching, database maintenance and the release calendar, so the handover is not dependent on us.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial handover.
- Retainer scope covers planned platform upgrades, plugin updates and incident response agreed in writing in advance.
- Before you sign, ask for a quote tied to the written scope, and confirm which release support window your retainer will cover.
