How to migrate from Blackboard to Moodle without losing course data
Most institutions reach this page because a renewal, a hosting change or an on-premises requirement is forcing a move off Blackboard Learn. Moodle can take most course content through standard packages, but grading, question banks, discussions, LTI tools and SIS links must be rebuilt and verified. Treat the migration as two workstreams: moving course material, which is largely mechanical, and rebuilding the parts that do not travel, which needs faculty time and a test plan. The institution's LMS team usually owns the work and brings in an implementation partner for the Moodle build, integrations and data handling. Blackboard's own dates set the urgency: the latest self-hosted Learn release listed is v3900.84.0 from February 15, 2024, and Managed Hosting has not been supported since December 31, 2022, so confirm your current support status directly with Blackboard before you set a cutover date.
Moodle is licensed under GPL-3.0 and can be self-hosted in your own data center or cloud account, or run through MoodleCloud or a Moodle Partner. That choice determines who patches, backs up and upgrades the platform, so settle it before scoping. Ask any partner for a written scope that lists each course type, each integration and each record set to be migrated, along with who verifies grades and who signs off on each stage. Effort and risk rise with the number of courses using Blackboard-specific tools, the volume of gradebook history and the number of LTI and SIS connections. Run a pilot on a small set of representative courses, compare gradebook totals line by line against the Blackboard source, and only then schedule the full cutover.
Which Blackboard features move to Moodle cleanly and which need rework
This table maps common Blackboard Learn capabilities to their Moodle equivalents and marks each as clean, needs rework or gap. Read it as a checklist for your own course inventory, then confirm each row against the Moodle version you plan to deploy, since behavior and plugin availability vary by release. Most content moves, but gradebook logic, question banks and integrations usually need deliberate rebuilding.
| Blackboard capability | Moodle equivalent and status | What to confirm in your Moodle version |
|---|---|---|
| Content areas and modules | Course sections and activities. Needs rework: Common Cartridge brings files and pages, but layout is usually rebuilt by hand. | Check how your import maps folders and modules to sections and activities. |
| Common Cartridge export | Import through Moodle's course backup and restore tools. Needs rework: review every imported item, since some resource types arrive as plain files. | Test one representative course end to end before bulk import. |
| Gradebook and grading schemes | Moodle gradebook with grade categories and weights. Gap for direct transfer: grades are not carried over in Common Cartridge, so rebuild or import from a grade export. | Confirm how grade categories, weights and letter schemes are set up in your version. |
| Random question blocks and question banks | Moodle random questions drawn from categories. Needs rework: random block logic is not carried over and must be rebuilt in the quiz settings. | Verify category structure and random selection counts in a test quiz. |
| Tests and assessments | Moodle quiz activity. Needs rework: question types and settings often need manual review after import. | Check question types, attempt limits and time settings against your policy. |
| Discussion boards and threads | Moodle forum activity. Gap for threads: posts and thread history generally do not transfer with course content. | Decide whether to archive threads separately for records retention. |
| Announcements | Moodle news forum and course announcements. Needs rework: re-post or archive current announcements manually. | Confirm notification settings reach students as expected. |
| LTI tools and SIS connections | Moodle LTI external tools and LTI core authentication. Needs rework: tool keys, launch URLs and roster sync must be reconfigured. | Confirm each tool version supports LTI in your Moodle release and retest launches. |
| Authentication and SSO | Moodle core authentication includes LDAP, LTI, OAuth 2, Shibboleth and external database. SAML2 requires the marketplace auth_saml2 plugin. | Check which method your identity provider needs and confirm plugin compatibility with your Moodle version. |
| Archives with student data | Moodle course backup and restore, kept under your own retention rules. Needs rework: archives from Blackboard are not restored directly and need separate handling. | Ask your records office which student data must be kept, and where. |
What data and integrations need to move, and through which export paths
A Blackboard to Moodle move is really four separate transfers: course content, archived student records, identities and enrolments, and LTI tool connections. Each travels through a different path, and each path leaves something behind. Check every group against your own export before you commit to a cutover date.
Course content through Common Cartridge
A Common Cartridge export carries course structure and standard content items such as files, pages and links that can be reused in another system. It is the portable layer, so it is the first thing to test. Moodle's own import tools must be used to bring the content in, and every imported item should be reviewed because formatting, embedded media and proprietary Blackboard content types may not map cleanly. Do not assume that anything missing from the cartridge is recoverable later without the original course. Confirm in your environment which Blackboard content types appear in a sample export and which of them need manual rebuilding in Moodle.
Gradebook and assessments need separate checks
Treat grades, random question blocks and discussion threads as items to verify, not items to assume. Common Cartridge exports are not a reliable source for gradebook data, and question pools that draw random items at delivery time usually need to be rebuilt. Discussion threads and their replies may also be left behind. Ask the team responsible for your Blackboard exports to confirm, with a sample course, exactly which of these items appear in each export format before you plan the Moodle gradebook rebuild.
Course archives that contain student data
A full course archive package can include submissions, grades and attendance records, which makes it a student record rather than a content file. Before any archive is downloaded to a shared drive, copied into a Moodle backup or restored into a test site, decide how long it must be kept and who may access it. Blackboard packages also expire after a set period, so the export window matters. Involve your records officer and data protection lead first, and confirm where the archive will be stored and how it will be deleted at the end of its retention period.
User identities and enrolments through the SIS
Accounts, roles and course enrolments usually come from the student information system or a directory, not from Blackboard exports, so the migration depends on the SIS feed being rebuilt against Moodle. Confirm how usernames map to existing identities, how historical enrolments are handled and whether instructors keep their teaching roles. Moodle core provides authentication plugins for manual accounts, LDAP, external database, LTI, OAuth 2, Shibboleth and web services. Confirm which of these your institution already uses, and test enrolment sync on a copy of production data first.
LTI tool connections to re-register
Each external tool, such as a publisher content platform, plagiarism checker or video service, is connected to Blackboard through its own registration with a key and secret. Those registrations do not move with the course content, so each tool must be registered again in Moodle and its deep links tested inside migrated courses. Ask each vendor whether it supports a new registration in Moodle and whether existing licences or stored user data transfer. Keep a register of tools, owners and contacts before cutover so that no connection is discovered broken by a student.
Migration sequence from inventory to decommission
This sequence moves Blackboard Learn courses, gradebooks, integrations and enrolments into a supported Moodle site in stages, so each phase ends with a documented output you can check before the next one starts. It also keeps retention-bound archives under your control until the Blackboard environment is retired.
Inventory courses, tools and retention obligations
Start by building an inventory register that lists every active and archived course, its owner, enrolment count, assessment types, LTI or building block integrations, and the SIS feeds that depend on it. Record which records your retention schedule requires and where they must be kept. Registrar, LMS administrators and the compliance owner should sign off on the register. The step is done when every course has a disposition (migrate, archive only, or retire) and every integration has a named owner.
Run a pilot import into a test site
Stand up a Moodle test site on a version that is still in support, and confirm the database engine against the Moodle release notes for that version. If you choose Moodle 5.1, point the web server document root at the
/publicdirectory, not the main Moodle folder, or the site may show directory listings or errors. Import a representative set of courses chosen to cover quizzes, group work, file-heavy content and gradebook schemes, then log every item that did not come across. The output is a pilot sign-off list that states, for each course, what transferred, what was rebuilt by hand and who accepted it.Rebuild gradebooks, question banks and LTI tools
Common Cartridge exports do not carry everything from a Blackboard course, so grading schemes, random question blocks, discussion threads and some assessment settings need to be recreated in Moodle. Rebuild the gradebook categories and weights, reconstruct question banks, and reconnect each LTI tool with its consumer key and launch settings. Ask each tool vendor which Moodle version and LTI version they certify. The output is a reconciled gradebook report for each pilot course, compared line by line against the Blackboard grade export, with differences explained.
Run a parallel period with a defined overlap
Keep Blackboard available in read-only or limited mode while instructors and students use Moodle for the same pilot courses over an agreed overlap window. Compare submissions, grades and enrolments between the two systems at fixed checkpoints and log each discrepancy with an owner and a fix. Confirm the length of the overlap with your academic calendar and vendor contract terms, not with a generic duration. The output is a parallel-run log with every discrepancy closed or formally accepted.
Cut over enrolments, SIS feed and DNS
Switch the SIS feed to point at Moodle, reconcile enrolment and role data against the registrar's records, and then change the DNS record so users reach the Moodle site. Test authentication through your identity provider, including any SAML2 or LDAP connections, before the switch. Keep a rollback plan with a tested procedure to point DNS back. The output is a cutover checklist signed by the registrar and the service owner, with a post-cutover enrolment reconciliation report.
Decommission Blackboard and store archives
After the agreed exit point, export the final course archives that your retention schedule requires, including submissions, grades and attendance where applicable, and store them in an access-controlled location under your records policy. Confirm with your vendor how long the Blackboard environment and its data remain available and what must be done before the contract ends. Remove integrations and revoke service accounts. The output is a decommission record listing every archive, its storage location, its retention end date and the person who approved deletion of the source data.
What drives cost and duration in a Blackboard to Moodle move
This table lists the factors that most change the effort and cost of moving Blackboard courses to Moodle, with the reason each matters and how to keep it under control. Use it to shape the scope you send to a partner, since most of the cost sits in archive handling, integrations and gradebook validation rather than in the software itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number and complexity of courses | Each course that uses adaptive release, random question blocks, discussion threads or custom content needs manual rebuilding because Common Cartridge does not carry all of it. | Inventory courses by usage, archive dormant ones, and migrate only active or required courses in the first wave. |
| Archives containing student data | Course archives with submissions, grades and attendance need secure storage, access control and a records retention plan, which adds handling work beyond course content. | Agree a retention schedule with records staff first, then split archives that must be kept from content that only needs reloading. |
| LTI tools and custom integrations | Each LTI tool must be registered, configured and tested in Moodle, and any custom integration built against Blackboard APIs needs redesign. | List every tool and integration from Blackboard admin settings before scoping, and retire tools no longer used. |
| SIS integration depth | Enrollment, term and grade feeds from the student information system must be rebuilt and tested against Moodle's data model, and errors here affect many users at once. | Document the current feed formats and run test enrollments in a non-production Moodle instance before cutover. |
| Gradebook rebuild and validation | Grade categories, weighting and calculated items do not move as a full set, so staff must rebuild them and check results against prior grades. | Limit the rebuild to courses in scope, and ask faculty to sign off a sample of grade calculations for each course type. |
| Moodle hosting and database choice | Moodle's requirements depend on the release: Moodle 5.1 needs PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and Moodle 5.3 raises these to PHP 8.3 and PostgreSQL 17. Your hosting choice sets the recurring infrastructure cost. | Choose the database engine your team already operates, size hosting against the expected concurrent users, and confirm the release you will run before buying infrastructure. |
| Upgrade cadence | Moodle ships major releases in April and October and point releases every two months, so each upgrade is recurring work with testing, plugin checks and a maintenance window. | Plan to run a long-term support release where your policy allows, and budget a fixed test cycle for each upgrade. |
| Staff availability for validation | Faculty, registrars and administrators must test courses and grades, and their availability often sets the schedule more than technical work does. | Book reviewer time early, name one accountable owner per department, and agree acceptance criteria in writing. |
What usually goes wrong and how to prevent it
Most failed Blackboard to Moodle moves fail in the same few places: grades, question logic, discussions, integrations, archives and the server stack. Each risk below has a prevention step that feeds a checklist, a sample course test and a named sign-off before cutover.
Gradebook totals that do not reconcile
Imported assignments and quizzes rarely bring their weighting, categories and hidden items with them intact, so course totals can shift after rebuild. Before any live course is switched over, export final grades from Blackboard for a sample of courses and compare them line by line with the rebuilt Moodle gradebook, including dropped lowest scores and extra credit. Record every difference and have the registrar or instructor of record sign off the reconciled totals.
Random question blocks flattened
Blackboard test pools that draw a random set of questions for each attempt are often exported as a fixed list, so every student sees the same questions. In Moodle, rebuild these as random question selections drawn from a question bank category, then test two or three attempts as different student accounts. Confirm that question counts, point values and feedback match the original quiz before you publish it.
Discussion threads left behind
Common Cartridge exports do not carry discussion threads, replies or grading of posts in the form Moodle needs, so instructors can open a course and find the forums empty. Decide per course whether threads are archived as read-only records, copied as text into a forum, or closed. Keep the Blackboard export for the thread history, and get the course owner to approve the approach in writing.
LTI tools failing after re-registration
Each external tool in Blackboard has its own client ID, deployment ID and endpoints, and none of them transfer to Moodle. Register each tool again as an external tool in Moodle, then confirm launch, grade passback and roster access with a test course for every tool. Ask each vendor whether it needs a new consumer key or a new deployment, and document the outcome before you switch learners over.
Archives copied into uncontrolled locations
Full course archives include submissions, grades and sometimes personal data, and teams often copy them to laptops, shared drives or email while they work. Set a single controlled storage location with named access, encryption and a retention end date that matches your records schedule. Confirm with your records officer and data protection lead which fields must be kept, and delete working copies once the sign-off is recorded.
PHP and database versions not matching the release
A Moodle release only runs on specific PHP and database versions, and the web root must point to the public directory from Moodle 5.1. Check the release notes for your chosen version against the servers you actually run, and upgrade the stack before installing Moodle. Fix the document root in the web server configuration first, then run a staging install with an imported course set before any production change.
How the migration differs by institution size and starting point
A small college usually has a limited number of courses, a short list of integrations and a small team that handles the LMS alongside other duties. The migration is mostly a content and training exercise. Course export and import take a modest share of the effort, and the largest task is usually deciding which courses are worth moving at all, since many terms of archived courses may never be needed again.
- Course selection: Move only active and required courses, and export the rest as archives for records retention.
- Gradebook rebuild: Expect to recreate grade items by hand in most courses, which is manageable at this size.
- Integrations: Confirm which LTI tools and the single sign-on setup are actually in use before planning any reconnection.
- Training: Staff and instructors learn one new system, so a short set of guides and a pilot course usually cover the need.
- Operations: Plan who applies Moodle point releases and backups, since a small team has few backup administrators.
Check with the college's registrar and records office which course archives must be kept and in what format before any export starts.
A large university typically runs a student information system feed, several LTI tools, separate sandbox and production instances and formal change control. The course content is the smaller part of the work. Most of the effort goes into rebuilding integrations, testing enrollment and grade passback, and coordinating several departments that depend on the LMS.
- SIS integration: Enrollment feeds, term codes and grade return must be tested against Moodle before cutover.
- LTI tools: Each tool needs its own configuration, key exchange and test course, and some vendors may need a new registration.
- Environments: Use separate development, test and production instances, with the database and document root configured the same way in each.
- Governance: Departments sign off on their own courses, and the migration calendar must avoid enrollment periods and exam weeks.
- Records: Archive packages with student submissions and grades need a retention plan agreed with the registrar and legal teams.
Confirm with the SIS vendor and each LTI tool provider whether their connectors support the Moodle version you plan to run.
An institution that runs Blackboard in its own data center and plans to keep Moodle there has the most infrastructure work. Hosting, database administration, backups, patching and availability move from the vendor to the institution's own staff. Course migration is the same task as elsewhere, but the surrounding platform work grows substantially.
- Server build: Plan the web server, PHP and database layers, and configure the web server document root to point to the
/publicdirectory from Moodle 5.1 onward. - Database choice: Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, so confirm the database platform against the current support matrix before building.
- PHP version: Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported.
- Backups and recovery: Test restores of both the database and the moodledata directory, because archive packages and course files depend on both.
- Upgrade path: Sites must run Moodle 4.4 or later to upgrade to 5.3, so older intermediate versions need a staged upgrade.
Ask your infrastructure team to confirm the staffing and hardware plan, and check the Moodle release notes for the target version before committing to a build.
Teams that choose MoodleCloud or a Moodle Partner shift hosting, patching and database operations to the hosting provider. The migration keeps the same content and integration steps, but the questions change: which data residency commitments apply, what the contract covers, and who handles upgrades and restores. Because the provider runs the platform, fewer infrastructure tasks land on the institution's own team.
- Hosting terms: Confirm where course data and backups are stored, and how long archive copies are kept.
- Integrations: Check which LTI tools and authentication plugins the hosted plan allows, because custom plugins may not be available on every service tier.
- Upgrade ownership: Ask whether the provider schedules Moodle point releases and major upgrades, and how much notice is given.
- Exit planning: Request a written export of courses, gradebooks and user data in case the service is later changed.
- Support: Clarify whether the provider or your own staff handles Moodle configuration questions.
Ask the provider to put these answers in writing before any content is imported, since they determine what the institution must still maintain itself.
Questions buyers ask before moving from Blackboard to Moodle
How much does it cost to move from Blackboard to Moodle?
The cost is the sum of several components, and no single figure applies to every institution. Moodle itself carries no license fee because it is released under GPL-3.0, so the recurring costs are hosting, storage, database and backup infrastructure, staff or partner time for upgrades and patching, and integration work. The one-time costs are course migration, archive handling, gradebook rebuilding and LTI reconnection. Costs rise with the number of courses, the volume of attached media, the number of LTI tools and the SIS integrations that must be rebuilt. Ask any implementation partner for a fixed-scope quote that lists each component separately, including what is one-time and what recurs each year.
How long does a Blackboard to Moodle migration take?
The timeline depends on scope more than on the platform itself. The main drivers are the number of courses to move, how many courses use features that Common Cartridge does not carry across, such as grading schemes, random question blocks and discussion threads, the number of LTI tools and SIS connections to rebuild, and how many approval cycles faculty and records staff require. Plan around academic calendars so that migration does not collide with term start or grading deadlines. Ask for a written timeline with phases for pilot courses, full migration, parallel testing and cutover, and confirm which phases the partner expects your staff to staff.
What does the work require from our own staff?
Your staff must provide decisions and subject knowledge that no outside team can supply. Faculty or course owners confirm which courses move, which content is current and how assessments should be rebuilt. Registrar or records staff define retention rules for archives. The SIS administrator supplies the data feeds and identifiers, and the identity team confirms single sign-on settings. Your LMS administrators also need to learn Moodle administration, because they will own upgrades, plugin decisions and backups after handover. Ask the partner to name these roles in the scope document so the institution can plan staff time before work starts.
Can our internal team migrate from Blackboard to Moodle alone?
A capable internal team can move simple course content, but the work becomes risky when courses depend on gradebook structures, LTI tools, SIS feeds or archives that carry student data. Moodle is documented and widely deployed, so administrators with Linux, PHP and database experience can install and operate it. The gaps usually appear in migration verification, reconciling grades and handling records retention. Teams that want to keep the work in-house should map which Blackboard features each course uses, run a pilot, and decide early whether to bring in an outside partner for the high-risk pieces. DeployOpen plans, implements, integrates and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts.
How should archives with student data be handled for records retention?
Treat Blackboard archives as records, not as migration input alone. Export the full course archives, which carry submissions, grades and attendance where those were recorded, and store them in a location your records office controls before any import begins. Confirm the retention schedule and the access rules for each record type with your records and legal teams, since Common Cartridge exports do not reliably include all of this data. Keep the archive reviewable separately from the live Moodle site, and test that a sample of records can be opened and read after the move. Ask your partner to document where each archive is stored, who can access it and how it is deleted at the end of its retention period.
Do LTI tools and the SIS reconnect automatically after migration?
No. Course content can move, but integrations generally do not reconnect on their own. Each LTI tool needs its consumer key, shared secret or registration, and launch URLs configured again in Moodle, and each vendor may require its own approval step. Moodle core includes LTI support and single sign-on options such as OAuth 2 and SAML2 through a plugin, but your identity settings, SIS data feeds and roster sync must be rebuilt and tested with live identifiers. Build a list of every LTI tool and SIS connection, confirm each vendor's support for Moodle, and test enrollment, grade passback and attendance flows in a staging site before cutover.
Which Moodle version should we start on for our servers?
Choose the version after checking your server stack, because each Moodle release sets minimum PHP and database versions. Moodle 5.1 requires 64-bit PHP 8.2 or later and supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later, and sites must already run Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and upgrades must start from Moodle 4.4 or later. Moodle 4.5 is a long-term support release with security support until 4 October 2027. For a new deployment, confirm your database and PHP versions first, then pick the release line your operations team can keep patched. From Moodle 5.1, the web server document root must point to the /public directory.
How DeployOpen scopes, runs and supports the Moodle migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Moodle inside your own infrastructure, including the Blackboard course migration. Each engagement starts with a written scope that covers courses, archives, gradebooks, LTI tools and the SIS connection before any work begins.
How we scope
- Inventory which Blackboard courses, archives and gradebooks are in scope and which are retired.
- Identify LTI tools, the SIS feed and authentication sources that must reconnect to Moodle.
- Agree in writing how archives with student data are stored, retained and access-controlled.
How we build
- Install and harden Moodle on your servers, matching a supported PHP and database version.
- Test Common Cartridge imports and rebuild random question blocks, threads and grading by hand.
- Configure LTI, SAML2 or other authentication and the SIS integration, then test each path.
How we hand over
- Deliver runbooks covering installation, backups, restores, upgrades and the course migration record.
- Document which items were rebuilt manually, so instructors know what changed from Blackboard.
- Walk your administrators through daily operation, plugin management and the upgrade procedure.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Moodle upgrades around the release schedule and confirm each target version before work.
- Confirm support terms, response expectations and scope boundaries in the written agreement.
