How to export your data from D2L Brightspace

How to export your data from D2L Brightspace before the contract ends

If your Brightspace renewal, price change or exit decision has a deadline, start the export inventory now. Brightspace lets you export course packages in Brightspace or Common Cartridge format, but those packages leave out learner data. User-level data sets for grades, enrollments and activity history come from Data Hub as CSV exports, so learner records need a separate archive plan. Treat the course packages and the Data Hub sets as two different projects with two different owners.

Formats, file limits and Data Hub access depend on your contract and product version, so confirm them early with D2L and with your Brightspace administrator. Ask which package formats your tenant can export, whether course exports include the content types your teachers actually use (quizzes, question libraries, release conditions, rubrics and discussions), and which Data Hub data sets your role can open. Ask also how long exports stay available after the contract ends. Run one trial export of a single course and one Data Hub set before the deadline, so you learn about gaps while you still have full access.

Once you have a sample, record what each export contains and what it omits, then decide where the learner archive will live. Your administrator or records team should confirm retention rules for grades and attendance records before anyone deletes data from Brightspace. Keep the export files in storage you control, with access logs, and check that the sample files open correctly in the tools you will use to review them. Gaps found at this stage are cheaper to resolve than gaps found after cutover.

What you can export from Brightspace and in which format

This table lists each data type you can pull out of Brightspace before a contract ends, the method used to get it, the output format and what you must confirm in D2L's documentation. Course packages carry content but not learner data, while Data Hub CSV sets carry the user-level records you need to archive. Treat the export method and role requirements as items to verify with your D2L administrator before the exit timeline is set.

Data type	Export method	Output format	Confirm before relying on it
Course content (Brightspace format)	Course export from the course admin tools by an instructor or administrator with course export rights	Brightspace course package, a ZIP archive	Whether your role can export every course, and whether quizzes, question libraries and release conditions are included
Course content (Common Cartridge)	Course export to Common Cartridge from the course admin tools	Common Cartridge (IMSCC) ZIP file	Which components Brightspace writes to the package, and how Canvas or Moodle import them afterward
Grades and gradebook data	Data Hub data set for grades, selected by an administrator	CSV	Which grade items, calculated grades and rubric scores appear in the data set, and the role required
Enrollments and course membership	Data Hub data set for enrollments	CSV	Whether section, role and enrollment dates are included, and how inactive users are represented
Learner activity history	Data Hub data set for activity or usage history	CSV	The date range the data set covers, and whether it is retained long enough to meet your archive needs
Other user-level data (accounts, profiles, discussions)	Admin reports or Data Hub data sets, depending on what your plan exposes	CSV or report file	Which data sets your subscription and admin role can access, and any personal data handling terms in your contract
Learner files and submissions	Course export may omit learner-submitted files; confirm with D2L	Varies by export method	Whether dropbox submissions, assignment files and forum attachments can be retrieved in bulk

What Brightspace course packages leave out and how to recover it

A course package moves course content, but the learner side of a Brightspace course stays behind. The cards below cover the components a package usually does not carry, and the workaround for each, so nothing is lost when the contract ends. Confirm the exact list against D2L's current export documentation before you plan the work.

Learner submissions and attempts

Assignment files, quiz attempts and their timestamps generally sit with the learner record, not the course structure. A course package carries the quiz or assignment definition, but not what students submitted. Pull attempt and submission history through Data Hub CSV exports and store the files with their metadata. Check that each file can be matched back to a user ID and an activity, because the archive is only useful if someone can find a student's work later.

Grades and grade history

Final grade values are the records most often requested after a contract ends. Use the grade and enrollment Data Hub data sets to export per-learner results, and keep a copy of the grade item definitions, weights and categories so the numbers can be explained. Export after the last grade change and before access is removed, then record the export date so a later correction can be traced.

Discussion posts and activity history

Discussion threads, replies and other activity history are tied to individual users and usually stay out of a course package. Use the activity data sets in Data Hub to capture who posted what and when. Discussion text may contain personal data, so confirm who may access the archive and how long it is kept under your own policy.

Completion and enrollment records

Completion status, enrollment dates and section membership are learner facts, not course content. Export them from the enrollment data sets and keep them in a system your registrar or training records team controls. A new LMS will not reproduce past completions from the course files, so the completion record has to be archived separately and referenced when certificates or transcripts are requested.

Release conditions and calculated grades

Release conditions, prerequisites, and calculated or formula grades are logic that a course package may not carry in a form Moodle or Canvas can run unchanged. Write down each condition, its trigger and its effect in a rebuild checklist, and test each one in the target system. Treat this as manual rebuild work, not a file import, and check the course design with the instructors who wrote the rules.

Rubrics, question banks and LTI links

Rubrics, shared question banks and links to external tools often need a separate check after import. Confirm whether each item is included in the package you export, then list what did not come across. Re-register LTI tools in the new platform with their own keys and settings, and retest any quiz that depends on a question bank, because an import can keep the question text but lose its links.

Why learner records need their own archive plan

Course packages carry course content but not learner history, so the grades, enrollments and activity records your institution or business relies on must be pulled out separately as Data Hub CSV exports and stored where your records policy allows. Treat this as its own workstream with its own owner, not as a side task of the course migration. Before the contract ends, confirm with D2L which Data Hub data sets your administrator role can export, how large each export is, and whether any data set is missing or truncated, because a course package will not recover what was never exported.

Decide how long each record type must be kept before you choose a storage location. Retention periods come from your own records schedule, legal counsel and any accreditation or funder obligations, not from the LMS or this page. Once you have those periods, record which copy is the authoritative archive, where it is held, and how it will be read in future. Store the CSV files with checksums, and keep the export settings and date ranges used for each run so a later reviewer can see exactly what was captured.

Limit who can open the archive. Grade and activity files contain personal data, so restrict access to named roles, use the same identity controls you apply to other sensitive records, and log access to the storage location. Name one person who signs off that the archive is complete. That sign-off should compare row counts and key totals against Brightspace reports for a sample of courses and terms, and it should be recorded with the date, the reviewer and any gaps found. Ask your compliance or legal team to confirm the sign-off standard before the Brightspace subscription ends.

The export sequence and verification for a complete export

This sequence turns a Brightspace contract end into a verified, access-controlled archive of course packages and user-level data sets. Each step closes with evidence you can hand to the next team, so gaps are found while Brightspace is still available.

Confirm contract end date and export rights
Ask your D2L account contact in writing for the contract end date, the final access date, and which export tools and data sets your subscription and administrator role allow you to use. Your administrator must perform this step because only the customer's account holder can request it. Keep the written reply in the migration file. The step is done when you have a dated answer covering course packages, Data Hub access and any restrictions on post-term access. Ask whether the Brightspace environment will remain readable after the end date and for how long, and confirm that answer in writing.
Inventory courses, terms and owners
Your administrator lists every org unit to be exported, including course shells, sandboxes, archived terms and departmental spaces, and records the term, instructor owner and retention need for each. Sort them into keep, archive only or delete. The output is a spreadsheet with one row per org unit and a column for the export status, which you will update as the steps proceed. Flag courses that use release conditions, calculated grades or external tools, because those components will need manual rebuilding later and should be noted now.
Run course package exports
Your administrator runs course exports from Brightspace for each org unit on the inventory, choosing the Brightspace format or the Common Cartridge format as your target platform requires. Packages contain course content and structure but not learner data, so they do not replace the records taken in Data Hub. Save each package under its org unit ID and term, and note any export that fails or times out. The step is done when every row on the inventory has a package file or a documented reason for exclusion.
Run Data Hub CSV exports by data set
Your administrator runs Data Hub exports for each user-level data set you are permitted to take, such as grades, enrollments and activity history, and saves each CSV with its data set name, date range and run date. Record the filter settings used, since a different date range or org unit selection produces a different row count. The step is done when each data set has a file for each period in scope. Ask D2L which fields are included in each export so you can judge whether the archive meets your records retention requirements.
Record hashes and row counts
Generate a SHA-256 checksum for every package and CSV file and store the results in a manifest with file name, size, row count for CSVs, and the time of export. Store the manifest separately from the files. The check is complete when a second person can recompute a checksum on a copy and get the same value. Any mismatch means a file was altered or corrupted in transfer, and the file should be re-exported from Brightspace rather than repaired by hand.
Test packages in a non-production environment
Import a sample of packages into a test instance of the target platform, such as Moodle or Canvas LMS, and confirm that course structure, files, pages, quizzes and discussion settings arrive intact. Log each component that fails or needs rebuilding, including release conditions and calculated grades. Test one package from each course type you hold, not only the simplest. The step is done when the test log lists every failure, with the owning course and component, and each failure has an owner and a fix or an accepted loss.
Compare CSV row counts with the source
Reconcile each CSV's row count against the figure shown in Brightspace or a fresh Data Hub query covering the same filters, and record any difference with a reason. Spot-check a sample of grade and enrollment rows against the source for the same learners and terms. The output is a reconciliation sheet signed off by the person who owns the data. A difference that cannot be explained should stop the process until it is resolved, because a short export is the most common reason an archive fails a later audit or dispute.
Store the archive in access-controlled storage
Move packages, CSVs, the manifest and the reconciliation sheet into storage that is encrypted at rest and restricted to named roles, with access logging turned on and a retention period set by your records policy. Keep a copy of the D2L correspondence on export rights with the archive. Confirm that the restore procedure works by opening one archived package and one CSV from the storage location. The step is done when access rights have been tested and the storage owner has signed the handover record.

Checking the target platform before you import Brightspace packages

Moodle publishes major releases in April and October and point releases every two months. Moodle 5.1 is the current release line with security support until 19 April 2027, and Moodle 5.2 has security support until 4 October 2027. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next long-term support release, with security support until 1 October 2029. Confirm which release you will install before you check requirements, because each release sets its own minimums.

PHP and database versions: Moodle 5.1 requires 64-bit PHP 8.2 or later (8.3 and 8.4 are supported). Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 is supported). Check the database engine against the release notes for your target version.
Database versions: Moodle 5.1 supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later.
Upgrade path: Sites must be on Moodle 4.2.3 or later to upgrade to 5.1, and on Moodle 4.4 or later to upgrade to 5.3. Plan an intermediate upgrade if your install is older.
Document root: From Moodle 5.1, point the web server document root at the /public directory, not the main Moodle folder. Otherwise the site may show directory listings or errors.
Theme and features: Moodle 5.3 removes the Classic theme from core, so check any course or site setting that depends on it.

Confirm the exact version, PHP and database targets with your hosting or platform team and in the release notes before you build the environment.

What to plan before the Brightspace renewal or termination date

Brightspace exports are only as complete as the access and time you give yourself to take them. The cards below cover the decisions that have to be made before the contract ends, roughly in the order they block each other. Work through them early, because the export window and the target platform choice set the limits for everything after.

Export window and admin access

Confirm the end date of your subscription and who holds the administrator role in Brightspace before that date. Course packages and Data Hub exports depend on an account with the right permissions, and the people who hold it may change during a renewal or procurement cycle. Ask your D2L account contact in writing how long read access remains after termination and whether any export can be requested afterward. Do not assume the window is open-ended.

Data inventory and retention decision

List every data set you need to keep: course content, grades, enrollments, submissions, activity history and any records your policies or regulators require you to hold. Decide which of these will be archived outside the LMS, in what format and for how long. Course packages leave out learner data, so grades and activity history need their own Data Hub exports and a named owner for the archive.

Parallel-run period

Decide whether learners and instructors need the old and new platforms running side by side for a while. A parallel run lets you compare grades and course content before cutover, but it also means paying for both platforms and keeping two sets of accounts current. Set the overlap length in the written plan, and agree who signs off that the new course copies match the originals.

Target platform and hosting

Choose between self-hosted Moodle and self-hosted Canvas LMS, and decide where each runs. Moodle 5.1 and 5.3 have different PHP, database and web server requirements, and Canvas needs PostgreSQL, Redis and an SMTP server in addition to the application. Check that your hosting, database versions and upgrade path fit these requirements before you commit to a release line.

Identity and SSO cutover

Map how learners and staff sign in to Brightspace today and how that will work on the new platform. Moodle core ships LDAP, LTI, OAuth 2, Shibboleth and other authentication options, and SAML2 is available as a plugin. Plan the cutover date for accounts, the handling of duplicate or retired users and the way student identifiers carry over to the new system.

Cost of the new platform

Compare the cost of running the target platform with the renewal quote you have been offered. Your side includes hosting, database and storage, backups, administrators and support, while a renewal covers subscription and add-on modules. Ask D2L for the full renewal scope in writing, and use the sibling cost page to build the self-hosted estimate by component.

Common questions about exporting data from D2L Brightspace

Can I export my Brightspace data without help from D2L?

Most of the export can be started by your own administrators, because course packages and Data Hub data sets are available through your Brightspace account. Confirm with D2L which roles and permissions your contract grants, especially for organization-wide course exports and Data Hub access, and ask whether any export assistance is included in your agreement. Keep a written inventory of every course package and data set you export, with the date, the requester and the storage location. That inventory becomes your proof of what left the platform, and it is the first thing a migration partner or auditor will ask for.

How long does a full Brightspace export take?

The duration depends on the scope of your tenant, and no figure for D2L's export times has been published in the sources used for this page, so ask D2L for an estimate in writing. The main drivers are the number of courses and org units, the volume of embedded media and uploaded files, the number of Data Hub data sets and date ranges you need, and the time you allow for verification. Large course libraries with heavy video content usually take longer to package and check than a small set of text-based courses. Plan the export as a project with a start date, a named owner and a checkpoint for each course group, not as a single download.

What does my Brightspace administrator need to prepare?

Your administrator needs an account with export rights across the org units you are leaving, access to Data Hub for the data sets you have chosen, and enough secure storage for course packages, CSV files and any media they contain. They also need a written list of courses and data sets in scope, a decision on which learner records you must keep and for how long, and a single accountable owner who signs off the inventory. Where your institution has records or privacy officers, involve them before the first export, because learner data in CSV form often carries the same retention and access obligations as the live system.

Can Brightspace course packages be reloaded into Canvas or Moodle?

Canvas LMS can import Common Cartridge ZIP or IMSCC files through its Course Import Tool, according to Instructure's guide for importing Common Cartridge content, and it can also import Thin Common Cartridge files as module content. Moodle's course import and any Common Cartridge support depend on the version and plugins you run, so test a representative sample course on a staging instance and confirm the result against the release notes for your Moodle version. In either system, expect to check quizzes, question banks, embedded links, release conditions and grade calculations by hand, because these are the components most often lost or changed in transit.

What happens to learner history when I export courses?

Course packages leave out learner data, so grades, submissions, enrollments and activity history must come from Data Hub CSV exports instead. Those files are records in their own right, not a working gradebook, so they need a documented home outside the new LMS, with access controls and a retention period set by your institution. Confirm with your records officer which fields and time ranges must be kept, and confirm with D2L which data sets your contract includes. Learner history is the component most likely to be needed years after the cutover, so store it with clear file names, checksums and a short data dictionary.

How do I confirm that an export is complete?

Reconcile counts before you rely on any export: compare the number of courses, modules, files and quiz questions in each package with what Brightspace shows, and compare CSV row counts with enrollment and grade totals for the same period. Open a sample of packages in a test instance of your target LMS and check that content, links and media open as expected. Record a checksum for every file and keep the reconciliation sheet with the inventory. Verification is often the step that takes longest, so include it in your timeline from the beginning rather than treating it as a final check.

When should I ask D2L for export support?

Ask D2L for help when a course package fails to generate or is incomplete, when you need a Data Hub data set that your admins cannot select, or when termination dates are close and you need written confirmation of what D2L will provide and in which format. Request the answers in writing, including the file formats, the retention period for exported data after termination and any charges. If you want an independent partner to plan, run and verify the export inside your own environment, DeployOpen works under a written, fixed scope that sets deliverables and timelines before work starts. It does not issue audit reports, so any compliance evidence still comes from your auditors.

Who runs Canvas or Moodle after the migration, and who supports it?

Once you host Canvas or Moodle yourself, your team or a service provider runs the servers, databases, backups and upgrades, and that work recurs. Canvas's Production Start guide was written for Ubuntu 22.04 LTS, recommends at least 8GB of RAM and directs installation problems to the community mailing list or IRC channel rather than to Instructure support, so budget for a paid support route if you need one. Moodle 5.1 requires PHP 8.2 or later and a supported database, and its web server document root must point to the /public directory. Confirm current requirements with each project's release notes before you size the environment.

How DeployOpen scopes and delivers a Brightspace export

DeployOpen treats a Brightspace export as a fixed-scope piece of work agreed in writing before anything is touched. We plan which course packages and Data Hub datasets your organization needs, build and check the extraction in your own environment, and hand over documented, verified files that you keep.

How we scope

Inventory which courses, org units and terms must leave Brightspace before the contract ends.
Agree in writing which Common Cartridge or Brightspace packages and which Data Hub CSV datasets are in scope.
Record which learner data sets sit outside course packages and need separate archiving.
Confirm the target platform, such as self-hosted Moodle or Canvas LMS, so the export matches the import.

How we build

Run test exports of sample courses and check that quizzes, question banks and files arrive intact.
List components that do not survive packaging, such as release conditions and calculated grades, for manual rebuild.
Validate Data Hub CSV files for row counts, field definitions and date ranges against the source.
Store exports in your own infrastructure with access controls and retention settings you approve.

How we hand over

Deliver a written record of every package, dataset, extraction date and known gap.
Provide a checklist showing what was exported, what must be rebuilt and who owns each step.
Document the file layout and naming so records stay readable after the Brightspace subscription ends.
Walk your administrators through the archive and the restore steps for the target platform.

How we support

Offer ongoing support as a retainer if exports must be repeated or extended after the contract date.
Re-run extractions for courses added late or changed during the transition period.
Confirm with your team before any new dataset is requested from the Brightspace administrator.
Scope any follow-on migration work separately, with its own written agreement and deliverables.

How to export your data from D2L Brightspace