Migrate from D2L Brightspace to self-hosted Canvas LMS

How a Brightspace to self-hosted Canvas migration is structured

If your Brightspace renewal, data residency rules or lock-in concerns are pushing you toward your own servers, plan the move as a staged project covering course content, assessments and integrations, running on infrastructure your organization controls. Nothing about it is a single cutover. The work splits into content transfer, assessment checks, learner records and LTI re-registration, and each stage can be tested before the next one depends on it. The project is usually led by the institution's learning technology team, often with an implementation partner for installation, integration and testing. Canvas LMS is released under the AGPLv3 license, so there is no license fee for the code, but self-hosting means your organization owns the installation, the database, backups and upgrades. Ask any partner to show the scope of each of those in writing, including who applies security patches and who restores from backup when something fails.

Effort depends mainly on how much content you have, how many quizzes and question banks need manual checking, and how many LTI tools must be re-registered against the new platform. Your Canvas hosting setup, whether a server you run or a partner-run environment, also shapes the work. The Canvas Production Start guide, which was written and tested on Ubuntu 22.04 LTS, lists the services a production install needs, including PostgreSQL, Redis and an outgoing SMTP server, so confirm that your team or partner has the skills to run each one. Ask for a quote built from a written inventory of your Brightspace courses, assessments and integrations rather than a flat estimate, and confirm the dates and milestones before work starts.

Which Brightspace capabilities map to Canvas and which need rework

This table maps common Brightspace capabilities to their closest self-hosted Canvas LMS equivalent and marks each as clean, needs rework or gap. Treat the marks as a planning starting point, then test each row against a sample course export from your own Brightspace instance. Hosted-service features that go beyond the AGPL code must be confirmed with Instructure separately.

Brightspace capability	Canvas LMS equivalent	Status and what to check
Course content and modules	Modules and pages imported through the Course Import Tool	Needs rework: Common Cartridge content usually arrives as module content, so confirm module order, links and embedded files after import
Quizzes and question banks	Canvas quizzes and question banks	Needs rework: question types, feedback, random pools and time limits must be checked question by question after import
Gradebook and grading schemes	Canvas gradebook and grading schemes	Needs rework: weighting, drop rules and calculated grades must be rebuilt and compared against Brightspace totals
Rubrics	Canvas rubrics attached to assignments	Needs rework: confirm that rubric criteria and points map cleanly on a test course before bulk import
Discussions	Canvas discussion topics	Clean for basic threads; confirm grading settings, groups and posted content in a test import
Announcements	Canvas announcements	Confirm that dates and visibility settings carry over; Common Cartridge coverage should be tested
Groups and sections	Canvas groups and sections	Gap to plan: group membership and section enrollments are usually recreated from your SIS or roster data, not from course packages
Release conditions	Canvas module prerequisites and conditional release	Needs rework: rebuild conditions manually and test each path with a student test account
LTI tools	LTI 1.3 tools registered in Canvas	Needs rework: every tool must be re-registered with new keys, deployment IDs and endpoints; confirm vendor support for your Canvas version
SSO and identity	Canvas authentication and your identity provider	Gap to plan: Canvas SSO configuration is independent of Brightspace and must be set up and tested before cutover
Analytics and learner history	Canvas analytics and gradebook history	Gap: course packages do not carry learner records; archive history separately and confirm which Canvas reports you need
Hosted service extras	Instructure hosted features beyond the AGPL code	Confirm separately with Instructure; the AGPL code alone may not include every feature you use in Brightspace

What data and integrations move, and through which export paths

Brightspace data does not move as one bundle. Course content, learner history, identities and LTI tool connections each take a different path into a self-hosted Canvas LMS, and each path has its own checks. Confirm the exact export route with your Brightspace administrator before you plan the cutover.

Course content through Common Cartridge

Course materials are the part most likely to move through a standard package. Canvas's Course Import Tool accepts Common Cartridge ZIP or IMSCC files, and it can also import Thin Common Cartridge files as module content. The Canvas import guides cover Common Cartridge and Blackboard exports, not Brightspace exports directly, so ask your Brightspace administrator which Common Cartridge version the export produces and test one course before committing to the full set. Expect assignments, quizzes and discussions to need manual review after import.

Quizzes and question banks

Question banks and quiz settings are where imports most often lose detail. Some question types, feedback, random question pools and availability dates may not carry over in the form they had in Brightspace. Build a checklist from a sample quiz in each question type you use, and compare scores and settings in Canvas against the source. Plan for a second pass on high-stakes assessments before any learner sees them.

Grade and learner history archived outside the LMS

Course packages generally leave out learner data, so completions, grades, attempts and activity history need a separate export. Take them from the Data Hub CSV exports and store them in an archive your records policy covers, such as an encrypted file store or a read-only database. Confirm the retention period, access rights and who may query the archive. Canvas will not hold historical grades unless you enter them there, which is a decision for your registrar or training owner.

User identities and SIS feeds

Learner and staff accounts, enrollments and section mappings have to be recreated in Canvas before courses are usable. Decide whether Canvas will authenticate through your identity provider or local accounts, and whether a student information system feed will provide enrollments. Test with a small set of users, confirm that login identifiers match what your SIS sends, and check that former students and leavers are removed on schedule.

LTI tools that need re-registration

Each LTI tool connected to Brightspace must be registered again against the new Canvas instance, with its own key, secret or developer credentials and its own deployment settings. Make an inventory of every external tool, including publisher content, plagiarism checkers and video platforms, and record which vendors must issue new credentials. Test a launch, grade passback and deep link for each tool before cutover, since a tool that opens but returns no grades is still broken.

The migration sequence from inventory to decommission

This sequence moves Brightspace courses, assessments and integrations onto a self-hosted Canvas LMS in controlled stages, so each step produces a checked result before the next begins. It ends with a decommissioned Brightspace tenant and learner records held in an archive you control.

Inventory courses, quizzes, integrations and retention needs
Start by listing every active and archived course, its owners, the quiz banks and question libraries it depends on, the LTI tools and SIS or SSO connections attached to it, and the retention period your records policy requires for grades and learner activity. Learning designers and the LMS administrator should own this list together, with registrar or compliance input on retention. The step is done when each course has a named owner, a disposition (migrate, archive or retire) and a list of external tools that must be re-registered. Ask Instructure's documentation and your own records team which learner data sets must be kept outside the LMS.
Run a pilot import with quiz checking
Export a representative set of courses from Brightspace as course packages in Common Cartridge format, then import them with Canvas's Course Import Tool, which accepts Common Cartridge ZIP or IMSCC files. Choose courses that cover different content types, such as modules with files, embedded media, discussions and quizzes with varied question types. Check each imported quiz and question bank against the original, since question types, feedback, and settings can behave differently after import. The pilot is complete when a course designer has signed off on every item type in the sample and the defects are logged with a fix or workaround.
Build the Canvas environment from the Production Start components
Provision the production servers following the Canvas Production Start guide, which was written and tested on Ubuntu 22.04 LTS. The stack includes PostgreSQL 14 or later, Redis 6.x or above for caching and OAuth2, Apache with Passenger, a background daemon for automated jobs and an outgoing SMTP server. The guide recommends at least 8GB of RAM. Your infrastructure team should confirm the Ruby version against the release you deploy, since the guide lists Ruby 3.4.1 as the recommended minimum for the 2025-07-02 release. The step is done when the staging instance serves a test course, sends a notification email and runs a scheduled job without errors.
Re-register LTI tools and connect identity
Register each LTI tool that the courses rely on against the new Canvas instance, using the developer keys and configuration each vendor provides, and connect your single sign-on and any SIS feed. Test launches from a sample course for every tool, including grade passback where it is used. The step is done when each tool launches for a test learner and a test instructor and any grade return path has been verified end to end.
Operate a parallel run with a defined cutover window
Run Brightspace and Canvas side by side for a defined period. New course builds happen in Canvas for the migrated set, while Brightspace stays read-only for courses in active use. Agree the cutover window in advance with academic and training leads, and freeze Brightspace edits for migrated courses before the final import pass. Re-run the import for any course that changed during the parallel run and compare gradebooks and enrollments against the source export. The step is done when the sign-off checklist for each course is complete and the cutover window has been executed as written.
Archive learner records outside the LMS
Export learner history, including grades, enrollments and activity records, from Brightspace's Data Hub as CSV data sets, because Common Cartridge packages do not carry learner data. Store these files on storage you control, with access restricted to the roles your policy names, and index them by course and term so that a records request can be answered without restoring the LMS. Confirm the retention schedule with your records team before the export. The step is done when the archive has been checked by sampling records against Brightspace and the retention owner has accepted it.
Decommission Brightspace and close the migration
Once learner records are archived and the parallel run has closed, disable Brightspace enrollments and logins, remove its LTI registrations and SSO connections, and confirm that no integration still points to the old tenant. Record the decommission date, the archive location and the owner of each retained data set in the change log. Keep the Brightspace contract terms and the archive access process in the same register. The step is done when the old tenant is no longer used, every integration has been repointed, and the retention owner confirms the archive is the record of truth.

How the migration changes by institution size and starting point

A small training team with a modest number of courses usually has the simplest path. The main question is whether the Brightspace content is worth carrying across at all, or whether a handful of current courses should be rebuilt directly in Canvas. Common Cartridge exports from Brightspace can be loaded through the Course Import Tool, which accepts Common Cartridge ZIP or IMSCC files, so the content transfer itself is usually the quick part. The rework comes from checking what the import brings across.

Import a pilot course first: Load one representative course and review every module, page, file link and quiz before importing the rest.
Check quizzes and question banks: Confirm that question types, feedback and point values survived, and that any question libraries were rebuilt correctly.
Decide where learner history goes: Completion and score history usually stays outside the LMS, so plan the archive before cutover.
Re-register any LTI tools: Each external tool needs a new registration in Canvas, even when the tool itself is familiar.
Keep the installation small: A single server with the documented database, Redis and mail services is often enough for a small user base, but confirm sizing with the Production Start guide and your load.

Before you commit, check the import on one course against the original and confirm that someone on the team can run the Canvas server after go-live.

What drives the cost and duration of the Canvas migration

This table lists the factors that move the cost and schedule of a Brightspace to self-hosted Canvas move, with how each one changes effort and what to ask for in a fixed-scope quote. Read it as a checklist to size your own inventory before requesting a written scope.

Driver	Why it moves cost or effort	How to keep it down and what to ask for
Course count and complexity	Each course needs an export, an import into Canvas and a review of modules, pages, assignments and file links. Courses built with heavy custom HTML or embedded media take longer to check.	Retire inactive courses before export. Ask the quote to state the course count, the sample size reviewed and how many course types are treated as templates.
Quizzes and question banks	Common Cartridge exports carry quiz and question content, but question types, feedback, randomization and point values need manual checks. Question banks can be large and uneven.	Count quizzes by type and check a sample of each. Ask for a stated test plan covering quiz settings, scoring and question bank import results.
LTI tools to re-register	Each external tool needs a new Canvas developer key or registration, launch URLs, data-sharing settings and course placement. Tools that reference Brightspace identifiers need reconfiguration.	List every LTI tool with its vendor and data flow. Ask the quote to price tool registration and testing as separate line items so that tools can be dropped or deferred.
Learner history and records	Completion history, grades and attempts do not move through a course package. Archiving them from Brightspace Data Hub is a separate workstream, and the archive format and retention rules affect the work.	Decide which records are archived, which are imported and which stay read-only. Ask for the export format, retention location and access controls in writing.
Identity and SIS integration	Single sign-on, enrollment feeds from a student information system and role mapping must be rebuilt for Canvas. Errors here affect every user, so cutover testing takes longer than the import itself.	Document current identity providers, enrollment sources and sync frequency. Ask the quote to include a named integration test and a rollback plan for enrollment feeds.
Internal Canvas and Linux skills	A production Canvas install uses Apache with Passenger, a background job daemon, PostgreSQL, Redis and SMTP. Staff without this experience need more support hours, and the Production Start guide directs installation problems to the community mailing list or IRC rather than Instructure support.	Assess the team's Linux, Ruby, PostgreSQL and Canvas administration skills early. Ask whether the quote includes knowledge transfer, runbooks and a support window after go-live.
Hosting capacity	The Production Start guide recommends at least 8GB of RAM, and PostgreSQL 14 or later and Redis 6.x or above are required. Larger course volumes and concurrent users raise the sizing and the monitoring effort.	Confirm the target server specification against the current guide and expected peak use. Ask the quote to state the environments (test, staging, production), backup approach and who patches each component.
Testing depth	Testing ranges from a spot check of courses to full quiz, grade and integration testing with sign-off from faculty and administrators. Deeper testing adds time but reduces post-cutover support.	Agree on acceptance criteria before work starts, including sample courses, grade passback checks and LTI launch tests. Ask for the test scope and sign-off steps in the written scope.

What usually goes wrong in a Brightspace to Canvas move

Most failed Brightspace to Canvas moves are not caused by the import itself. They come from assumptions about what the import carries, how tools reconnect, and how much work the self-hosted stack creates. Each card below names one risk and the check that prevents it.

Quizzes and question banks change

Quiz questions, answer keys, point values and question banks can import with altered formatting, lost images or changed scoring. Question types that Brightspace handles differently may arrive as a close approximation rather than an exact copy. Before cutover, import a sample course, open every quiz type you use, compare points and correct answers against the Brightspace original, and re-run one graded attempt end to end.

Grade history does not travel with courses

Course packages carry content, not learner records. Past grades, submission history, attempts and completion dates stay behind in Brightspace unless you export them separately. Decide which records must remain available for audit or appeals, export them from the Data Hub as user-level CSV files, and store them in a system you control before the contract ends.

LTI tools fail on re-registration

Each external tool in Brightspace has its own registration, keys and launch URLs. In Canvas, every tool must be registered again in the self-hosted instance, and the vendor may need new client credentials or a changed redirect address. Build an inventory of every LTI tool, record who owns each vendor relationship, and test a launch, grade passback and deep link for each one in a staging instance.

Underestimating the server stack

A production Canvas install is more than the application. It needs PostgreSQL, Redis, Apache with Passenger, a background job daemon and an outgoing SMTP server, and the production guide recommends at least 8GB of RAM. Someone must patch the operating system, back up the database, rotate certificates and watch job queues every day. Ask who owns each component, what the on-call expectation is, and what the staffing cost looks like before committing.

Installation problems go to community channels

The Production Start guide directs administrators with installation problems to the community mailing list or IRC channel rather than to Instructure support. Hosted Canvas customers have a vendor support path. Self-hosters do not, unless they buy one from a partner or consultant. Agree in writing who will fix a failed upgrade or a broken job queue, and rehearse a rollback before the first live term.

Questions buyers ask before moving from Brightspace to Canvas

What does a move from Brightspace to self-hosted Canvas cost, and what drives it?

The cost has three main parts: infrastructure you run, people who install and operate the platform, and migration work on courses, quizzes and integrations. Canvas is AGPLv3 licensed, so there is no license fee for the code, but you pay for servers, a PostgreSQL database, Redis, email delivery and backups. The Canvas Production Start guide recommends at least 8GB of RAM for a server, and it lists Apache with Passenger, a background job daemon and an SMTP server as parts of a production install. Recurring costs include hosting, staff time for upgrades and patching, and support. One-time costs include setup, course migration and retesting. Ask any quote to split these lines, to state which Canvas release it targets, and to list who performs each task.

How long does a Brightspace to Canvas migration take?

The duration depends on how many courses you move, how much of each course uses quizzes, question banks, release conditions and third-party tools, and how much learner history you must archive. No supplied source gives a fixed duration, so treat any timeline as unconfirmed until the scope is written down. Content that exports cleanly as Common Cartridge packages can be imported through Canvas's Course Import Tool, but quizzes and question libraries need manual checking after import. Plan for a pilot with a small set of representative courses, then a staged cutover. Ask a partner to state the courses in scope, the checks for each course type and the acceptance criteria before work begins.

What must our institution provide before the migration starts?

You need named decisions and people, not only budget. Decision-makers must confirm which courses, terms and learner records move, and which are retired. Your team must provide a Brightspace export, access to Data Hub user-level exports, a list of LTI tools and their owners, and the SSO and SIS details needed for the cutover. You also need an operations owner for the Canvas servers, someone who can approve the database and storage design, and faculty or trainers who will check their courses after import. Confirm with your Instructure or hosting contacts which Canvas release you will use, since the Production Start guide has changed with releases.

Can our own team run this migration without outside help?

Yes, if you have people who can operate Linux servers, PostgreSQL, Redis and a Rails application, and who can test course content. The Canvas Production Start guide was written and tested on Ubuntu 22.04 LTS and directs installation problems to the community mailing list or IRC channel rather than to Instructure support, so your team should expect to resolve issues through the community or a paid partner. Outside help is most useful for scoping, LTI re-registration, course validation and cutover testing. Ask any provider to state which tasks it performs, which remain with your staff, and how it hands over runbooks.

How are learner records and completion history kept after the move?

Course content and learner records are different things, and they need separate handling. Common Cartridge exports carry course materials, not the full learner history, so grades, enrollments and activity logs must be exported separately, typically from Brightspace Data Hub as CSV files. Store that archive on your own servers with a documented retention period and access controls. Decide whether historical grades will be imported into Canvas or kept in the archive for reference, and confirm with your registrar or records office what the institution must keep and for how long. Ask the team to demonstrate that archived records can be found and read before Brightspace is closed.

Does the AGPL Canvas code include the same features as Instructure's hosted service?

Not necessarily. The canvas-lms repository publishes the code under AGPLv3, but Instructure's hosted service may include operations, integrations, support and features that the open-source code does not cover. Confirm the exact feature set you need, including LTI tools, analytics, accessibility features, mobile apps and any Instructure-managed add-ons, by checking the release you plan to run against your requirements list. Run each required feature in a test environment before committing. Ask Instructure directly which hosted capabilities are not available in the self-hosted build.

What should we check in our LTI tools and quizzes after import?

Start by listing every LTI tool used in Brightspace, then re-register each one in Canvas with its new client settings, launch URLs and keys, because registrations do not move with course packages. For quizzes and question libraries, compare question counts, scoring, feedback and randomization for a sample of courses per department, since these components need checking after import. Test release conditions and any calculated grades, and confirm that accessibility remediations survived the export. Keep a test script per course type so reviewers repeat the same checks for every course.

What DeployOpen takes on in a Canvas migration

DeployOpen plans and runs the move from Brightspace to self-hosted Canvas LMS inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The work is usually agreed as a fixed-scope engagement with a written scope, deliverables and timelines set before anything starts. In that scope, the team typically covers the Canvas install itself (the Production Start guide calls for Ubuntu 22.04 LTS, PostgreSQL 14 or later, Redis, Apache with Passenger, a background jobs daemon and an outgoing SMTP server), the Common Cartridge import runs, the question bank review, the learner history export and the LTI re-registration. Confirm the exact Canvas release and Ruby version with the release tags in the repository at the time you sign, since the guide's version requirements move between releases.

The decisions that matter most belong to you, and they should be written into the scope early. Name who signs off on the content cutover, which courses are archived rather than imported, where Brightspace learner records will be stored and who may read them, and which LTI tools are essential on day one. DeployOpen can build the import checklists, run test imports against a staging instance and document each step, but the academic and records decisions remain with your faculty, registrar and data owners. Ask any partner to put in writing which of these tasks they perform, which they only advise on, and which stay with your staff.

Where your organization must demonstrate controls, DeployOpen prepares the systems, configuration baselines and evidence that an assessor will ask for, such as access records, change logs and backup test results. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, so ask your assessor early which evidence they expect from the new platform. DeployOpen does not hold a partner or reseller relationship with Instructure or D2L, and any proposal should be judged on its written scope and your own environment. Ongoing upgrades and support after cutover can be handled under a separate retainer if you want them.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Brightspace to self-hosted Canvas LMS, we start with a written scope that separates course content, quizzes, learner history and LTI tools so each one has a clear owner and a clear test.

How we scope

We inventory courses, Common Cartridge exports, question banks, LTI tools and SSO links before agreeing any work.
The written scope names which course content moves into Canvas and which records are archived outside the LMS.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We install Canvas LMS on your infrastructure following the project's Production Start guide, including PostgreSQL, Redis, Passenger, background jobs and SMTP.
We import Common Cartridge packages through the Course Import Tool, then check modules, links, quizzes and question libraries course by course.
We re-register each LTI tool in the new instance and test launches, grade passback and single sign-on with your staff and learners.

How we hand over

You receive a documented migration log listing every course, what imported cleanly and what was rebuilt by hand.
Learner history exported from Brightspace is archived in a location you control, with access rules documented.
Your administrators get runbooks for backups, upgrades, plugin checks and LTI configuration, so they can operate the instance.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after cutover.
A retainer can cover Canvas release upgrades, database and storage checks and re-testing of LTI tools after changes.
Before you sign, ask us to confirm the support hours, response terms and upgrade approach in the written scope.