Migrate from Instructure-hosted Canvas to self-hosted Canvas LMS

Migrate from Instructure-hosted Canvas to self-hosted Canvas LMS: what the move involves

Institutions that want to keep Canvas but run the AGPLv3 code themselves usually have one of three drivers: control over where student and course data lives, a different cost profile than an Instructure subscription, or a requirement to operate the platform inside their own network. The course model carries over, so teachers keep modules, assignments, quizzes, rubrics and the gradebook. What changes is who hosts the application, who runs the database, who applies upgrades and who answers when something breaks. Those responsibilities move to the institution or to a partner. In practice the work falls to several groups. Platform engineering or IT operations builds and runs the stack described in the Canvas Production Start guide in the canvas-lms repository wiki: Ruby application servers under Passenger, PostgreSQL, Redis, background job processing, file storage and the load balancer in front of them. The LMS administrators own configuration, accounts, developer keys and LTI tool registrations. Security and compliance staff own identity integration, backups, logging and the evidence that controls are working. Many institutions bring in a partner for the first build and for upgrades, and keep a small internal team for day-to-day operations. Confirm with Instructure, through its community and the repository, which Canvas release and Ruby version your build targets before you commit to a plan. Effort and risk concentrate in three places: the first production build, the upgrade cadence and the support model. Each Canvas release has to be tested against your own integrations, SIS feed, single sign-on and LTI tools, because hosted customers no longer receive that testing for you. Ask any partner for a written scope covering build, cutover, upgrade procedure, backup and restore tests, and who is on call during term start. Ask Instructure what community support and documentation are available to self-hosters, since that is the help you will rely on.

Which Canvas capabilities move cleanly to self-hosted Canvas LMS

This table maps hosted Canvas capabilities to their self-hosted equivalents and marks each as a clean move, needs rework, or a gap. Because both run the same AGPLv3 codebase, most differences sit in hosting, institution-configured integrations and the operational services Instructure provides, so confirm feature parity against the canvas-lms repository and your own configuration before you commit.

Capability	Self-hosted Canvas LMS	Move status and note
Course content and modules	Same course, module and page tools from the canvas-lms codebase	Clean move. Confirm the version you install matches the feature set you use today.
Quizzes and question banks	Same quiz engine, configured on your instance	Needs rework. Test quiz settings, question types and any third-party quiz tools after import.
Gradebook and grading schemes	Same gradebook, with grading standards configured locally	Needs rework. Grades are not carried in course packages, so export and verify them separately.
Common Cartridge course import	Course Import Tool imports Common Cartridge ZIP or IMSCC files	Clean move for most courses. Check media links, LTI references and embedded external resources.
LTI tool integrations	Tools are registered and configured by your institution	Needs rework. Each tool needs new keys, endpoints and testing on your own domain.
SIS enrollment sync	Sync runs through your own SIS connector and configuration	Gap until configured. Your team or partner must build, test and monitor the sync.
File storage for course media	Files are stored in the object or file storage you provision	Needs rework. Size and back up storage yourself and plan for large video libraries.
Hosting, uptime and scaling	Ruby, PostgreSQL, Redis and Passenger run on your infrastructure	Gap. Instructure's hosting and capacity planning become your responsibility.
Upgrades and security patching	You apply releases and patches from the repository	Gap. Plan a recurring upgrade cycle and test each release in staging.
Vendor support and incident response	Community help, plus any support contract you arrange with a partner	Gap. Confirm who answers outages and what response terms, if any, a partner will commit to in writing.

Migration sequence from inventory to decommission

This sequence moves a Canvas deployment from Instructure's hosted service to a self-hosted Canvas LMS in controlled stages. Each step ends with a named output, so the institution can stop, fix, or go back at a known point before the hosted instance is retired.

Inventory the hosted instance and its dependencies
Start by listing what the hosted instance actually does: course count, active integrations and LTI tools, SIS and identity connections, custom themes, scheduled jobs, file storage volume, and the reports staff rely on. Ask Instructure for a written description of what the hosted service provides that you will have to replace, including backup, upgrades, and support. The Quick Start and Production Start guides in the canvas-lms repository wiki are the starting point for mapping those needs to the self-hosted stack. Output: a component inventory with an owner and a replacement decision for each item.
Build the Production Start stack in a test environment
Using the Production Start guide, build the Ruby, PostgreSQL, Redis, and Passenger stack in a non-production environment that mirrors the planned production layout. Confirm the exact Ruby and Canvas versions the guide requires before installing anything, and record them in the build notes. Your infrastructure or a partner's engineers carry out the build, and the internal team should own the configuration files. Output: a working test instance with documented build steps that a second person can repeat from scratch.
Prove backup and restore before any course moves
Configure database and file storage backups for the test instance, then restore them to a separate host and confirm that courses, users, grades, and uploaded files open correctly. Time the restore and record the steps, since this will become part of your operations runbook. Repeat the test after any change to the stack. Output: a tested backup and restore procedure with a signed record of the result from the operations owner.
Move a pilot course set and sign it off
Export a representative set of courses from hosted Canvas as Common Cartridge packages and import them into the test instance with the Course Import Tool, which accepts Common Cartridge ZIP or IMSCC files. Check the imported content, quizzes, and module structure against the originals, and reconfigure LTI tools, grade passback, and enrollments in the pilot. Faculty and support staff should review each pilot course. Grades and student records are not contained in the course packages, so they need a separate migration path. Output: a signed-off pilot with a list of known defects and their fixes.
Run hosted and self-hosted instances in parallel
Keep the hosted instance live while a limited group of courses and users works on the self-hosted instance, and track every defect, support request, and integration failure in one log. Confirm that identity, SIS sync, and LTI launches behave the same way on both systems. Decide in advance which system is authoritative for each course during this period to avoid split records. Output: a parallel-run log with defect closure status and an agreed cutover criteria list.
Write and rehearse the cutover runbook
Write a step-by-step cutover runbook covering the final course export, the last incremental data transfer, DNS and certificate changes, the freeze window for edits, rollback triggers, and who makes the go or no-go decision. Rehearse it in the test environment at least once and note where the steps took longer than expected. Your contract with Instructure should be checked for notice and data export terms before cutover is scheduled. Output: a rehearsed cutover runbook with named roles and a documented rollback path.
Cut over and monitor the new production instance
Execute the runbook, announce the switch to users, and monitor logs, job queues, integrations, and support tickets closely through the first business cycles. Keep the hosted instance available in read-only mode for the period agreed in your contract and migration plan, so staff can check historic records. Output: a production instance accepting logins and course activity, with a post-cutover issue list that is closed or assigned.
Decommission the hosted instance
Once the agreed read-only period has ended and historic data has been exported and verified, request the hosted instance be closed under your contract terms, confirm in writing that data has been deleted or returned, and retire the related SSO, LTI, and SIS connections. Update the operations runbook with ongoing upgrade, patching, and support responsibilities. Output: a written decommission record and a current operations handbook that names who maintains the self-hosted Canvas LMS.

How the Ruby, PostgreSQL, Redis and Passenger stack changes operations

Running Canvas yourself moves a set of operational duties from Instructure to your team or partner. The core stack is Ruby application servers under Passenger, a PostgreSQL database, Redis, file storage for course content and uploads, and background job processing. Each piece needs its own backup, patching and monitoring plan, and the failure of one can stop logins, grading or course delivery even when the others are healthy. Before you commit, confirm with your own platform team which of these components you already operate well, because the Production Start guide in the canvas-lms repository assumes you can manage them.

PostgreSQL is the component that carries the most risk. It holds grades, enrollments, submissions and audit history, so backups must be tested by restoring them to a separate environment, not just by confirming that backup jobs succeed. Point-in-time recovery, retention periods and the recovery time you can accept should be written down and approved by the registrar and the academic governance owner. Redis holds session and cache data and queued job state. Plan for its loss to be survivable, and confirm how the Canvas release you choose handles a Redis restart, since some queued work may need to be retried.

Passenger, the Ruby application servers and the job workers change your patch cadence. Canvas releases, Ruby runtime updates and operating system security fixes all need a staging environment that mirrors production closely enough to catch plugin and LTI breakage before users see it. File storage for course files and uploads needs its own backup and capacity monitoring, separate from the database. Monitoring should cover request latency, job queue depth, database connections and disk use, with alerts routed to people who can act at night during term start. Check the Production Start guide and the upgrade notes for each release before you set these thresholds.

Which course data moves by Common Cartridge and what needs a separate export

Common Cartridge carries course structure and material, but not the records that make a Canvas course a live teaching environment. Each card below covers one piece of the move: what the import handles, what you must export on its own, and what you rebuild by hand in the new installation.

Common Cartridge ZIP and IMSCC imports

The Course Import Tool in Canvas accepts Common Cartridge ZIP or IMSCC files, so an export from the hosted instance can bring modules, pages, assignments and files into a self-hosted course shell. Run the import in a staging installation first and compare module counts, file links and quiz content against the source course. Check that embedded links to the old hostname are rewritten, since they will break once the domain changes.

Thin Common Cartridge as module content

Thin Common Cartridge files are imported as module content rather than as full course material, which makes them useful for moving structure without every resource. Confirm with your instructional design team which packages are thin and which are full, because the import result differs. Plan a review of each imported module, since item order and prerequisites may need manual correction.

Grades and submissions need a separate export

Grades, submission history and gradebook configuration are not part of course content packages. Export them as reports from the hosted instance and store them with the registrar's retention records. Ask the vendor or your data team which grade fields the export covers, and reconcile totals for a sample of courses before decommissioning the hosted tenant.

Enrollments and SIS sync are rebuilt

Enrollments come from your student information system, not from the course package, so the SIS integration must be configured again against the new installation. Test term creation, section mapping and drop or add timing with a sample of records. Expect enrollment reconciliation to be a repeated task until the production sync runs cleanly.

LTI tool re-registration

External tools such as publishers' content, proctoring and video services are registered per installation with their own keys and endpoints. Each tool vendor must issue or accept new credentials for the self-hosted domain, and launch URLs in courses must be updated. Build a list of every registered tool from the hosted admin pages and confirm each vendor's process before cutover.

Integration configuration and secrets

Account-level settings, developer keys, branding, grading schemes and notification rules live in the installation's configuration, not in course files. Document each setting before migration, and store API keys and LTI secrets in your secrets manager instead of in configuration files. Record who approved each change so the audit trail survives the move.

How the migration differs by institution size and starting point

A single department pilot is the lowest-risk way to learn what running the AGPLv3 code involves. The scope is one or a few courses, a small group of instructors, and a test or staging environment that mirrors the production stack described in the Production Start guide in the canvas-lms repository wiki. Governance can stay inside the department, but the pilot should still record who owns the servers, who applies updates, and where course exports are stored, because those answers decide whether the pilot can grow.

Scope: Limit the pilot to a few courses exported as Common Cartridge packages, so the team tests import and rebuild steps without touching live enrollments.
Ownership: Name one person accountable for the Ruby, PostgreSQL, Redis and Passenger components, even if the work is informal.
Support: Community help is the main channel for self-hosters, so note which questions the team cannot answer internally.
Data: Keep grades and student records out of the pilot unless the data protection office has approved them.
Exit criteria: Write down what the pilot must prove before a wider move is considered.

Before the pilot starts, confirm with your Instructure account team whether any subscription terms restrict parallel use of course content.

Replacing Instructure's support with your own team or a partner

When you self-host Canvas LMS, the support relationship changes first. Instructure's hosted service comes with its own operations, upgrades and incident response, and that work moves to you once the code runs in your infrastructure. For self-hosters, the main sources of help are the community and the documentation in the canvas-lms repository wiki, including the Quick Start and Production Start guides. Those documents explain the Ruby, PostgreSQL, Redis and Passenger stack, but they do not commit anyone to a response time. Before you sign off on the move, confirm in writing who answers a production outage, who applies security patches to the Ruby runtime and the operating system, and who restores service at 2 a.m.

Each of those duties has to land on either your own staff or an outside partner under a retainer. In-house staff give you direct control and institutional knowledge, but Canvas needs people who can manage the web tier, background job workers, database upgrades and the release process at the same time, and that skill set is scarce. An outside partner brings a repeatable runbook and can be on call, but you still own the decisions about what to upgrade and when. Ask any partner which Canvas releases they have deployed, how they handle database migrations during upgrades, what their incident response times are in the contract, and how they test patches before production. Get those answers in the statement of work rather than from a sales conversation.

A practical approach is to write a responsibility matrix before cutover. List each function (monitoring, backups, patching, upgrades, on-call, security reviews, LTI tool support) and assign it to an internal role or a named vendor, with a fallback for when that person is unavailable. Treat the matrix as the input to your quote, because the cost of running Canvas depends on how much of this work you keep. Those costs are mostly recurring staff time or retainer fees, which continue after the one-time migration effort ends. Confirm your plan with Instructure's documentation and your own security team, and ask any implementation partner, DeployOpen included, to put scope, deliverables and support hours into a written statement before work starts.

What drives the cost and duration of moving to self-hosted Canvas

Moving to self-hosted Canvas LMS costs more or less depending on a handful of inputs: how much content you carry, how many systems Canvas must talk to, how far you depart from stock code, how you size the data tier, who operates the platform, and how much downtime you can accept at cutover. Each driver below is worth pinning down in writing before you ask any partner for a quote.

Course volume and attachment size

Migration effort scales with the number of courses, enrollments and files you move, not just with the number of users. Large media libraries, lecture recordings and old course attachments inflate both the export work and the file storage you must provision. Ask Instructure for an inventory of course counts, term history and total attachment size per account, and decide early which archived terms you will leave behind. Common Cartridge packages carry the content, but grades and student records need their own export.

LTI and SIS integrations

Every LTI tool, SIS feed, single sign-on connection and grade passback is a separate integration that must be re-registered, reconfigured and tested against your own Canvas instance. Vendors may need new keys or new endpoints, and each one adds test cycles. Build a register of every integration with its owner, data flow and whether the vendor supports a self-hosted Canvas. Integrations you cannot re-establish often decide the timeline more than the course content does.

Customizations and theme changes

Each change to the stock Canvas code, theme, branding or custom Ruby plugin becomes code you maintain through every upgrade. Customizations also need regression testing against new Canvas releases. Separate changes you truly need from preferences, and record each one as a patch or plugin with an owner. Fewer local changes make upgrades cheaper and reduce the support burden you take on from Instructure's community.

Database and storage sizing

Canvas runs on Ruby, PostgreSQL, Redis and Passenger, and each tier has its own capacity limits. Database size tracks enrollments, submissions and grade history, while file storage tracks attachments and media. Ask your architect to size PostgreSQL, Redis, file storage and backups separately, and to model peak load during grading deadlines and enrollment periods. Undersized tiers become the most expensive surprise after cutover.

Staffing model and support

Your choice of operator drives recurring cost more than any single setup task. An internal team needs Ruby, Rails, PostgreSQL and Linux skills available around the clock during term start, while a partner charges for a defined scope under retainer. Hosted Instructure support is replaced by community help and your own or a partner's on-call coverage. Ask each bidder for named roles, response expectations and how upgrades and security patches are handled.

Cutover window and parallel running

The cutover window determines how long courses can be unavailable and how long you must run Instructure and self-hosted Canvas side by side. Avoid cutover during enrollment, add-drop periods or final grading. Plan a freeze on course edits, a final delta export and a rollback path. Agree the acceptable downtime and the freeze calendar with academic leadership before scoping any work.

Questions buyers ask before moving Canvas in-house

Can we run self-hosted Canvas LMS without an implementation partner?

Yes, it is possible for an institution with the right engineering skills, because the canvas-lms code is public and the repository wiki includes Quick Start and Production Start guides for self-hosted installs. The harder question is whether your team can own the whole stack over time. Confirm three things before deciding: whether you have engineers comfortable with Ruby on Rails, PostgreSQL, Redis and Passenger; whether you have on-call coverage for a learning platform used during exams and enrollment periods; and whether you have a support path once Instructure's hosted support no longer applies. Many institutions split the work, keeping day-to-day operations in-house and buying scoped help for installation, hardening and upgrades.

What skills and staff time does a self-hosted Canvas deployment need?

Plan for four skill areas: application operations for the Ruby and Passenger services, database administration for PostgreSQL backups and performance, cache and job infrastructure for Redis, and web and identity integration for SSO, LTI tools and SIS feeds. Staff also need release management, because each Canvas upgrade must be tested against your own integrations and customizations before it reaches students. Ask your team to estimate hours per month for these areas in its own environment, since staffing depends on your user count, uptime targets and existing tooling. Treat this as a current-state assessment rather than a fixed number.

What costs are one-time and what recurs after cutover?

One-time costs include the migration project, course content transfer, LTI tool re-registration, SSO and SIS integration, testing and staff training. Recurring costs include the infrastructure that hosts the application, database, Redis, file storage for course media, backups, monitoring, security patching, Canvas upgrades and the people or partner hours that run them. Subscription fees to Instructure end, but that saving is offset by these operating costs. Ask any partner for a quote that separates the one-time migration from a recurring support retainer, and asks for the assumptions behind storage growth and upgrade frequency.

How are grades and student records protected during the move?

Course packages do not carry complete grade history or student records, so these must be exported and migrated separately before you cut over. Plan a reconciliation step that compares gradebook totals, enrollments and submission counts between the hosted and self-hosted instances. Restrict access to the export files, encrypt them in transit and at rest, and delete working copies when the migration closes. Your security team should also define who approves access to the production database, how backups are tested by restore, and how audit logs are retained. Confirm these controls against your institution's policies and applicable regulations with your own compliance and legal staff.

Does the AGPLv3 license require us to publish changes we make to Canvas?

The AGPLv3 license requires that if you modify Canvas and make the modified version available to users over a network, you must offer those users the corresponding source code of your modifications. Simply running the unmodified code for your own students does not trigger that obligation, but customizations such as a branded theme, a custom plugin or a patched module can. Ask legal counsel to review your planned changes and how you will publish them, and keep customizations in separate, documented plugins where possible so upgrades stay manageable. This is a licensing question for your counsel, not a conclusion this page can settle.

What should we ask a partner for a fixed-scope quote?

Ask for a written scope that lists the environments to be built, the Canvas version to be installed, the integrations (SSO, SIS, LTI tools, storage and email), the migration method for courses and the data migration method for grades and records, the testing and cutover plan, and the handover documents. Also ask what is excluded, such as ongoing upgrades, after-hours support or content rebuilding. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside a client's own infrastructure, and most engagements are fixed-scope, agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope.

What happens to support when we leave Instructure-hosted Canvas?

Instructure's hosted service includes vendor support, which ends when you run the software yourself. For self-hosters, the community resources are the main public channel, alongside the project documentation and repository. Decide before cutover who answers incidents, who applies security patches, and who handles the upgrade cycle. This can be an internal team, a partner under a retainer, or a mix of both. Confirm the response expectations you need with any partner in writing, and confirm what official Instructure support, if any, remains available for a self-hosted deployment.

What usually goes wrong in a Canvas self-hosting move

The most common failure is an incomplete data picture at cutover. Common Cartridge packages carry course content, but grades, enrollments, submissions, conversations and file attachments sit outside those packages, so a move that relies only on course exports will leave gaps in the gradebook and the student record. Before anyone schedules a cutover, the team should list every data class it must keep, name the export or database extraction that covers each one, and confirm with its records office which classes it is legally required to retain. Treat that list as the acceptance checklist for the migration, not as a planning note.

The second failure is a restore that has never been tested. Teams often rehearse the import of course packages but never restore a full PostgreSQL database, the Redis state and the uploaded files from the same point in time into a separate environment. Mismatched backups between the database and the file store produce broken attachments and missing submissions that only appear weeks later. Run a complete restore into a staging instance, log in as an instructor and a student, open graded assignments and confirm that files download. Record how long the restore took, because that figure is the one your recovery plan depends on.

Integrations and upgrades cause the slowest problems. LTI tools, SIS feeds, single sign-on and external grade passback can fail quietly after cutover, and a tool may appear to work while it writes to the wrong course or drops grades. On the upgrade side, self-hosted Canvas moves with the vendor's release cadence, so the Ruby, PostgreSQL, Redis and Passenger versions must be tested against each release, not applied once at installation. Ask who owns support for the community-only path, who holds the staging environment that catches regressions, and who is paid to fix a broken release at the start of term. Those answers belong in a signed scope with your own staff or a partner, before the hosted subscription ends.

How to prevent the most common cutover failures

Moving from Instructure-hosted Canvas to a self-hosted install fails most often at the data, integration and operations seams, not in the application itself. Each card below pairs one common failure with a control you can verify before students depend on the new system.

Rehearse the database restore

A self-hosted Canvas instance is only as recoverable as its PostgreSQL backups. Restore a full copy of the production database and file storage into a separate environment, then confirm that courses, enrollments, submissions and attachments open correctly. Time the restore so the cutover window is based on a measured run, not an estimate. Ask your partner to document who runs the restore, from which backup set, and how Redis state is handled, since it is not a durable record store.

Run a parallel gradebook reconciliation

Grades and submissions do not transfer reliably through Common Cartridge packages, so they need their own check. Run the new instance alongside Instructure-hosted Canvas for a defined period and reconcile grade totals, late policies and grading schemes course by course. Any mismatch becomes a blocker for that course. Keep the hosted export as the reference record until the registrar signs off on the reconciliation.

Inventory every LTI and SIS integration

Hosted Canvas often connects to a student information system, identity provider, publisher tools and proctoring services through LTI keys, endpoints and API tokens that live in admin settings rather than in code. Build a written inventory of each integration, its owner, its credentials and the DNS or certificate it depends on. Test each one in the staging instance with a sample course before cutover, and confirm which vendors must re-register the new domain.

Define a rollback path before cutover

A cutover plan without a rollback decision point leaves staff improvising during a failed launch. Set the conditions that trigger rollback, such as failed login tests, missing enrollments or broken gradebook totals, and name who makes that call. Keep the hosted tenant active and read-only until the agreed acceptance period ends. Confirm in writing with Instructure how long your subscription remains available during that window.

Assign upgrade and support ownership

Instructure-hosted Canvas includes vendor-run upgrades and support, while self-hosted Canvas moves those duties to your team or a partner. Before cutover, write down who applies releases, who handles Ruby, Passenger and PostgreSQL security patches, and who answers a Monday-morning outage. Compare that list against the support channels available to self-hosters, including the community support Instructure offers, and document any gap as a named risk with an owner.

How DeployOpen scopes, runs and supports a self-hosted Canvas migration

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Instructure-hosted Canvas to self-hosted Canvas LMS, we start from a written scope that names the Canvas release, the Ruby, PostgreSQL, Redis and Passenger stack, the course migration path and the support model you will run afterward.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which courses, term data, file storage and integrations move, and which stay on Instructure-hosted Canvas during cutover.
We confirm with you which Canvas release your institution will run and the Instructure license terms that apply to your use.

How we build

We deploy the Canvas code from the repository wiki's Production Start guide into your environment, with the Ruby, PostgreSQL, Redis and Passenger stack documented.
We test Common Cartridge imports from representative course exports, checking module structure, files, links and quizzes against the source.
We configure backups, access controls and logging, and we prepare evidence that supports your internal security and compliance reviews.

How we hand over

You receive architecture, runbooks, backup and restore procedures, and the migration record for each course batch.
Your staff are trained on administration, upgrades and troubleshooting against the systems we built, with the steps written down.
Grades, enrollments and learner records are exported and reconciled as a separate workstream, with the reconciliation report delivered to you.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover patching the Canvas release, database maintenance and restore tests on a schedule you agree.
Before you commit, ask us to confirm in writing which support tasks sit in scope and which remain with your own staff or Instructure.