Which open-source alternative to Canvas fits your situation
If you are facing a Canvas renewal, a data residency requirement or pressure from licensing terms, the closest like-for-like option is self-hosted Canvas LMS, because its source code is available under the AGPLv3 license. Moodle is the broadest general-purpose option, with a large plugin ecosystem and wide use across universities, schools and companies. Open edX fits course-led catalogs where authoring and publishing structured courses is the main job. Canvas itself is maintained by Instructure, so self-hosting keeps the code familiar to your staff, but it does not give you the features and services that Instructure runs in its own hosted environment.
Teams look at alternatives for a few concrete reasons. The canvas-lms repository publishes the source under AGPLv3 and includes Quick Start and Production Start guides in its wiki for self-hosted installs, which lets you test a deployment before committing. Moodle is distributed under GPLv3, and Open edX has no licensing fees and is stewarded by Axim Collaborative, a nonprofit founded by Harvard and MIT. Confirm that the features you rely on, such as hosted support, analytics, mobile features and some add-ons, exist in the open-source code and are not limited to Instructure's hosted service before you plan around them.
Before you compare costs, check your Instructure contract for the terms that actually drive your spend: the subscription basis, add-on modules, support tiers, data retention and exit or transition clauses. Ask your account team to list which modules and integrations are included and which are billed separately. Those answers decide whether a self-hosted Canvas, Moodle or Open edX deployment changes your total cost of ownership, and they determine how much course content and history you need to move out of the hosted service.
Self-hosted Canvas, Moodle and Open edX compared
Each option below can run on infrastructure you control, but they differ in how close they stay to Canvas, how much they lean on a plugin ecosystem, and who maintains the code. Compare them against your course catalog, your integration needs and the staff you can commit to operating the platform.
Self-hosted Canvas LMS
Canvas LMS is created and maintained by Instructure and released under the AGPLv3 license, so the interface your instructors and learners already know can run in your own cloud account or data center. The repository wiki includes Quick Start and Production Start guides for self-hosted installs. The trade-off is that the open-source code does not include every feature Instructure delivers in its hosted service, so you must map each hosted feature you rely on to the code before you commit. Confirm that list with Instructure in writing.
Moodle
Moodle is free and open-source software under the GNU General Public License version 3 and is used by universities, schools and companies. Its large plugin ecosystem covers many gaps, including reporting, SCORM handling and LTI connections, but each plugin adds its own upgrade and security review work. The trade-off is that you own the choice of plugins and the testing that comes with every Moodle upgrade. Ask whether the plugins you need are actively maintained and tested against the Moodle version you plan to run.
Open edX
Open edX is stewarded by Axim Collaborative, a nonprofit founded by Harvard and MIT, and has no licensing fees. The platform includes Open edX Studio for course authoring and can be self-hosted or run through managed Open edX providers. The platform code is licensed under AGPLv3, which requires you to share modifications when you offer the software to users over a network. The trade-off is a course model and authoring workflow that differs from Canvas, so expect instructor retraining and content rebuilding.
Which open-source option covers each Canvas capability
This table maps core Canvas capabilities to self-hosted Canvas LMS, Moodle and Open edX, marked covered, partial or confirm-with-vendor. Features delivered only through Instructure's hosted service or add-ons are not in the open-source code, so each one must be verified in your own environment before you commit. Treat any cell that says confirm as an open question for your evaluation.
| Capability | Canvas LMS (self-hosted) | Moodle | Open edX |
|---|---|---|---|
| Course authoring | Covered in the open-source code. Confirm editor parity with the hosted release you use. | Covered. Course content and activities are built in. | Covered through Open edX Studio, which is separate from the learner-facing LMS. |
| Assignments and gradebook | Covered in the code. Confirm grading features against release notes. | Covered through core assignment and gradebook modules. | Partial. Confirm assignment types and grade workflows against your needs. |
| Quizzes | Covered for common question types. Confirm advanced item types. | Covered through the quiz module and question bank. | Covered through problem types in Studio. Confirm item types and scoring. |
| LTI tool integration | Covered through LTI support. Confirm the LTI version each tool requires. | Covered through LTI support. Confirm the version and tool certifications you need. | Partial. Confirm LTI support and each external provider you depend on. |
| SIS and enrollment sync | Confirm. SIS import exists in the code, but ongoing sync with your SIS needs its own integration. | Partial. Enrollment plugins and external sync exist. Confirm a connector for your SIS. | Confirm. Enrollment and SIS integration is usually built for each deployment. |
| Mobile apps | Confirm. Instructure's app distribution is not established by the code alone. | Covered through the Moodle mobile app. Confirm branding and store publishing for your organization. | Confirm mobile app availability for your release. |
| Analytics | Partial. Confirm which reports ship in the code and which are Instructure-hosted. | Partial. Core reports exist, and additional reporting comes from plugins. Confirm each. | Partial. Confirm learner analytics and xAPI export needs. |
| Accessibility tooling | Confirm with your own audit against your WCAG target. Request the vendor's conformance statement. | Confirm with your own audit. Request the community conformance documentation for your version. | Confirm with your own audit. Request the platform's accessibility documentation for your release. |
| Hosted support | Confirm. Instructure-hosted support is not in the open-source code. Ask a provider for scope. | Confirm. Community support is open, and paid support comes from partners. Verify scope in writing. | Confirm. Managed Open edX providers are available. Verify scope and response terms in writing. |
Which Canvas alternative fits each situation
When student or staff records must stay in a specific country, region or on-premises data center, the question shifts from which product to which hosting boundary. Self-hosted Canvas LMS is the closest match to Canvas itself, because its source code is released under the AGPLv3 license and can be installed in your own infrastructure using the Quick Start and Production Start guides in the repository wiki. Moodle and Open edX are also self-hosted options if the feature set fits better.
- Hosting footprint: You own the database, file storage, backups and logs, so every location where course data lands becomes your scope.
- Integrations: LTI tools, single sign-on, the student information system and video services may send data to vendors outside your boundary. Map each flow before choosing.
- Support model: Confirm who patches the platform and who responds at night if the database fails in a residency-bound region.
- Backups and disaster recovery: Replicas and archives must stay inside the same boundary, which often needs a second site in the same jurisdiction.
- Vendor-hosted features: Some Instructure-hosted capabilities are not in the open-source code, so confirm whether any required feature depends on Instructure's cloud.
Before choosing, ask which data categories are regulated, which jurisdictions apply, and whether any integration already sends data outside the region.
Open-source licensing removes per-seat license fees for the platform itself, but the total cost of ownership is made of components: infrastructure, staff time, integrations, upgrades and support. Moodle is licensed under the GNU General Public License version 3, and Open edX has no licensing fees and is stewarded by Axim Collaborative. Self-hosted Canvas LMS avoids the hosted subscription, but the operating burden moves to your team.
- Who is paid for what: Licenses are free, so you pay cloud or hardware, internal engineers, an implementation partner and any managed-hosting provider.
- One-time versus recurring: Migration, content conversion and integration builds are one-time. Hosting, patching, backups and staff time recur every year.
- Cost drivers: User volume, peak enrollment periods, the number of custom plugins or themes, and the number of integrations all push cost up.
- Managed options: Open edX providers and Canvas hosting partners can shift operations cost to a contract, so compare them with self-run figures.
- What to ask in a quote: Request an itemized scope covering hosting, migration, integrations, upgrades, support hours and exit assistance.
Build a three-year cost model that includes staff time, because an apparently free platform can cost more than a subscription if nobody owns the operations.
If your teaching model needs deep changes to navigation, grading rules, authoring workflows or branding, the platform's extension model matters more than its feature list. Open edX includes the Studio authoring tool and is a strong choice when course authoring is central. Moodle has a long history of plugins and institutional customization. Self-hosted Canvas LMS gives you the code, but changes to core behavior need careful maintenance across upgrades.
- Authoring: Open edX Studio supports course construction directly, while Moodle and Canvas rely more on their own editors and plugins.
- Code ownership: With AGPL or GPL code, any modifications you distribute or host for users may carry source disclosure obligations, so confirm the terms with counsel.
- Upgrade path: Each custom change becomes a merge task at every release. Keep changes in plugins or themes where the platform supports them.
- Testing: Automated tests and a staging environment are needed to verify custom grading, reporting and LTI behavior after each upgrade.
- Skills: Confirm your team can work in Python, PHP or the relevant front-end stack, or budget for a partner who can.
Ask which customizations are must-haves, which can wait, and which existing Canvas features you truly depend on before you commit to a platform.
Regulated institutions need evidence that controls are operating, not only that the software is open source. Running any LMS yourself moves the security attestations you would otherwise receive from a vendor into your own program. Canvas LMS, Moodle and Open edX can all be placed inside a controlled environment, but the assurance comes from your configuration, monitoring and evidence collection. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any reports.
- Vendor attestations: Hosted vendors may hold certifications for their service. A self-hosted deployment needs its own scope, so ask which attestations you will need to produce.
- Access and identity: Map role-based access, single sign-on, multi-factor authentication and administrator logging to your control framework.
- Records and retention: Grade history, completion records and audit logs must be retained and exported in formats that auditors and regulators can read.
- Patching: Define how security updates are tested and deployed on a schedule your risk team accepts.
- Independent assessment: Plan for an external auditor to test the controls, and do not treat the open-source license as evidence of compliance.
Confirm which framework applies, who owns each control after go-live, and whether your auditors have accepted self-hosted evidence in the past.
What running Canvas in your own infrastructure involves
Self-hosting Canvas makes your institution the operator of a learning platform, and the work starts before the first course is loaded. The canvas-lms repository publishes Quick Start and Production Start guides in its wiki, which are the right starting point for scoping the build. Read them with a platform team, not only with the instructional technology group, because the production path assumes you will run the web tier, the background job queue, the database and file storage yourself. Ask Instructure, or your own platform engineers, to confirm the current supported versions of the database, the job queue and the Ruby and Node runtimes before you commit to an architecture.
Once the system is live, the recurring work sits in operations. Someone must own upgrades, which arrive from the open-source project and must be tested against your local customizations, LTI tools and SSO settings. Backups need to cover the database and uploaded course files together so that a restore is consistent. Single sign-on through your identity provider, LTI 1.3 registrations for every external tool, and the roles and permissions that map to your student information system all need documented configuration owners. Security monitoring, log retention and vulnerability response for the stack are also yours to run. Confirm with your own security team whether the hosted Instructure features your users rely on, such as particular analytics, mobile services or support tooling, exist in the open-source code at all, because anything that does not will have no vendor to patch or support it.
Treat the decision as a question of who carries these duties over the life of the platform, not only the first deployment. Ask prospective implementation partners for a written scope covering hosting, upgrade cadence, backup and restore testing, and incident response, and ask Instructure which features they consider part of the hosted service. Then compare that list with the commitments your institution is prepared to make on its own staff, budget and audit evidence. DeployOpen plans and operates self-hosted platforms inside client infrastructure on a fixed scope agreed in writing, so the same checklist can define that scope regardless of the platform you choose.
How Common Cartridge files carry course content between LMSs
A Common Cartridge package is the most practical way to move course structure and content out of Canvas and into another system. Canvas's Course Import Tool accepts Common Cartridge ZIP or IMSCC files, and it can also bring in Thin Common Cartridge files as module content. Its import path also covers Blackboard 6, 7, 8, 9 and Ultra exports, which matters if you are consolidating more than one legacy system. The package carries the course skeleton: modules, pages, files, assignment and quiz definitions, discussion prompts and the links between them. Treat that as the baseline for what survives the move, and check each item type against it rather than assuming the whole course arrives intact.
Plan on losing or rebuilding several categories of data. A standard export does not carry learner progress, grades, submissions, quiz attempts or anything that depends on the receiving platform's enrollments. LTI tool configuration is also usually absent, because each tool's keys, deployment IDs and launch URLs belong to the source institution's environment. Inventory every external tool a course uses, record how it is launched, and have the target platform's administrator register those tools before importing content that links to them. Grades and submissions belong in a separate archive export or your records system, not in the cartridge.
Before any production move, run imports in a sandbox course on the target platform and compare the results with the source course, item by item. Confirm that quizzes, rubrics, embedded media and links to course files resolve correctly, and note any item type that fails silently. Ask the vendor or community of your chosen platform which Common Cartridge versions and extensions it reads, because export settings in the source system determine what the file contains. Keep the original cartridge files and a record of each test import so that a later problem can be traced to a specific file and setting.
What self-hosting Canvas, Moodle or Open edX costs over several years
This table lists the cost components on the commercial side and on each self-hosted option, marking which costs are one-time and which recur. Use it to structure a quote request and a multi-year comparison, since no figures are published here beyond what the source documents state.
| Cost component | Who is paid or who carries the cost | One-time or recurring, and main drivers |
|---|---|---|
| Instructure subscription or contract (hosted Canvas) | Instructure, under the terms of your agreement | Recurring. Driven by user count, modules, support tier and renewal terms. Request the full contract schedule and renewal uplift clause. |
| Canvas self-hosted licensing | Canvas source is AGPLv3, but confirm any Instructure terms for self-hosted use, support or trademarks | Confirm in writing before modeling. Ask whether support, updates or add-on features carry separate fees. |
| Moodle and Open edX licensing | No license fee for the open-source code (GPLv3 for Moodle, AGPLv3 for Open edX platform) | None for the code. Costs come from infrastructure, staff, implementation and any paid managed provider. |
| Infrastructure, hosting, database and storage | Your cloud provider or data center | Recurring. Driven by concurrent users, course media volume, backup retention and redundancy. Ask for a sizing estimate for your peak load. |
| Implementation and integration (SSO, SIS, HR, LTI tools) | Internal staff or an implementation partner under a written scope | One-time, with some ongoing change work. Driven by the number of integrations and custom features. |
| Data migration and content reload | Internal staff or a migration partner | One-time. Driven by course volume, Common Cartridge or SCORM package quality and historical records needed. |
| Support, upgrades and security operations | Internal platform team, or a retainer with a provider | Recurring. Driven by uptime targets, patch cadence and how many upgrade cycles you run per year. |
| Internal skills and training | Your staff and your training budget | Recurring. Plan for Linux, database and Ruby or Python skills, plus LMS administration. |
What you give up when you leave Canvas and the usual workarounds
Moving off Instructure's hosted service or running Canvas yourself shifts several things from the vendor to your team. The cards below cover what usually disappears or becomes your job, and a practical workaround for each. Confirm every item against your own contract and the current feature list before you decide.
Hosted-only features and support SLAs
Some capabilities and the uptime commitments that come with them are delivered by Instructure's hosted service rather than by the open-source code. Ask Instructure which features are hosted-only, and what support and availability terms your current contract covers. When you self-host, those commitments become internal: you set your own on-call rota, escalation path and recovery targets. A workaround is an internal support runbook that maps each hosted-only feature to an owner and a documented fallback, reviewed before cutover.
Vendor-maintained integrations and LTI marketplace
Hosted customers typically rely on Instructure to keep integrations working across releases, and many LTI tools were certified against the hosted product. Inventory every LTI tool, publisher integration and SIS connector in use, then confirm with each vendor whether it supports a self-hosted Canvas or the standard LTI version you need. Retained LTI tools can keep working when you reconfigure their keys and endpoints, but each one that is not confirmed becomes a risk to plan around.
Mobile app parity
The official Canvas mobile apps are distributed and updated through app stores under Instructure's control. A self-hosted deployment does not automatically get the same app build, push notification service or release cadence, so students may see different features or delays. Ask whether your institution needs its own branded app, and whether the mobile web experience meets your learners' needs. Test grading, submissions and notifications on real devices before students depend on them.
Built-in analytics and reporting
Dashboards for engagement, course activity and outcomes depend on data pipelines and reporting services that you must rebuild or reconnect when you run the platform yourself. Identify which reports instructors and administrators use each term, then decide whether to export raw event data to a warehouse or to use an analytics tool your team already supports. Validate that the exported data matches what the old reports showed before you retire them.
Instructor-managed upgrades
On the hosted service, Instructure applies platform upgrades on its own schedule. Self-hosting makes your team responsible for database migrations, configuration changes, security patches and testing each release in a staging environment. Plan a recurring upgrade window, keep a rollback path, and document who approves each release. The canvas-lms repository publishes Quick Start and Production Start guides in its wiki, which are the natural starting points for building that process.
Staff familiarity and training
Instructors, instructional designers and help desk staff have learned Canvas workflows, and that knowledge does not transfer automatically to a new configuration. Budget time for retraining, write short guides for the workflows your faculty use most, and run a pilot course with a small group before the full move. Track help desk tickets during the first term so you can see which workflows still cause friction.
How to move off Canvas in seven phases
This sequence moves courses, users, integrations and records from a Canvas tenant to a self-hosted platform in controlled stages, so each phase has a clear output and the old tenant is only retired once retention duties are met.
Inventory courses, integrations and users
The Canvas administrator and the academic or training owners list every active, concluded and archived course, every LTI tool and API integration, every SIS feed, and every user population with its authentication method. Owners mark which courses must move, which can be archived, and which records carry retention obligations. The step is complete when the inventory is signed off by the business owners and each integration has a named owner in the target design. Ask your vendor and your own IT team to confirm which integrations depend on Canvas-specific APIs, since those will need rework rather than a simple reconnect.
Export course content through Common Cartridge
Course owners export each in-scope course as a Common Cartridge package from Canvas, and the platform team keeps the archive in a controlled, access-logged store. Instructure documents Common Cartridge as the route for moving content between systems, and Moodle and Open edX can both work with standards-based packages, though you should test each import on your own content. This step produces a verified archive with a manifest listing each course and its file count. Quizzes, rich media, rubrics and external tool placements often need manual review, so record those exceptions in the inventory.
Map roles, LTI tools and SIS data
Identity and academic operations teams map Canvas roles such as teacher, TA and observer to the target platform's roles, define how enrollments and sections arrive from the student information system, and confirm which LTI tools have a replacement and which must be retired. They also decide how grades, submissions and attendance records are exported, because those are not carried by a course package alone. The step is complete when a role and enrollment matrix is approved and every LTI tool has a target or a documented retirement decision. Confirm with each tool vendor whether it supports the target platform's LTI version.
Pilot with a small set of courses
The team imports a representative group of courses, covering different departments, content types and grading patterns, into a staging instance of the target platform. Instructors test navigation, assessments, gradebook calculations and integrations with real but non-production accounts. The pilot closes when instructors sign off each pilot course and the team logs every defect with a fix or accepted workaround. Use the results to refine the import checklist before scaling up.
Run both systems in parallel
For a defined period agreed by the steering group, active courses run in Canvas for existing learners while new term sections are built in the target platform. The team reconciles enrollments, grades and integration traffic between the two systems and tracks discrepancies in a shared log. Parallel running ends when reconciliation shows no open critical discrepancies and the steering group approves the cutover plan. The length of this period depends on your term calendar and should be confirmed with academic leadership, not assumed.
Cut over users and integrations
On an agreed date, authentication, SIS feeds and LTI launches point to the new platform, and Canvas becomes read-only for active courses. Support staff use a published runbook with rollback criteria, and identity and integration owners watch logs during the first working days. The cutover is complete when all users sign in to the new platform, scheduled jobs run without errors, and the business owners confirm that open grading cycles have closed correctly.
Decommission the old tenant after retention
Once the retention schedule set by records, legal and compliance owners is satisfied, the team takes a final verified export of Canvas data, including grade history and submission records that are not in course packages, and stores it under the approved retention policy. Only then are the Canvas tenant, integration credentials and API keys revoked and the contract closed out. The step is complete when the decommissioning checklist is signed by records, security and procurement, and the final export has been tested for readability. Confirm the retention duties and the format of the final export with your records officer before work begins.
Questions buyers ask before replacing Canvas
How much does a self-hosted Canvas or Moodle migration cost?
No supplied source gives a total price, so the cost depends on your scope. The main components are infrastructure (servers or cloud accounts, database, file storage, backups and monitoring), staff time for administration and upgrades, the migration itself (course export, content cleanup, integrations with your student information system and single sign-on), and training for faculty and administrators. Canvas and Moodle are both free to download under open-source licenses, so license fees are not the line item to compare. The costs that recur are hosting, staff time and upgrades. Ask any quote to split one-time migration work from ongoing support, and to state which integrations and content volumes it assumes.
How long does it take to move from Canvas to a self-hosted LMS?
The timeline is set by factors you can measure before you start: the number of courses and the size of their files, how many LTI tools and integrations must be rebuilt or re-tested, how many single sign-on and roster connections exist, and whether you run a pilot term before cutover. Course content moves through the Common Cartridge export and import path, which is quick for standard content but needs review for quizzes, external links and embedded media. Ask for a written plan with phases, acceptance tests and a cutover window, and confirm which dates your academic calendar requires.
Can our own team run a self-hosted Canvas without outside help?
A capable team can, provided it has skills in Linux administration, database operations, web server and queue tuning, backup and restore, and LTI integration. The open-source code is public, and the repository includes Quick Start and Production Start guides for installs. Few institutions have that depth across every area at once, and a single person leaving can stall upgrades. Decide which tasks stay in-house (daily operations, support tickets) and which you buy (initial build, hardening, upgrade runs, disaster recovery testing). DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a fixed scope agreed in writing, with ongoing support available as a retainer.
Do grades and submissions move with courses when we leave Canvas?
Course structure and content are what the Common Cartridge path carries: modules, pages, files, assignments and quiz definitions, depending on what the export includes. Student submissions, grade history, rubric scores, comments and audit trails generally need a separate extraction through Canvas reporting or API exports, and they must be mapped to the new gradebook. Confirm with your vendor and with the destination platform exactly which objects transfer, how grade history is preserved, and who signs off on reconciled totals before any old term is retired.
Does the open-source Canvas code match what Instructure hosts?
The canvas-lms repository is released under the AGPLv3 license and is created and maintained by Instructure, but the code you download is not guaranteed to match every feature in the hosted service. Some hosted capabilities, including integrations, add-ons, proctoring and certain analytics or support services, may depend on Instructure's infrastructure or on licensed components. Before committing, ask Instructure in writing which features are available in the open-source build, which require a commercial agreement, and how new releases reach self-hosted installs. Then test each feature your courses depend on in a staging environment.
What security obligations does self-hosting Canvas create?
Self-hosting moves responsibility for the platform to your organization. You own patching the application and operating system, access control, encryption of data at rest and in transit, backup integrity, logging and incident response, and vulnerability management. You also own the evidence: if an auditor reviews your controls, the records must come from your environment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Confirm your framework requirements early, because they shape hosting design and retention rules.
How does self-hosted Canvas compare with Moodle or Open edX for our team?
The choice depends on what your courses already use and what your administrators know. Canvas gives the closest feature match if you are coming from Instructure and want the same course model, and its code is AGPLv3 licensed. Moodle is GPLv3 licensed and widely deployed across universities, schools and companies, which means a larger pool of administrators and plugins. Open edX is stewarded by Axim Collaborative and includes the Studio authoring tool, which suits MOOC-style and structured course catalogs. Run a proof of concept with two or three of your real courses on each candidate before you decide.
How DeployOpen scopes a Canvas replacement
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Canvas replacement, that means the work covers the Canvas application itself, the database and file storage behind it, the identity provider used for single sign-on, the LTI tools your faculty depend on, and the course migration path from your current Canvas tenant. Scoping starts by listing those components and deciding which of them your team will run, which DeployOpen will build, and which stay with your existing vendors.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts. For this kind of project, the written scope should name the Canvas release and deployment guide being followed, the hosting target, the backup and restore test you expect to see, the hardening baseline, the content migration method (Common Cartridge export, the Course Import Tool, or a combination), and the evidence package handed over at the end. Ask for the acceptance criteria in writing, including who signs off on migrated courses and grade history. Ongoing support, upgrades and continuous testing are available as a retainer, which is usually the right question to raise once the first release is live and you know your upgrade cadence.
DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the quote to break out one-time work (design, build, migration, hardening, initial documentation) separately from recurring work (hosting, monitoring, upgrades, backups, support), and ask which of your own staff time is assumed. DeployOpen is not an official partner, reseller or certified provider of Instructure or any other vendor, and it does not issue audit reports or certifications. Where your institution needs an independent assessment of the resulting controls, the assessor or certification body does that work, and DeployOpen's role is to prepare the systems, controls and evidence for that review.
How DeployOpen scopes, migrates, hands over and supports the replacement
DeployOpen plans and implements self-hosted open-source learning platforms inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written, fixed scope that covers the Canvas replacement, the course migration and the operational handover.
How we scope
- Inventory of the Canvas features your courses actually use, including quizzes, gradebook, LTI tools and SSO
- Decision on Moodle, Open edX or self-hosted Canvas, based on course types and authoring needs
- Hosting, data residency and network requirements agreed before any installation work starts
- Written scope, deliverables and timeline agreed in writing before work begins
How we build
- Installation and configuration of the chosen platform in your infrastructure, following its documented install guides
- Course migration through Common Cartridge or IMSCC exports, with a test import and a content review
- Integration of identity, LTI tools and integrations with your existing systems as defined in scope
- Security testing and hardening of the deployed platform, with findings reported to your team
How we hand over
- Runbooks covering installation, upgrades, backups and restore procedures for your operations staff
- Documentation of configuration decisions, integrations and known gaps against the original Canvas features
- Compliance evidence packs prepared for your assessors, with the note that auditors, not DeployOpen, issue reports
- Handover session with your administrators and a sign-off on the delivered scope
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Retainer scope agreed in writing, covering the platform versions and integrations you run
- Quotes follow from the written scope, so ask for line items for build, migration, handover and retainer
