Canvas cost vs self-hosted Moodle: where the money actually moves
A Canvas renewal or pricing change is usually what starts this question. Moodle carries no license fee, since it is GPL-3.0 software, but moving from a hosted subscription to Moodle does not remove cost. It moves hosting, database administration, file storage, upgrades, support and migration effort to your team or to a partner you pay. No Canvas subscription price appears here because none was supplied for this page, so the first step is to get your current renewal terms in writing and compare them line by line against the components below.
The net result depends on three things: how many active users you carry, how much course media you store, and what skills your internal team already has. Map each component to a named owner. Hosting and the database are recurring infrastructure costs that scale with concurrent users and storage. Upgrades are recurring labor, and Moodle's release calendar matters here: Moodle 5.1 needs PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and it requires your site to be on Moodle 4.2.3 or later before you can upgrade. Moodle 5.3 raises the bar again to PHP 8.3 or later and PostgreSQL 17. Ask whether your current version can reach a supported release on the schedule you need, and budget that work as recurring effort rather than a one-off.
Migration is the largest one-time cost and the one most often underestimated. Course packages can move through Common Cartridge, but grades, quiz banks, rubrics and integrations are separate work. Confirm with any implementation partner whether they quote migration as fixed scope, and ask what is excluded. Canvas code is also licensed under AGPLv3, so running Canvas yourself is a separate option with its own cost profile, covered in the self-hosted Canvas section of this group.
Which cost components change when you leave hosted Canvas
This table compares each cost component of staying on Instructure-hosted Canvas with running Moodle yourself, showing who is paid, whether the cost is one-time or recurring, and what drives it. Use it to build your own cost model, then request written quotes for the items where no researched figure is available. The main takeaway is that Moodle removes the license fee but moves hosting, upgrades, storage and support work onto your team or a partner.
| Cost component | Hosted Canvas (Instructure subscription) | Self-hosted Moodle (GPLv3, no license fee) |
|---|---|---|
| Subscription or license | Recurring subscription paid to Instructure; confirm terms and renewal basis in your contract | No license fee; Moodle is GPL-3.0 licensed, so recurring cost is zero for the software itself |
| Hosting and compute | Included in the subscription; Instructure runs the environment | Recurring cloud or data center cost for web, PHP and cron capacity, sized to peak enrollment |
| Database | Managed by Instructure within the subscription | Recurring cost for PostgreSQL 15 or later, MySQL 8.4, MariaDB 10.11 or SQL Server, plus backups and replicas |
| File storage for course content | Included or metered under the contract; ask how storage growth is billed | Recurring storage for course files and backups, which grows with each term and with video content |
| Upgrades and testing | Handled by Instructure on its release schedule | Recurring staff or partner time for major releases in April and October and minor point releases, with staging tests and plugin checks |
| Support staff or partner | Vendor support included in the subscription tier you buy | Recurring in-house administrators or a Moodle Partner or implementation partner; confirm response commitments in writing |
| LTI and SSO integration | Maintained by Instructure for supported tools; confirm which integrations your tools need | Recurring effort to maintain LTI tool registrations and SSO plugins such as SAML2 or LDAP, plus upgrade regression testing |
| One-time migration | None while staying on hosted Canvas | One-time effort to move courses by Common Cartridge, rebuild quizzes and gradebooks, and migrate student records separately |
| Internal skills | Limited to Canvas administration and course design | Recurring need for Linux, PHP, database and web server skills, or a retained partner to cover them |
What moves the Moodle versus Canvas comparison
Running Moodle or self-hosted Canvas moves cost from the vendor invoice into your own infrastructure and staff time. The six factors below set how large that shift is, and each one should be sized against your own enrollment, content and support model before comparing with an Instructure subscription.
Concurrent and total users
Total registered accounts drive database size and licensing scope, while concurrent users during exam weeks and enrollment peaks drive web and PHP capacity. Both usually rise together, so the cost of running more application nodes and a larger database grows with each. Ask Instructure for the pricing basis it uses for your user count, then load test your own peak against any Moodle or Canvas sizing you plan to use.
Course file and video volume
Storage cost follows the size of uploaded files, embedded media and backup archives, and it recurs every term as content accumulates. Video is the largest driver, so decide early whether lectures are hosted in the LMS or in a separate media platform. Confirm how long course files are kept after a course ends, since retention rules decide whether storage cost grows without limit.
Availability and backup requirements
A self-hosted Moodle or Canvas needs a defined recovery point and recovery time, which means redundant database and file storage, tested backups and a maintenance window for upgrades. Each tier of availability adds infrastructure and on-call work that Instructure carries in a hosted subscription. Write the availability target into the scope before pricing, because it is one of the largest recurring cost lines.
Number of integrations
Each connection to your student information system, single sign-on provider, external tools delivered by LTI and grade passback adds build, test and maintenance effort. Moodle core ships LTI and SAML-capable authentication options, but the SAML2 Single sign on plugin is a separate install you would maintain. Inventory every integration and its owner, since integration count is often the largest hidden cost of moving off a hosted LMS.
In-house skills for PHP, PostgreSQL and Linux
Moodle is written in PHP and needs a database and Linux operations skills to keep running, while self-hosted Canvas adds Ruby, Redis and Passenger to that list. If these skills already exist in your team, the cost is largely internal time; if not, it becomes a recurring partner or hire cost. Ask whether your team can own on-call operations for the platform, not only the first installation.
Number of Moodle major upgrades
Moodle ships major releases twice a year, and each one changes requirements such as the PHP version and the supported database versions. The number of major upgrades you absorb over your contract period depends on which release line you choose and how often you move to it, so a long-term support release reduces how often you upgrade. Plan the upgrade test cycle, plugin compatibility checks and staff time for each one, and ask any partner to price them separately.
How to build the Canvas cost comparison with your own numbers
This sequence turns a vague sense that Canvas is expensive into a line-by-line model you can defend to finance, covering the current contract, your users and courses, infrastructure, upgrades, people and one-time migration. The output is a three to five year comparison built on written quotes and your own figures.
Gather the current Canvas contract and invoices
Pull the signed Instructure agreement, every order form and amendment, and the last twelve months of invoices, then list each recurring line: subscription tier, user or enrollment licensing, support plan, sandbox or test instances, add-ons and any overage charges. Ask your account contact to confirm in writing which lines renew automatically, the notice period, and whether price increases are capped. This step is done when every invoice line maps to a contract clause and you know the renewal date.
Count users, courses and enrollments
Pull active users per academic term or per year from Canvas reports and your identity system, then separate students, instructors, administrators and external guests, because licensing models often price these differently. Count published courses, sections and course shells that are created but unused, since archived content still affects storage. Record peak concurrent usage around exam and enrollment periods, because that peak drives the sizing of web and database capacity. This step is done when you have a yearly baseline and a growth assumption you can explain.
Size the file store for course content
Measure the total size of uploaded course files, media, and exported archives from Canvas, then add the growth rate from your enrollment counts. Decide how long to keep archived courses and whether video moves to a separate media service. Object storage is usually priced per stored gigabyte and per request, so ask your cloud provider or storage vendor for a quote based on that sizing. This step is done when you have a stored-gigabytes figure for year one and year three.
Price compute and managed PostgreSQL in your environment
Map the self-hosted stack to your own cloud account or data center: application servers, background job workers, Redis, a PostgreSQL database with backups, load balancing, monitoring and a non-production environment for testing upgrades. Canvas self-hosting follows the Ruby, PostgreSQL, Redis and Passenger stack in the Production Start guide, so confirm the sizing with your platform team. Request written quotes from your cloud provider or data center vendor and from any managed database service. This step is done when each infrastructure line has a quote and a named owner.
Estimate upgrade cycles from the Moodle calendar
If you compare with Moodle, use the Moodle release calendar: major releases ship in April and October, and minor point releases ship every two months. Long-term support releases carry security support for longer, so model which release you would run and when you would move to the next one. Note that Moodle 5.1 requires PHP 8.2 or later and PostgreSQL 15 or later, and that the web server document root must point to the new public directory, so include test cycles for each upgrade. Ask your Canvas contact for the equivalent upgrade commitments, then record the internal and partner effort per upgrade. This step is done when you have an upgrade calendar and an effort estimate per cycle.
Add support and staff time
Compare what Instructure's support plan covers against what your team or a partner would cover: on-call operations, security patching, certificate and backup management, plugin or integration maintenance, and first-line helpdesk for instructors. Estimate the staff roles involved, whether that is existing staff time reallocated or new hires, and whether you will buy a partner retainer. Ask any partner for a fixed-scope written quote that names response expectations and the scope of the retainer. This step is done when each support function has either an internal owner with allocated hours or a quoted external line.
Scope the one-time migration
List the migration work separately from recurring costs: exporting courses as Common Cartridge, exporting quizzes and grades, rebuilding quizzes, rubrics and gradebook setup, re-registering LTI tools, configuring single sign-on and enrollment sync, validating content, and training instructors. Ask a partner for a fixed-scope quote based on your course count and the number of integrations, and confirm which items you will do internally. Keep student records and grade history in a separate export because course packages alone do not carry them. This step is done when the one-time items sit in their own column and each has an owner or quote.
Model a three to five year horizon in your finance template
Place the recurring lines (subscription, infrastructure, storage, upgrades, support and staff) and the one-time migration costs into your own finance template across a three to five year horizon. Keep the Instructure renewal scenario and the self-hosted scenario side by side, apply the same growth assumptions to both, and show the year in which one-time costs are recovered, if they are. Share the model with your CFO, CISO and the academic leadership so assumptions are visible, and confirm each line against its written quote. This step is done when both scenarios total on the same basis and every line cites a quote, an invoice or a documented internal estimate.
How Moodle upgrade timing shapes the recurring cost
Moodle's support windows set the pace of upgrade work, so budget for upgrades as a recurring line item rather than a one-time project. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027. Moodle 5.1, released 6 October 2025, has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.3, released 5 October 2026, is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Each window ends on a date that forces a move, and an institution that runs an unsupported branch carries the security exposure itself.
The upgrade prerequisites add work that compounds. Moodle 5.1 requires 64-bit PHP 8.2 or later and a site already on Moodle 4.2.3 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later and a site already on Moodle 4.4 or later. An installation that has drifted several releases behind may need intermediate upgrades, a PHP runtime change and a database version change before the target release can be installed. Your internal team or partner should inventory the current Moodle version, PHP version, database engine and web server configuration, including the document root change to the /public directory introduced in Moodle 5.1, before estimating effort.
Before modeling costs, confirm the current support dates and prerequisites on the Moodle releases page, since the dates and minimum versions are the inputs that drive the schedule. Then model each planned upgrade as a line item covering test environment rebuilds, plugin compatibility checks for any LTI tools or authentication plugins, regression testing of quizzes and gradebook settings, and staff time. Ask any partner quoting upgrade support to state in writing which Moodle branches it covers, how many upgrade cycles fall within the contract term, and whether plugin remediation is included.
Canvas and Moodle cost questions buyers ask before hiring help
Does Moodle have a license fee?
No. Moodle is free and open-source software under the GNU General Public License version 3, so the software itself carries no license fee. The costs sit elsewhere: servers and database hosting, storage for course files, staff or a partner to run upgrades, plugin selection and support, and the one-time migration. If you want managed hosting instead, Moodle offers MoodleCloud or Moodle Partners, and those services are priced separately. Ask any provider to itemize the subscription, hosting and support lines in writing so you can compare them with your current Canvas invoice.
Is self-hosting Canvas or Moodle cheaper than Instructure-hosted Canvas?
It depends on the components you would take on, so there is no single answer. Compare each line of your current contract against the self-hosted equivalents: application servers, a PostgreSQL or MySQL database, file storage, backups, monitoring, upgrades and staff time. The main cost drivers are the number of concurrent learners, how much course media you store, how often you upgrade, and whether you already employ people who can run PHP or Ruby applications on Linux. Recurring costs (infrastructure, support, upgrade labor) usually outweigh the one-time migration over a multi-year horizon, but only your own numbers can confirm that. Build the model with each component listed separately.
How long does a Canvas to Moodle migration take?
No duration can be stated from the researched facts, so confirm it with each candidate partner against a written scope. Migration time depends on the volume of courses, how much content comes across as Common Cartridge packages, how many quizzes and rubrics need rebuilding by hand, the number of LTI tools to re-register, the SIS enrollment sync, and how much student record history you must keep. Ask for the phases, the acceptance tests and the cutover plan, and whether a pilot with a subset of courses is included before the full move. A fixed-scope agreement makes the timeline a deliverable you can review rather than an estimate you hope holds.
Can our internal team run Moodle without outside help?
Many teams can, if they have people who already operate web applications, but the answer depends on your staffing and risk tolerance. Running Moodle means owning the install, configuration, plugin choices, backups, security patches and major-version upgrades. Moodle publishes a six-month release cycle, so your team needs a regular upgrade routine rather than an occasional project. Check the release table on the Moodle releases page to see which versions are under security support when you plan. A partner can take on any part of that work, from a one-time setup to a retainer covering upgrades and support, and the split should be written down in the scope.
What skills does a self-hosted Moodle team need?
The team needs working knowledge of several layers. Moodle 5.1 requires 64-bit PHP 8.2 or later, and Moodle 5.3 requires 64-bit PHP 8.3 or later, so PHP administration is essential. The database can be PostgreSQL, MySQL, MariaDB or Microsoft SQL Server, with the minimum versions set per release. Staff also need to manage a web server, Linux, backups, TLS and email delivery. Two configuration details matter on upgrades: from Moodle 5.1 the web server document root must point to the public directory, and sites must already be on a supported earlier version before upgrading. Confirm the exact requirements for your target release on the Moodle 5.1 and 5.3 release notes before you size the team.
How do we move course files, quizzes and grades?
Course content and student records move separately, and the approach differs for each. Course content usually moves as Common Cartridge packages, while quizzes, rubrics and gradebook setup often need rebuilding in Moodle by hand. Grades, completion history and other student records should be exported as their own dataset rather than assumed to travel inside course packages. Storage matters too: course media can be large, so estimate it from your current file inventory and budget object or file storage in your own infrastructure. Ask the partner to show how each category is exported, validated and reconciled, and who signs off on the final record check.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists every deliverable, the environments covered, and the acceptance criteria for each. Request line items for planning, installation, hosting setup, course and quiz migration, LTI and SSO integration, testing, cutover, documentation and training, and mark which items are one-time and which recur as retainers for upgrades, backups and support. Also ask what is excluded, who holds the infrastructure and credentials, how the partner handles data during migration, and what happens when a scope change is requested. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that written scope.
What the one-time migration effort covers
Moving from Canvas to Moodle is mostly a one-time project, separate from the recurring cost of running the platform. The cards below cover the work that tends to decide how large that project is, so you can ask for each item explicitly in any quote.
Course export from Canvas
Courses leave Canvas as Common Cartridge packages, and the Canvas Course Import Tool can read Common Cartridge ZIP or IMSCC files back in, which helps you test the round trip. Export every course you intend to keep, then check that modules, pages, files and links arrived intact. Count the courses and the total file volume first, since both drive the size of this item.
Quiz and gradebook rebuild
Common Cartridge packages carry course content more reliably than quiz behavior, rubric links and grading schemes, so quizzes and gradebook setup often need manual rebuilding in Moodle. The effort depends on how many quiz items and weighted grade categories each course uses. Ask any partner to price this by course and by question type, and to state who verifies grade calculations before go-live.
LTI tool re-registration
Each external tool, such as a publisher content provider or proctoring service, must be registered again with the new Moodle site, with new keys, endpoints and launch settings. Moodle core supports LTI, but every tool vendor has to approve the new registration. Build an inventory of active tool connections now, including who owns each vendor contract, because vendor response times are outside your control.
SIS enrollment sync
Enrollment feeds from your student information system must be rebuilt against Moodle's enrollment and user data model, and tested with a copy of production data before cutover. Mismatched identifiers are the most common cause of duplicate accounts or lost enrollments. Confirm which system is the source of truth for each course and term, and schedule a freeze on enrollment changes during the final sync.
SSO and authentication setup
Moodle core ships LDAP, OAuth 2, Shibboleth and LTI-related authentication options, and a SAML2 plugin is available from the Moodle marketplace if your identity provider requires it. Configuring the login path, attribute mapping and account matching is a one-time task, but it must be tested with real student and staff accounts. Confirm which authentication method your identity provider supports and who maintains the plugin after launch.
Separating grades and student records
Common Cartridge packages hold course content, not the complete record of who passed, what grades they received or what their history looks like. Grades, completion data and audit-relevant records need their own export, mapped to Moodle's data structures and checked against the originals. Decide with your registrar or compliance lead how long the source records must be kept, and make sure that retention applies to the exported copies as well.
Should you run Moodle internally or buy support from a partner?
The core decision is whether salaried staff or a fixed-scope partner will carry the work of running Moodle after go-live. In-house operation means paying for people who can administer the PHP application, the database, the web server, backups, plugin compatibility and upgrades, and who stay on call for outages. A partner engagement replaces part of that payroll with written scope, deliverables and timelines agreed before work starts, plus an optional retainer for ongoing support. Compare the two on the same list of tasks, not on job titles. Ask who owns each task, how often it recurs, and what happens during a holiday or a staff departure. The infrastructure line also changes depending on the hosting model. Moodle can be downloaded and self-hosted, or run as managed hosting through MoodleCloud or Moodle Partners. Managed hosting moves servers, patching and some backup operations to the provider, so your internal cost shifts toward subscription fees and administration. Confirm with each provider which of the following they handle: the web server document root, database versions, storage for course files, backups and restore testing, and the Moodle upgrade path. Also confirm where your data is stored, since that is often the reason an organization chose self-hosting in the first place.
If you self-host, DeployOpen can plan, implement, harden, back up, upgrade and support Moodle inside your own cloud account, data center or air-gapped network. Ask for the scope in writing: which Moodle versions and database engines are covered, how plugins and authentication (such as SAML2 single sign-on) are tested, who approves upgrades, and how restores are verified. Ongoing support, upgrades and continuous testing are available as a retainer, which suits organizations that want a named external team on call without hiring for every skill. A fixed-scope project covers the initial build and migration. Neither option removes accountability from your side: someone internal must own the platform, approve changes and sign off on compliance evidence, and an external auditor or certification body, not DeployOpen, issues any attestation.
How DeployOpen scopes a fixed-price Moodle implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Canvas to Moodle move, we work from a written scope that sets out what is included, what your team owns and how the handover will be evidenced.
How we scope
- Inventory your current Canvas courses, enrollments, integrations and certificates before agreeing any deliverables in writing.
- Confirm which Moodle release line you will run, checking PHP, database and web server requirements against your hosting plan.
- Agree in writing which student records, grades and LTI tools are migrated, and which remain in the source system as an archive.
How we build
- Install Moodle in your environment with the database, PHP and web server settings your chosen release requires.
- Configure authentication, including SSO through a SAML2 plugin or LDAP where your identity setup calls for it.
- Test course imports, quizzes, gradebook setup and LTI launches in a staging environment before any cutover is scheduled.
How we hand over
- Document the architecture, configuration, backup and restore steps, and the upgrade procedure your team will follow.
- Provide the test results and migration reconciliation so your own reviewers can check each agreed deliverable.
- Walk your administrators through daily operations, plugin management and the release calendar before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Ask any provider, including DeployOpen, to state in writing who patches Moodle security releases and within what process.
- Confirm with your auditors which evidence they need, since DeployOpen prepares controls and records but does not issue audit reports or certifications.
