Migrate from Canvas to Moodle

Migrate from Canvas to Moodle: what the move involves

A team that has decided to leave Canvas for self-hosted Moodle should expect that course content moves reasonably well and everything that makes a course gradeable has to be rebuilt. Course content travels through Common Cartridge, but assessments, gradebook structure, LTI registrations and SIS sync are rebuilt by hand. Canvas exports course packages as Common Cartridge files, and Moodle's import tooling can take those packages in, so pages, files, modules and links are the easy part. Quizzes, rubrics, grading schemes, weighting and the tool connections to publishers and proctoring vendors need to be recreated and tested in the Moodle instance before any teacher relies on them.

The institution's own IT and academic technology staff usually carry most of this work, because they know the courses, the SIS and the identity setup. Many teams bring in a partner for the parts that are new to them, such as the PHP and database stack, the SSO and LTI configuration, or the enrollment sync. Moodle is licensed under GPL-3.0, so the code can be run in your own infrastructure, and it can also be run through MoodleCloud or a Moodle Partner if hosting is a better fit. Confirm with the Moodle Partner or your partner shortlist which model matches your data residency and staffing needs before you commit to a hosting path.

Student records do not move with the course packages. Grades history, submissions, attendance and completion data need their own export and a plan for where historical records will live after cutover, including how long Canvas stays readable for audit and appeals. Ask your registrar and compliance owner to define that retention rule first, then confirm with the Canvas export options which data can actually be taken out. Run a pilot course through the full cycle, from export to a graded test submission, before scheduling the full cutover.

Which Canvas capabilities map to Moodle and which need rework

This table maps the main Canvas capabilities to their Moodle equivalents and marks each as clean, needs rework or gap. Use it to plan the migration scope, then confirm feature parity against the Moodle version you deploy, since activity types and plugins change between releases.

Canvas capability	Moodle equivalent	Migration status
Modules and course structure	Course sections containing activities and resources	Needs rework: confirm module order, prerequisites and completion rules after import
Pages and files	Page, File and Book resources in course sections	Clean for static content: check internal links and embedded media after import
Quizzes	Quiz activity with question banks	Needs rework: rebuild question banks and settings, and test each question type
Rubrics	Rubric method under advanced grading	Needs rework: recreate criteria and levels, and confirm the method in your deployed version
Gradebook	Gradebook with categories, weights and letter grades	Needs rework: rebuild grade structure by hand; historical grades come from a separate export
Discussions and announcements	Forum activities and course news forum	Needs rework: forum types differ, so map each discussion and export replies separately
LTI tools	External tool activity and LTI registration	Needs rework: register each tool again with new keys, and confirm LTI version support
Single sign-on	Core authentication plugins and SAML2 SSO plugin	Needs rework: configure the identity provider and confirm plugin support with your IdP
SIS enrollment sync	Enrollment plugins and web services, with third-party connectors	Gap: no direct Canvas SIS equivalent, so budget for a connector or custom build

Which exports and integrations to move from Canvas

Canvas course content moves through a small set of export formats, but everything around the course, including grades, enrollments, tool connections and sign-in, is handled separately. Treat each item below as its own workstream with its own owner and test.

Common Cartridge course packages

A Common Cartridge export carries course structure, pages, files, modules and many assignment and discussion objects in a standard package. Moodle's import path needs to be tested against your own export, because Canvas-specific settings and interactive content may not map one to one. Export a test course first, import it into a Moodle staging site, and list every item that arrives empty, renamed or missing.

QTI quiz exports

QTI exports hold quiz questions, answer options and scoring rules, which makes them the closest thing to a portable question bank. Question types, feedback text and randomized question pools do not always carry over in the same form. Plan to review each quiz after import, rebuild any question type Moodle handles differently, and confirm that scoring and attempt limits match what students saw in Canvas.

Zip file exports and attachments

Zip file exports hold the uploaded files that courses link to, such as PDFs, slides and media. File paths and links inside pages can break when the files move, so check internal links after import rather than trusting the import summary. Ask which file types and sizes your Moodle site will accept and whether large media belongs in an external store.

Thin Common Cartridge module content

The Course Import Tool can bring in Thin Common Cartridge files as module content, which suits a set of links and references without full course material. This is useful when you want to rebuild activities in Moodle and keep the structure. Confirm with your Canvas administrator which exports were produced in each format, because the two types look similar and import differently.

Grades and student records

Course packages do not carry gradebook history, submissions, completion data or attempt records. Export grades, submission history and completion logs from Canvas as separate data sets, and decide how long those records must be kept and where they will be stored. Confirm retention obligations with your registrar or compliance team before you decommission the Canvas tenant.

Enrollments, LTI tools and sign-in

Enrollments, sections, LTI tool registrations, developer keys and single sign-on settings are not copied into Moodle. Each external tool needs a new registration in Moodle with its own keys, and each SIS or identity connection must be rebuilt and tested against Moodle's authentication plugins, which include LTI and SAML2 options. Inventory every connected tool and owner before cutover so none is discovered by a failed login.

How the Canvas to Moodle cutover runs, step by step

This sequence moves a Canvas deployment to Moodle in stages, so each course, gradebook and integration is proven before students depend on the new system. Each step ends with a named output that the next step needs.

Inventory courses, integrations and records
Your team lists every active, archived and upcoming course in Canvas, along with its sections, enrollments, LTI tools, external integrations, SIS feeds and any grade or record exports your registrar requires. Owners of each course, the quiz types in use and the rubric-based grading patterns are recorded in the same inventory. Done means one signed-off inventory spreadsheet that names an owner and a migration decision for every item, including items you will retire rather than move.
Check the target Moodle release and server stack
Your platform engineers choose the Moodle release line and confirm the server requirements in the release notes before any install. For Moodle 5.1 the release notes call for 64-bit PHP 8.2 or later (8.3 and 8.4 are supported), and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later, and they require an existing site to be on Moodle 4.2.3 or later before upgrading. For Moodle 5.3 the notes call for PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and a Moodle 4.4 or later source. From Moodle 5.1 the web server document root must point to the new /public directory, otherwise the site may show directory listings or errors. Done means a staging server that passes a fresh install with the document root set correctly.
Build and test a pilot course
Pick one representative course that uses quizzes, a rubric, group work and at least one LTI tool. Import its Common Cartridge export into Moodle, then rebuild quizzes from QTI or manual entry, recreate the gradebook categories and weights, and re-register each LTI tool with its new consumer key and launch settings. Instructors and a small group of test students run the course end to end. Done means a written list of what did not carry over, each item fixed or accepted, and a sign-off from the course owner.
Configure identity, enrollment and SIS sync
Your team sets up authentication in Moodle, including the SAML2 Single sign on plugin if your identity provider uses SAML, and maps Canvas enrollment roles to Moodle roles. The SIS feed that currently creates sections and enrollments is rewritten or replaced to target Moodle's enrollment and user sync methods. Done means a test term loaded from the SIS into staging with correct enrollments, roles and logins, verified by comparing counts against the Canvas roster for the same sections.
Run courses in parallel
For a defined term, new sections run in Moodle while active Canvas sections stay open for reference and for any course not yet moved. Instructors check that gradebook totals in Moodle match the Canvas values for the same students on the same assignments, and support staff log issues in one shared queue. Done means a reconciliation report showing grade differences, each one explained or corrected, and a go or no-go decision recorded by the project owner.
Cut over and archive Canvas
On the agreed cutover date, the remaining courses are imported, the SIS feed is switched to Moodle, and students and instructors are directed to the new site. Canvas is set to read-only, and the final grade and student record exports you took in the inventory step are stored in your records system, separate from the course packages. Done means the cutover checklist is complete, access points point to Moodle, and the archive location and retention owner are documented.
Decommission Canvas and hand over operations
Once the archive is verified and the retention period set by your records policy has been agreed, the Canvas instance and its database, file storage and backups are shut down under change control. Your team confirms that Moodle backups, upgrade dates from the Moodle releases page and security patch ownership are assigned to named staff or a support partner. Done means a decommissioning record, a tested Moodle restore, and an operations runbook that names who applies each Moodle minor release.

What drives the cost and duration of the migration

This table lists the factors that move the cost and effort of a Canvas to Moodle move, why each one matters and how to keep it under control. Read each row as a question to answer in your own inventory before you request a quote. The main takeaway is that course count, quiz complexity and integration depth usually matter more than the license, which is free in both directions.

Driver	Why it changes cost or effort	How to keep it down
Course volume and term structure	Each course needs export, import, review and sign-off, so effort grows with the number of active and archived courses in scope.	Migrate only active and recent terms, archive the rest as read-only exports, and ask the quote to price courses in batches.
Quiz and question bank complexity	Common Cartridge carries course content, but quizzes often need rebuilding in Moodle, and question banks with formulas, random pools or media take longer to verify.	Inventory quizzes by type, retire unused ones, and ask whether QTI exports will be used for quiz content.
Rubrics and gradebook setup	Rubrics, weighting schemes and grade categories are not part of course packages, so they are recreated by hand or scripted, and errors surface in grade reviews.	Standardize grading schemes across courses before the move and ask for a grade-mapping check on a sample course.
Number of LTI tools	Each LTI tool needs a new registration, new keys or client settings, and its own test, and tools that store data in Canvas need a separate data plan.	List every tool, confirm which ones the target Moodle version supports, and drop tools that no longer have active use.
SIS and enrollment sync depth	Moving the enrollment feed from the student information system to Moodle requires new mapping, test loads and reconciliation of enrollments, and the work grows with custom data fields.	Document the existing feed fields and ask the vendor for a test enrollment cycle before cutover.
SSO and identity integration	Replacing Canvas login with Moodle's authentication methods, such as SAML2 through a plugin or LDAP, requires identity testing for staff, students and guest accounts.	Confirm the identity provider and protocol early and ask the quote to list each authentication method separately.
Stored course files and media	Large file libraries and embedded video take time to transfer, check for broken links and store, and affect hosting capacity.	Clean up unused files before export and confirm storage sizing with the target hosting team.
Target Moodle version and database	Moodle 5.1 and 5.3 list different PHP, database and upgrade-path requirements, and an older source installation may need an intermediate step.	Choose the target release against the supported version table, confirm the database engine your team operates, and ask for the upgrade path in writing.
Internal staff and skills	Staff time for course owners, administrators and reviewers is often the largest share of effort, and gaps in Linux, PHP or database skills add partner time.	Name course owners and a technical lead early, and ask a quote to separate staff training from migration work.

What usually goes wrong when moving from Canvas to Moodle

Most Canvas-to-Moodle problems come from assumptions that hold inside one platform and break across two. Quizzes, grade formulas, LTI registrations, enrollment feeds and server configuration each carry settings that do not transfer by default. The checks below are ordered roughly by when they surface in a migration project.

Quiz and question import loss

Common Cartridge and QTI exports carry quiz structure more reliably than every question type or feedback setting. Question banks, random question pools, formula questions and per-answer feedback may arrive partially or as plain text. Import one representative quiz per question type into a staging Moodle course, then compare question counts, points and feedback text against the Canvas original before committing to bulk import.

Gradebook weighting drift

Canvas assignment groups with percentage weights, drop-lowest rules and hidden or muted assignments do not map one to one onto Moodle grade categories and aggregation methods. A course can look correct at the item level while the final grade shifts by several points. Recalculate a sample of students in both systems using the same scores, and confirm each category's aggregation method and whether excluded grades are handled the same way.

LTI tools that fail after re-registration

Each LTI tool must be registered again in Moodle with its own consumer key, shared secret or tool configuration, and launch URLs, and vendors may require new client IDs. Deep Linking content items, grade passback and placement settings are often lost. Keep a register of every tool, its vendor contact and its data retention terms, then test one launch, one deep link and one grade return per tool before enabling it for students.

SIS enrollment mismatches

Enrollment feeds that were configured for Canvas's SIS import do not transfer. Section codes, role names, term identifiers and course short names often differ, so students can land in duplicate courses or miss enrollments entirely. Map each SIS field to its Moodle equivalent in a written specification, run the feed against a test category, and reconcile counts of students, teachers and sections per term before the first live term opens.

Broken links and embedded media

Course pages often link to Canvas file URLs, embedded Studio or YouTube videos, and internal course navigation. After import, these links point to the old domain or to files that did not come across. Run a link checker on every imported course, replace internal links with Moodle file or activity references, and confirm that embedded media plays for a test student account from outside the campus network.

Missing PHP or database versions

Moodle's supported stack changes between releases, and a server that runs an older PHP or database version can block the upgrade path. For Moodle 5.1, the release notes list 64-bit PHP 8.2 or later, PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and require an existing site on Moodle 4.2.3 or later. Check the current version and extension list on the target server before scheduling the install, and confirm the release you choose is still supported for your planned term.

Incorrect web server document roots

From Moodle 5.1, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site may show directory listings, expose code files or throw errors on every page. Confirm the Nginx or Apache virtual host points to the public path during the first deployment, and include a check for directory listing and for configuration files returning errors in the cutover runbook.

How the migration differs by institution size and starting point

A single department moving a small set of courses usually has a narrow footprint: a handful of course shells, a few quizzes, one gradebook pattern and a limited number of LTI tools. The work is mostly content transfer and rebuilding assessments by hand, which is manageable for one team but easy to underestimate when quizzes depend on question banks. Integration work is often light because the department may rely on the institution's existing single sign-on and roster feed rather than building its own.

Course count: Rebuilding a few courses is largely a people task, so the schedule depends on instructor availability more than on tooling.
Quiz rebuilding: Question banks and item analysis are often the slowest part, since QTI exports may not carry every setting you need.
Roster source: If the institution already feeds Canvas from its student information system, confirm who will supply the same feed to Moodle.
LTI tools: Count the tools in use and re-register only the ones the department actually needs.
Parallel run: A short overlap is often enough, provided grades are exported before the Canvas course closes.

Confirm with your institution's registrar and IT team who owns the roster feed and whether Canvas records must be retained for a fixed period.

Questions buyers ask before moving from Canvas to Moodle

How much does it cost to move from Canvas to Moodle?

No supplied fact gives a price for this migration, so the cost depends on the components you pay for: Moodle itself has no license fee under the GPLv3, but you pay for hosting, the database, storage for course files, staff or a partner to install and configure the platform, and the time to rebuild content. Recurring costs include hosting, backups, security patching and upgrades, while the migration effort is largely one-time. Ask any implementation partner for a fixed-scope quote built from your course count, quiz volume, integrations and the number of LTI tools that must be re-registered. Compare that against your current Canvas subscription and its support terms before deciding.

How long does a Canvas to Moodle migration take?

No researched figure gives a duration, so the timeline depends on how many courses you move, how many quizzes and rubrics need rebuilding, how many LTI tools and SIS connections you run, and how much your staff can test. Start with a pilot set of courses to measure real effort, then plan batches by term. Pick your target Moodle release early, because the release calendar affects how long you have to finish. Ask any partner for a written timeline tied to a defined scope rather than a generic estimate.

What does the migration need from our internal staff?

Your team needs people who own course content, people who run identity and enrollment data, and at least one administrator who can install and operate Moodle. Course designers review each imported course, because Common Cartridge imports carry structure and content but not every Canvas behavior. Your identity or SIS team maps enrollment feeds and single sign-on, and your security or platform staff set up hosting, backups and patching. Ask a partner to name which of these roles they cover and which fall to you.

Can our team migrate from Canvas to Moodle without outside help?

Yes, a capable team can do it alone, provided it has Linux and PHP administration skills, a PostgreSQL, MySQL, MariaDB or SQL Server database team member, and time to test. The harder work is usually not the import but the operations afterward: upgrades, security patches, backups and restore testing. Use a partner for fixed-scope pieces you lack, such as hardening, integration, or migration of records. Make the decision based on the skills you have today and the staffing you can keep.

What happens to grades and student records during the move?

Grades, completion history and student records do not travel inside Common Cartridge course packages. Canvas course packages carry course content, so you need a separate export of gradebook and enrollment data, then a defined import or manual rebuild in Moodle. Decide which records are the official source, such as your student information system, and keep an archived copy of Canvas data for your retention period. Confirm with your registrar or compliance lead what must be retained and in what format before you start.

Which Common Cartridge content moves cleanly into Moodle?

Static content such as pages, files and module structure generally moves more cleanly than interactive elements. Canvas exports Common Cartridge ZIP or IMSCC packages, and Moodle does not read Canvas packages natively, so you will convert or rebuild material as part of the work. Expect to rebuild quizzes, rubrics, gradebook setup, assignment settings, and LTI tool links. Test a sample course from each department first, and confirm how each content type converts with the tools you plan to use.

How do Moodle release dates affect our migration plan?

Moodle ships major releases in April and October and point releases every two months, so pick a target that matches your term calendar. 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 on 5 October 2026, is the next LTS with general support until 4 October 2027 and security support until 1 October 2029. Moodle 5.1 requires PHP 8.2 or later and PostgreSQL 15 or MySQL 8.4 or MariaDB 10.11, and the web server document root must point to the new public directory. Confirm current support windows on the Moodle releases page before you commit to a version.

How DeployOpen scopes and runs a Canvas to Moodle migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Canvas to Moodle move is handled as a fixed-scope engagement with written deliverables. The work covers the course export, Moodle build, LTI and SIS connections, and the records that stay outside the course packages.

How we scope

Inventory every Canvas course, quiz, rubric, LTI tool and SIS feed before agreeing the migration scope in writing.
Confirm which courses move as Common Cartridge packages and which need manual rebuilding in Moodle.
Agree who owns grade and enrollment history exports, and where those records will be stored.
Set the Moodle version, PHP and database targets against the release notes before hosting is chosen.

How we build

Stand up Moodle in your cloud account or data center, with the web root pointed at the /public directory.
Rebuild quizzes, rubrics and gradebook categories, then test them against the original Canvas course outcomes.
Re-register LTI tools and configure authentication, including SSO, with test accounts before any learner access.
Configure the SIS enrollment sync and check it against a sample of real course rosters in a staging environment.

How we hand over

Deliver a written runbook covering the Moodle install, backups, upgrade path and enrollment sync configuration.
Document the mapping of each Canvas course to its Moodle counterpart, including exceptions and manual steps.
Provide the grade and student record export files with a description of their format and retention location.
Walk your administrators and course designers through the handover and the open items still to confirm.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, Moodle upgrades and continuous testing are available as a retainer after handover.
Ask your DeployOpen contact to confirm which Moodle release, database and PHP versions the quote assumes.
Confirm with your auditors or accreditation body which evidence they will need from the migration records.

Migrate from Canvas to Moodle