How to export your data from Canvas before the contract ends
Start by exporting course content from hosted Canvas with the Content Exports API, which supports three export types: common_cartridge produces an .imscc file containing the course, qti exports quizzes in QTI format, and zip exports files from a course, group or user. A Common Cartridge export is the main package to plan around, since it can include files, folders, pages, quizzes, assignments, announcements, calendar events, discussion topics, modules, module items and rubrics. Run an export for every course you need, then open each package in a test course on the target platform before the contract ends, so you find gaps while you still have access to the source.
Treat the course package as only part of the exit. Grades, gradebook history, submissions with comments, student enrollments, completion records and certificates are not covered by a course export, and they need their own extraction, usually through reports or the API, with a decision on who keeps them and for how long. Also record the configuration that does not travel in a package: LTI tool registrations, SIS feeds, sub-account settings, rubrics shared across courses, and integrations with your identity provider. Confirm with your Instructure account team which of these data sets your contract entitles you to receive, in what format, and by what date, because the export tools are only available while the subscription is active.
Before you export, ask a short list of questions: how many courses and attachments are in scope, which quizzes depend on question banks, and which external tools embed content that a package will not carry. Check the size of the file storage for each course, since large media libraries can make packages slow to download and slow to import. If you are moving to Moodle or self-hosted Canvas LMS, plan a sample migration of one course per department, verify the grade totals and student records against the source, and keep the exported files in storage you control until the audit trail for the move is complete.
What Canvas exports and in which format
This table lists each export type documented in the Canvas Content Exports API, the method used to request it, the file format it produces and the content it can carry. Use it to decide which export covers each part of a course before you plan the move. Grades, submissions and student records are not course content, so they need their own export path.
| Export type | Request method and format | What it contains | What to confirm before you rely on it |
|---|---|---|---|
| Common Cartridge (common_cartridge) | Content Exports API, returns an .imscc file | Files, folders, pages, quizzes, assignments, announcements, calendar events, discussion topics, modules, module items and rubrics | Which content types your course includes, and whether student-specific data is excluded in your version |
| QTI (qti) | Content Exports API, quizzes exported in QTI format | Quiz questions and quiz structure only | Whether question types, feedback and media survive the trip into the target platform |
| Zip (zip) | Content Exports API, returns a zip archive of files | Files from a course, group or user, without the course structure around them | Folder paths, file size limits and whether linked media is included |
| Course import compatibility | Import into Moodle or self-hosted Canvas using a Common Cartridge or IMSCC package | Package contents as exported, mapped to the target course structure | How the target platform maps modules, quizzes and rubrics during import |
| Grades and gradebook | Not provided by a content export | Outside the course package, so it needs a separate report or data export | The export format your institution uses and who has permission to run it |
| Student submissions and records | Not provided by a content export | Submitted files, enrollment history and completion records sit outside the course package | Retention rules and privacy obligations before you copy any learner data |
| Limits and retention | Set by Canvas and your institution's configuration | Not stated in this table | Export size limits, how long export files are kept and who can request them, in the Content Exports API documentation |
What does not come out in a course package
The Common Cartridge, QTI and zip exports move course content, but they leave out most of what makes a course a record of teaching and learning. Grades, submissions, enrollments, integrations and account settings need their own extraction plan, and each one depends on what your institution's Canvas administrators can export.
Gradebook and grade history
A course package carries assignments and rubrics but not the scores students earned, the gradebook layout, or how grades changed over time. Ask your Canvas administrator which gradebook exports and grade history reports your account can run, and whether they include audit detail. Export final grades per course and keep the raw per-assignment scores, because Moodle will need both to rebuild gradebook categories and check totals.
Student submissions and files
Submitted assignments, discussion replies and quiz attempts belong to students, not to the course template, so they are not in a Common Cartridge file. Confirm with Instructure or your administrator whether submission downloads are available in bulk for the courses in scope and in what file structure. Plan for retention rules, since these records may be needed for appeals or accreditation long after the course closes.
Enrollments and section data
Rosters, section membership, roles and enrollment dates are held by the SIS or by Canvas enrollment records, and a course package contains none of them. Ask whether your institution's SIS export files can be reused in Moodle's enrollment sync, and confirm who owns the mapping between Canvas section IDs and the new course IDs. Without this step, instructors rebuild rosters by hand.
SIS and integration data
Student identifiers, SIS import history and the mapping from Canvas accounts to institutional IDs live outside the course. Confirm with your administrator where these mappings are stored and whether they can be exported. Moodle's authentication plugins, such as LDAP, LTI or SAML2 single sign on, need the same identifiers, so this data decides how accounts match after migration.
LTI tool registrations
External tools such as publishers' content, proctoring or plagiarism checks are registered in Canvas at the account level, and course packages reference them only by link. Export a list of every registered tool, its launch URL, its key and its placements, then ask each vendor whether they support Moodle's LTI tool setup. Treat the consumer keys and shared secrets as credentials and move them through a secrets manager, not email.
Account-level settings and branding
Account settings, feature flags, grading schemes, term dates, themes and custom roles are configured by administrators and are not part of any course file. Record them in a written inventory before the cutover, since Moodle uses its own roles, grade letter scales and theme system. Confirm with Instructure which settings are visible to your administrators and which need a support request.
Why grades and student records need a separate export
A course package carries course structure and content, not learner outcomes. A Common Cartridge export from Canvas, whether it is the .imscc file from the common_cartridge export type or a QTI file for quizzes, holds the files, pages, quizzes, assignments, modules and rubrics that instructors built. It does not carry the scores students earned, the submissions they uploaded, completion status, or the enrollment history that shows who took the course and when. Those records sit in the gradebook, the submission store and the enrollment tables of the hosted instance, so they have to be extracted and stored separately before anything can move to Moodle or self-hosted Canvas. Plan that work as its own workstream with its own owner, not as a side effect of the course copy.
Before you export, have your registrar, records office and legal or compliance team confirm which records you must keep, for how long, and in what form. Retention periods for grades, transcripts, student submissions and training completion are set by your institution, your accrediting body, your funding sources and applicable national or sector rules, and they are not something this page can settle. Ask who owns each record class, whether any records must stay in the original system as the official copy, and whether a copy of the gradebook is an acceptable archive. Also ask how access to archived records will be controlled after the move, since a flat export of learner data can be harder to protect than the source system.
Confirm the destination can receive what you export before you start. Moodle and self-hosted Canvas both need the student identifiers, course codes and term structure to line up with the records you extract, so decide the join key early, usually a stable student ID, and test an import with a small set of courses. Check which grade and completion fields the destination's import path accepts, and record any values that will not map cleanly. Keep the exported records, the mapping and the test results together, because they are the evidence that your records were moved complete and unaltered.
The export sequence and how to verify each step
This sequence moves course content, quiz banks, file libraries and student records out of hosted Canvas into an archive you control, with a check at each stage. The result is a set of packages you can test-import before any migration decision is final.
Inventory courses and terms
The Canvas administrator or instructor lists every course to be kept, grouped by term, along with its owner, enrollment count and whether it is still in use. Keep the list in a spreadsheet with a column for each export type so progress is visible. The step is complete when every course in scope has a row and a named owner, and the list is checked against the Canvas course list for the account. Courses missing from the inventory are the most common cause of gaps found after cutover.
Run common cartridge exports per course
For each course, run a common_cartridge export through the course settings or the Content Exports API, which produces an .imscc file. Record the file name, the export date and the course ID next to the inventory row. Verification is a test import of each .imscc into a sandbox course on the target platform, then a comparison of item counts for pages, assignments, quizzes, discussion topics and module items against the source course. Any mismatch goes back to the owner before the source course is changed.
Run QTI exports for quiz banks
Where question banks matter beyond a single course, run a qti export for the quizzes concerned, since a common cartridge export carries quizzes but a QTI package is the format to review question-level content. Store each file with its quiz name and course ID. Verification is opening a sample of the QTI files and counting questions per quiz against the Canvas quiz statistics page, and confirming that question types, point values and feedback text appear as expected. Quizzes that rely on Canvas-specific features should be listed as needing manual rebuild.
Run zip exports for file libraries
Use the zip export type to pull the files from each course, group or user area that holds documents, media or templates not already embedded in pages. Confirm the file count and folder structure against the Files area in Canvas. Generate a SHA-256 checksum for every archive and for a sample of extracted files, and keep the checksum list with the archive. The step is verified when extracted files match the checksums and the count matches what Canvas reports.
Extract grades and student records separately
Course packages do not carry the gradebook, submissions history, enrollment records or completion data in a form you can rely on for records retention, so export these as separate reports using the gradebook export and the reporting tools your institution already has access to. Confirm with your registrar or HR team which records must be kept and in what format. Verification is reconciling totals for a sample of courses, such as the number of students and the final grade for a known student, against the live Canvas data before the source is archived.
Store the archive with a manifest
Place the .imscc, QTI, zip and record files in a single archive location under your control, with a folder per term and course. Write a manifest that lists each file, its source course ID, export type, date and checksum. Restrict access to the people named in your data governance policy, and confirm that retention rules for student records apply to the copy. The step is complete when a second person can open the manifest, pick any course and find the files and matching checksums without asking the original exporter.
Export approach by scope: single course, department or whole account
A single course is the simplest scope. You run one Common Cartridge export for the course, and where a quiz bank or specific files matter, one QTI or zip export alongside it. The work is small enough to do by hand, but it still needs a check on each package, because the course export is the only copy of the content structure. Confirm the resulting .imscc file opens, that modules and their items are in order, and that quizzes, rubrics and assignments you rely on appear in the package. Grades and enrollment records do not come with the course, so they need their own export and a separate record.
- Export jobs: one Common Cartridge export, plus any QTI or zip exports you need for files or question banks.
- Checks: open the package, compare module structure, and spot-check a quiz and a rubric against the live course.
- Scripting value: low, so manual work is usually acceptable for a handful of courses.
- Records outside the package: gradebook and enrollment data are exported separately.
- Question to ask a provider: whether the single-course steps need any tooling at all, or whether a written checklist is enough.
Before you close the course, confirm that the package and the separate records are stored where the destination team can reach them.
A department usually means a set of courses sharing a term, a template or an owner. The number of export jobs grows with course count, and so does the number of checks, because each package needs its own review. Work scales with the number of courses and with file volume, since large media libraries inside course files add time to each zip and QTI export. Naming conventions and a shared inventory are what keep a department export from becoming a set of loose files nobody can match to a course later.
- Export jobs: one Common Cartridge export per course, plus file-level zip exports where courses hold large media.
- Checks: a per-course review record that notes package size, module count and any failed or missing item.
- Scripting value: high, because the Content Exports API accepts requests per course and can be looped over a list of course IDs.
- Inventory: a course ID list with owner, term and destination name, kept alongside the packages.
- Question to ask a provider: whether they will script exports from your course ID list, and how they will report failures per course.
Confirm with the provider how they will handle courses that fail to export, since a silent gap is harder to find once the course has been retired.
A whole-account move covers every course, sub-account and file store that the institution or company still needs. The work is driven by the number of courses, total file volume and how many owners must sign off. Export jobs run in batches, and the review process needs a sign-off step per owner. Records such as grades, enrollments and submissions are a separate workstream that must be scoped and exported on their own, not inferred from the course packages. Plan for a repeatable pipeline and an audit trail rather than a single run.
- Export jobs: batched Common Cartridge, QTI and zip exports across all in-scope courses, run in waves.
- Checks: automated package validation, sampling by owner, and a reconciliation of courses requested against packages received.
- Scripting value: essential, since manual handling does not scale to account size.
- Records workstream: grade, enrollment and submission exports scoped and governed separately, with retention rules agreed up front.
- Question to ask a provider: whether the pipeline logs every export request and result, and how re-runs are handled without duplicating packages.
Confirm how long you must keep source data and what your data protection terms require before any bulk export begins.
Across all scopes, scripting and handoff decide how much effort lands on your team. The Content Exports API is the supported way to request exports programmatically, and each request returns an export job whose status you can poll before downloading the file. A script that records the course ID, export type, job status and file name gives you the inventory that a single course never needs but a whole account depends on. Handoff to the destination team should include the package, the inventory row and the separate records for that course in one predictable location.
- Export jobs: one API request per course and export type, with status polled before download.
- Inventory log: course ID, export type, job status, file name and any error text in one table.
- Checks: file integrity, package contents and a reconciliation count against the source list.
- Handoff bundle: package, inventory row and records export grouped per course.
- Question to ask a provider: whether the script can be rerun safely, and who owns the credentials and the log after the engagement ends.
Confirm that the export account has only the permissions it needs and that the logs are kept after the move is complete.
What to plan before renewal or termination
Most export problems come from decisions made too late, after the notice window has closed or the subscription has ended. The cards below cover the choices to settle first, so that the Common Cartridge, QTI and zip exports can be tested and archived before access ends.
Confirm the export window
Ask Instructure in writing how long you keep access to your Canvas site after the subscription ends, and whether exports stay available during that period. Confirm which roles can run exports, because the Content Exports API is tied to course permissions. Record the answer in the migration plan so the export work is scheduled against a known end date rather than an assumed one.
Choose the destination and hosting
Decide whether the courses will land in self-hosted Moodle, in self-hosted Canvas LMS or somewhere else, because the export format you need depends on the target. Note the hosting model, the database and the PHP or Ruby stack each option requires, and who will run upgrades. Your choice determines whether Common Cartridge packages alone are enough or whether quizzes need separate handling.
Budget archive storage
Estimate how much course file storage you need to keep, including zip exports of files attached to courses, groups and users. Decide how long archives must be retained and where they will sit, such as on your own object storage or on a backup platform. Ask who pays for that storage after the subscription ends, since archive copies recur as a cost even when the migration itself is one-time work.
Assign owners for grades and records
Name one owner for gradebook exports, enrollment history, submission records and audit logs, because Common Cartridge packages do not carry them. Confirm with your registrar or academic office which records must be kept and for how long. Grades usually need a separate export format and a sign-off step before the source site is closed.
Schedule test imports
Plan at least one test import into the destination platform before the live cutover, using a representative sample of courses that include quizzes, modules and media. Record which items import cleanly, which need manual rebuilding and which fail. Repeat the test after each fix so that the final import runs on known results rather than on the first attempt.
Document what the export omits
Write down every item the export will not carry, including LTI tool registrations, SIS enrollment links, rubric associations and integrations with external tools. Assign each gap to an owner and a fix, such as re-registering a tool or re-importing a roster. This list becomes the acceptance checklist for the cutover and prevents the course packages from being treated as a complete copy.
Preparing the destination for imported course packages
Before any course package is imported, the destination must be a working platform that meets its own upgrade prerequisites, and you should prove the import path with one test course before moving anything in bulk. For Moodle, this means confirming the release you plan to run against its published requirements. The Moodle 5.1 release notes state that the web server document root must point to the new public directory rather than the main Moodle folder, and that otherwise the site may show directory listings or errors. They also list minimum 64-bit PHP and database versions, and a minimum prior Moodle version for upgrades. Treat those figures as facts to verify against the release you choose, not as settled, because the Moodle 5.3 notes list different minimums. Self-hosted Canvas needs the same discipline with its own stack, so check the Production Start guide in the canvas-lms repository for the versions your release expects.
Import one representative course first, ideally a course with modules, files, a quiz and a rubric-scored assignment. Expect the content to arrive, but expect the assessment layer to need work. Quizzes often import as questions that need rebuilding, rubrics may not carry over with their scoring intact, and LTI tool launches need the tools re-registered with new keys and endpoints on the destination. Record every item that did not come across cleanly, because that list becomes the rebuild plan and the basis for the cost estimate you will need from any partner. Confirm with your Moodle or Canvas administrator which authentication method, such as LDAP, SAML2 through the SAML2 Single sign on plugin, or OAuth 2, your users will log in with, since enrollment and identity are configured separately from course content.
Questions buyers ask before exporting from Canvas
How much effort does a full export from Canvas take?
Effort depends mostly on how many courses you export, how much file content they hold, and whether grades and student records must travel with them. A full export is not one action. It is a sequence of course-level Common Cartridge exports, quiz exports in QTI format, zip exports of course files, and a separate extraction of gradebook and enrollment data. The Content Exports API covers the course content side, but it does not replace a gradebook extract. Ask your team to inventory courses by type (active, archived, template) before estimating, because each type follows a different path. Illustrative example: a university with a few hundred archived courses and a handful of active programs needs a triage step before any export starts.
Can our institution export from Canvas without outside help?
Yes, many institutions can, provided they have an administrator with API access, staff who can run exports course by course, and someone who can check the results. Canvas exports are generated from the course itself, so an administrator with the right permissions can request them through the Canvas interface or the Content Exports API. The harder parts are the scripting for bulk runs, handling failed or large exports, and verifying that the packages open and contain what was expected. Outside help is most useful for bulk automation, verification sampling and records that must be documented for an audit. DeployOpen plans and implements such work under a written, fixed scope, but the decision to use outside help is yours.
What do administrators and instructors need to contribute?
Administrators own the export process, access to the Canvas account, and the decisions about retention and which records must be kept. Instructors are needed to confirm which courses are still in use, to flag content that is unfinished or unpublished, and to review quizzes, rubrics and question banks that will need rebuilding. Plan a short review window for each course owner. Without it, teams often discover after cutover that a quiz was exported but its settings or question pools were not what the instructor expected. Ask your registrar or records office to define which grades and attendance records must be retained and in what form before any export begins.
How long does a Canvas export project typically take?
The timeline depends on the number of courses, the total file volume, how many courses need manual review, and how quickly your team can respond to questions. Large file libraries and courses with many embedded media files take longer to export and to check. Exports that fail and need retrying add time, as do institutional approval steps for records retention. No duration can be stated here without your inventory. Ask any provider for a timeline tied to a written list of courses, file volumes and review steps, and for the assumptions behind it. Confirm with your Canvas administrator the export limits and any rate or queue constraints in your instance.
Which parts of a course are not fully covered by a Common Cartridge export?
A Common Cartridge export captures much of the course structure and content, including files, pages, quizzes, assignments, modules and rubrics, according to the Content Exports API documentation. It is still a content package, not a full record of the course. Gradebook data, student submissions, enrollments, learner progress, and some integrations with external tools (LTI registrations and their settings) are not carried as a complete record in the package. Verify each category against your own course samples before the migration plan is signed off. Keep the Canvas instance accessible for read-only reference until you are satisfied with the target.
How should grades and student records be exported separately?
Grades, submissions, enrollments and progress records should be extracted as structured data, separate from the course packages, and stored under your records retention policy. Course packages alone do not preserve the gradebook. Plan a dedicated extract for each term, confirm the fields with your registrar, and store it encrypted with access restricted to the people who need it. Test a sample by reconciling a few students' final grades against the source before relying on the extract. Ask any provider how they will document this extract, how they will protect the data in transit and at rest, and who signs off on completeness.
What should a quote for Canvas export support include?
A quote should follow from a written scope and list each component separately, so you can see who does what. Ask for the course inventory assumptions, the export methods for each content type, the bulk automation work, the verification approach and sample size, the grade and record extraction method, the handover documentation, and any post-export support. Ask which items are one-time and which are recurring, such as retention storage or support retainers. DeployOpen does not publish a price list. Its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
What does it cost to keep Canvas exports and records after migration?
Ongoing costs are mainly storage for exported packages and records, access control and logging, and time spent by staff who answer questions about archived content. One-time costs include the inventory, export runs, verification, and the extraction of records. Storage cost rises with file volume and retention length. Access control cost rises with the number of people and systems that need archive access. Ask for the storage format, the retention period set by your records office, and how archives will be searched and restored. No storage figures are given here because they depend on your own volumes and policy.
How DeployOpen scopes and delivers a Canvas data exit
DeployOpen plans and delivers a Canvas data exit as a fixed-scope engagement inside your own infrastructure. We agree in writing which course packages, quiz exports, file archives and student records are in scope before any export runs, then document and hand over each set so your team can verify it.
How we scope
- Inventory which courses, terms, sub-accounts and content types must leave Canvas, and which can be retired.
- Agree in writing how each content type is exported: Common Cartridge packages, QTI quiz exports or zip file exports.
- Define separately how grades, enrollments, submissions and other student records are extracted and where they will be stored.
How we build
- Run the Content Exports API calls for each course and record which export type produced each file.
- Test that exported packages import into the target Moodle or self-hosted Canvas LMS environment, and log every gap found.
- Document the field-level mapping for grades and student records so your registrar or HR team can check them independently.
How we hand over
- Deliver the exported archives, mapping documents and a reconciliation report showing what was exported and what was not.
- Walk your administrators through the import steps, the known gaps and the items that need manual rebuilding, such as rubrics and LTI tool setup.
- Store the export artifacts in your own storage with access controls you approve, and confirm retention with your compliance owner.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the exit is complete.
- Confirm with your auditor or compliance owner which exit evidence they need, since DeployOpen prepares records but does not issue audit reports or certifications.
- Ask any provider, including DeployOpen, to confirm in writing the scope, deliverables and timeline before work starts, since no prices are published and a quote follows the agreed scope.

