How to migrate from Blackboard Learn to Moodle without losing course history
If your team runs Blackboard Learn courses, question banks, gradebooks and integrations and needs them on a self-hosted Moodle, expect a split outcome. Courses, questions and some content can usually be brought in through documented import paths, while gradebooks, enrolments, integrations and reporting generally have to be rebuilt and tested. The total effort depends on how much content you hold, how many integrations depend on Blackboard, and which Moodle release you target. The work begins with an inventory of what you have, not with a bulk import.
Start with an inventory. List every course, its size, its last activity date and its owner, then separate courses that must move from those that can be archived. For each course, note the content types it uses (documents, embedded media, quizzes, assignments, discussion forums, SCORM or Common Cartridge packages) and whether instructors still edit it. Question banks deserve their own count, because questions are often shared across many courses and duplicated in ways that inflate the apparent volume. Confirm with your Blackboard administrators which exports they can produce and whether course archives include user submissions and grades, since that determines what course history you can actually keep.
Next, map the Blackboard features you rely on to a Moodle equivalent before any content moves. Gradebook structures are the most common gap: Blackboard grade centers, weighted columns and calculated columns do not carry over as one-to-one objects, so you will need to decide which Moodle grade items, categories and aggregation methods reproduce the same results. Enrolments and roles also need a decision. Decide whether users come from your identity provider, a file load or a sync from your student information system, and confirm how Blackboard roles such as instructor, teaching assistant and course builder map to Moodle roles.
Test imports on a copy of real data before committing to a plan. Use a non-production Moodle built on the release you intend to run, and import a representative sample: a simple course, a course with a large question bank, a course with graded assignments and a course that uses an external tool. Compare question counts, quiz settings, file links and grade results against the source. Record every discrepancy, decide whether it is acceptable, and convert the outcome into a rebuild list with owners. The target release also matters: Moodle 5.1 and 5.3 have different PHP and database requirements, and the web root for 5.1 and later must point to the public directory, so confirm your hosting stack before you start building.
Finally, agree on what "without losing course history" means for your organization. Some teams need every past grade and submission; others need a read-only archive of closed courses and a clean live environment. Ask your implementation partner to put the scope, the rebuild items, the test evidence and the cutover plan into a written statement before work starts. Ask each vendor or internal team to confirm which exports and integrations are supported in the version you run, rather than relying on general statements about either platform.
What maps from Blackboard Learn to Moodle and what does not
This table compares each Blackboard Learn area with its Moodle equivalent, the migration note and whether it is typically imported, rebuilt or redesigned. Rows marked for confirmation depend on the Blackboard export your team can produce, so check them against a sample export early. The main takeaway is that content and question banks usually move, while gradebooks, groups and integrations need deliberate rebuilding.
| Area | Moodle equivalent | Migration note | Typically |
|---|---|---|---|
| Courses and content | Courses, sections, resources and activities | Content can arrive through IMS Common Cartridge where the export supports it. Check links, embedded media and file paths. Confirm in your environment. | Imported, with checks |
| Question banks | Question bank with categories and question types | Blackboard question exports can be loaded with Moodle's Blackboard question format. Question types, feedback and media vary by export. Confirm in your environment. | Imported |
| Assessments and grades | Quiz and assignment activities | Settings, attempts, timing and availability dates are usually recreated. Questions in unsupported formats need rebuilding. | Rebuilt |
| Gradebook structure | Grade categories, grade items, weights and aggregation | Blackboard grade columns and weighting schemes do not carry over one-to-one. Plan the Moodle gradebook design before loading grades. | Redesigned |
| Users and enrolments | User accounts, course enrolments and roles | Accounts arrive through an authentication plugin or CSV upload. Map roles and match user identifiers so historical submissions link correctly. | Imported |
| Groups | Groups and groupings | Membership is usually rebuilt from a current roster. Activities restricted to groups need their group settings reconnected after the move. | Rebuilt |
| Announcements and discussions | News forum and forum activities | Discussion history and attachments may be archived or imported as files. Confirm what the export contains before promising thread history. | Rebuilt |
| Integrations such as SSO and video | Authentication plugins, LTI tools and video plugins | Blackboard connections are not carried across. Rebuild and test each sign-on and video integration, such as SAML 2.0 through a plugin. | Redesigned |
Which Moodle import paths apply to a Blackboard migration
Moodle core offers three routes that can carry Blackboard material into a new site: question imports, Common Cartridge packages and CSV upload tools. Each one covers a different kind of content and stops at a different boundary, so the path for each content type should be chosen before any export is requested. Confirm early which exports your Blackboard administrators can produce, because that list decides which routes are available.
Blackboard question format import
Moodle's question import includes a Blackboard format for question sets exported from Blackboard. It brings question text, answer options and feedback into a question bank, so teams can review the banked questions before reusing them in quizzes. Check whether each exported question type maps cleanly, and rebuild any quiz settings, attempt rules or question categories by hand afterward.
IMS Common Cartridge 1.0 and 1.1
Moodle's built-in converters can read IMS Common Cartridge 1.0 and 1.1 packages for course content where the Blackboard environment can export them. The package carries content structure and resources, but activity types without a matching Moodle equivalent need rework. Ask your Blackboard administrators whether they can produce these packages and which course content types the export includes.
Cartridge content mapping limits
Common Cartridge exports vary by source system and content type, so a successful import does not confirm that every item arrived intact. Test a representative course from each department, comparing links, embedded media and file paths against the source. Plan a rework list for items that fail to map, and assign an owner for each entry.
CSV upload for users
Moodle's upload users tool loads accounts from a CSV file, which suits a one-time load of user records for the new site. Decide the identity source before the import, because accounts created this way must match the authentication method the institution will use. Confirm with your administrators which user fields the Blackboard export can supply.
CSV upload for courses and enrolments
Moodle's upload courses tool creates course shells and can assign enrolments from a CSV file, so course structure can be prepared before content arrives. This tool does not move gradebooks, group membership or course settings from Blackboard unless your export supplies that data and you verify it. Confirm what your Blackboard administrators can export for enrolments, and compare the imported rosters with the source before teaching begins.
Grades, groups and settings
None of the three paths should be treated as carrying grades, groups or course settings unless the documentation for your version and your Blackboard export confirms it. Gradebook setups, group structures and course configuration usually need to be rebuilt or verified by hand. List these items as a separate workstream during planning, and ask your implementation partner to quote them within the written scope.
What has to be rebuilt by hand after the import
Plan on recreating most of the gradebook in Moodle rather than expecting it to arrive intact. Blackboard gradebook categories, weighting schemes, grade items and letter scales do not map one to one onto Moodle's grade structure, so treat them as design work. Ask the registrar and academic leads to confirm which grading schemes are still in use, which are historical, and which must produce identical final grades for past terms. Then rebuild the gradebook setup in Moodle's grade categories and grade items, choose the aggregation method for each category, and define letter scales where the institution reports them. Check the results against a sample of real student records from the Blackboard source, term by term, before any instructor is given access.
Integrations need their own design, and the import does not carry them across. Student information system feeds, identity provider sign-on, video conferencing and publisher content each depend on connection settings, credentials, data ownership and role mapping that live outside the course files. For the student information system, confirm whether enrolment comes from a recurring feed, a file load or a manual process, and who owns that data. For identity, decide how Moodle user accounts are created and matched, and which authentication plugin will carry sign-on. For video conferencing and publisher content, record which tools are in use, which Moodle plugin or LTI connection replaces each one, and whether licenses or content keys must be re-issued for the new platform.
Record every rebuilt element as an item in a migration inventory, with one row per element. A useful row names the Blackboard source, the Moodle target, the owner who approved the design, the test case that verifies it, and the status. Gradebook categories, individual grade items, letter scales, each external integration, each LTI tool, each enrolment source and each role mapping should all have their own rows. Keep the inventory in version control or a controlled document so that changes are dated and traceable. Testing then works from a fixed list: each row needs a pass or fail result and a named tester, and no row should close until its check is repeatable.
Set the inventory up before the first test cycle, not after the build. Teams that start with the import and add rebuilt items as they are remembered tend to miss integrations that only show up under real use, such as a grade passback that fails at term end or a publisher link that opens without the correct course context. Ask the vendor or plugin maintainer to confirm the supported version and configuration for each integration in the Moodle release you plan to run. Moodle's current release line and support windows are listed on the releases page, and the choice of version affects which plugins and settings you can rely on, so confirm both before design freezes.
How to sequence a Blackboard to Moodle cutover with a parallel run
This sequence moves a Blackboard Learn deployment to a self-hosted Moodle in controlled stages, so each course, question bank, gradebook and integration is checked against its source before students and instructors depend on it. The length of each stage depends on scope and should be fixed in the written plan.
Inventory courses, questions, users, grades and integrations
Before any build starts, the team lists what Blackboard Learn holds: active and archived courses, question banks and their export formats, user populations and roles, gradebook structures, and every system that reads from or writes to the LMS. DeployOpen typically runs this with your registrar, instructional design and identity owners, and the output is a signed inventory that marks each item as migrate, rebuild, retire or keep in place. The step is done when every course and integration has an owner and a disposition in writing.
Choose the target Moodle release and hosting
The team selects the Moodle release and the infrastructure it will run on, weighing the support windows in the release schedule, the PHP and database versions each release requires, and the organization's own hosting and patching rules. For a new install, confirm the web server document root will point to the public directory required from Moodle 5.1 onward. The step closes with a written decision record covering release, PHP, database engine, hosting location and the upgrade path after go-live.
Build the base instance and identity
The team builds the Moodle instance in your environment, configures the database, file storage, backups and email, and connects authentication to your identity provider. Core authentication options include manual, LDAP, external database, OAuth 2 and Shibboleth, and SAML 2.0 is usually handled by a community plugin that you must validate against your Moodle version. The step is complete when test accounts from each user population sign in, receive the correct roles and pass a restore test of the backup.
Import a pilot set of courses and questions
A small, representative set of courses is chosen with instructors, covering different content types, question types and course sizes. Question banks are exported from Blackboard and imported with Moodle's Blackboard question format where the export is compatible, and course content is brought in through IMS Common Cartridge where the source supports it. Each import is logged with the items that converted cleanly and the items that need manual rework. The step is done when the pilot courses load without errors and the rework list is agreed with the pilot instructors.
Rebuild gradebooks and integrations
Imported content does not carry the Blackboard gradebook, so grade categories, weightings, grade items and any calculated fields are rebuilt by hand in Moodle using the pilot courses as the reference. Integrations such as single sign-on, roster feeds, video, file storage and reporting are rebuilt against the inventory, with each connection tested against a sample of real but non-sensitive data. The step closes when a sample set of grades calculated in Moodle matches the expected result for each pilot course.
Run the parallel period and compare against the source
For an agreed period, both systems stay available, and instructors check the imported courses, questions and gradebooks in Moodle against the same content in Blackboard. Discrepancies are logged with severity, fixed in Moodle or in the import process, and retested. The parallel period is the point where the team confirms that rebuilt grade calculations and integrations behave as expected under normal use. The step is complete when instructors sign off each migrated course and every open discrepancy has a fix or an accepted exception.
Execute the cutover with a Blackboard freeze
The team sets a defined freeze on the Blackboard side, after which no new grades or content are entered there. The final incremental import brings in changes made during the parallel period, DNS, identity and integration endpoints are switched, and a final reconciliation confirms student, course and grade counts. Support contacts and a rollback decision point are agreed in advance. The cutover is done when Moodle is the system of record, the freeze is recorded and the reconciliation report is accepted by the business owner.
Decommission Blackboard after the retention period
Blackboard remains available in read-only form for the retention period set by your records, legal and accreditation requirements. Once that period ends, the team takes a verified final export, confirms the export can be restored or read, removes access, and decommissions the hosting and integrations. The step is complete when the retention period has expired, the archive is verified and the decommissioning record is signed by the data owner. Confirm the retention length with your records office before the plan is written.
What drives the cost and duration of a Blackboard migration
This table lists the factors that most change how much work a Blackboard Learn to Moodle move takes and what the one-time build differs from the recurring run cost. Read each row as a question to answer before requesting a quote, since the answers determine scope more than any single platform setting. Costs for the build, testing and cutover are one-time, while hosting, upgrades and support recur for as long as the Moodle site runs.
| Driver | Why it matters | What to ask for in a quote |
|---|---|---|
| Number and state of courses | Each course needs export, conversion, review and sign-off. Archived, empty or duplicate courses still consume effort unless they are excluded early. | A course inventory with counts by status, term and owner, and a stated rule for what is excluded. |
| Share of content needing manual rework | Blackboard content that does not convert cleanly, such as proprietary tools, embedded widgets or links to course-internal pages, must be rebuilt or reattached by hand. | An estimate of rework by content type, based on a sample of real courses, and who performs and verifies each fix. |
| Question bank size and formats | Blackboard question exports are imported through Moodle's Blackboard format. Large banks, multipart questions and custom question types need mapping and test imports before they can be trusted. | The number of questions, the question types in use, and a test import of a representative sample before the full run is priced. |
| Gradebook complexity | Weighted categories, calculated columns, custom grading schemes and manual overrides rarely carry over as-is and usually need to be rebuilt in Moodle's grade structure and checked against historic results. | A list of gradebook schemes in use, a plan for verifying grades against source records, and who signs off on the comparison. |
| Integrations and SSO requirements | Each connected system, such as the student information system, SSO provider, content tools or publisher links, needs a new connection, a test plan and a cutover step. SAML SSO often needs a plugin choice made early. | A list of integrations with owners, the protocol for each, and whether each is rebuilt, replaced or retired. |
| Data retention rules | Retention periods decide which courses, user records and grades are migrated, archived or deleted. Legal holds and accreditation records can extend the migration scope. | A written retention schedule from the organization, and confirmation of how archived data will be stored and accessed after cutover. |
| Target Moodle release and server requirements | The target release sets the minimum PHP version, database engine and web server layout. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and a document root pointing to /public, while Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17. Hosting changes can add cost before any content moves. | The chosen Moodle release with its support dates, the server stack it needs, and whether existing infrastructure must be upgraded or replaced. |
| Number of parallel-run cycles | Each parallel run repeats content checks, grade comparisons and user testing. More cycles reduce cutover risk but add calendar time and effort. | The number of test cycles included in the fixed scope, the exit criteria for each cycle, and the cost of any extra cycle. |
| One-time versus recurring costs | The migration build, testing and cutover are one-time costs. Hosting, Moodle upgrades, security patching and support recur every year the platform runs, and they grow with user count and integrations. | Separate line items for one-time work and annual run costs, with the upgrade cadence and the support hours included in each. |
Identity and enrolment decisions before content moves
Settle users, roles and enrolments before any course content moves into Moodle. Course ownership, instructor access and gradebook records all attach to Moodle user accounts, so an import that runs before identities are correct can leave courses owned by the wrong people and grades attached to duplicate accounts. Start with a written map of Blackboard roles to Moodle roles: which Blackboard instructor roles become Moodle teachers, which become non-editing teachers, and who holds site administration. Choose the field that identifies each person across both systems, such as an institutional ID, username or email address, and confirm that this field is stable and populated for every account, including staff, students and external guests.
Moodle core ships several authentication plugins that decide how people sign in, including manual accounts, LDAP, external database, OAuth 2, Shibboleth and LTI. LDAP and external database authentication can draw user records from a directory or database your organization already runs. OAuth 2 and Shibboleth suit sites that delegate sign-in to an external identity provider, and LTI matters where Moodle receives launches from other tools. The core list does not include SAML 2.0. That protocol is commonly provided through the auth_saml2 plugin maintained by Catalyst IT, which maps identity fields to Moodle profile fields. Confirm that plugin's compatibility with your target Moodle release, and confirm which protocols your identity provider can issue, before you commit to a design.
Enrolment is a separate decision from authentication. Authentication answers who can sign in, while enrolment answers which courses each person can see and in which role. Moodle can take enrolments from a one-time CSV load, from an external database or LDAP enrolment method that keeps them current, or from a combination of the two. A one-time load is simple to rehearse and leaves no ongoing link to the source, but any change made in Blackboard after the load must be replayed before cutover. A recurring sync keeps Moodle current through a parallel running period, but it needs a named owner, a schedule and a rule for removing people who leave. Decide which method your team will run before you plan the cutover window, because that choice determines whether Blackboard must be frozen for enrolment changes.
Record these decisions in writing and test them with a small set of accounts before any course is imported. Create a test course with a teacher, a student and a non-editing teacher, sign each in through the chosen method, and check that enrolment, role and grade visibility match the mapping. Pay particular attention to people who hold more than one role across courses, because those cases tend to surface late. Also identify accounts that exist in both systems under different identifiers. Duplicates found after grades have been imported are costly to unpick, so resolve them at this stage.
What usually goes wrong in a Blackboard to Moodle move and how to prevent it
Most problems in a Blackboard to Moodle move show up after import, not during it. The cards below cover the failure points that repeat across these projects, each paired with a check to run before cutover.
Gradebook totals change after import
Grade items, category weights and hidden totals do not always carry over in the same form, so a course can show different final grades than it did in Blackboard. Before cutover, compare a sample of students' final grades in the source and target systems and rebuild the gradebook categories by hand where the totals differ.
Question formats import partially
Blackboard question exports can bring in some question types cleanly and others with missing answers, lost feedback or broken formatting. Import a representative question bank into a test Moodle site first, then review each question type you use and rewrite the ones that do not survive.
Courses duplicated during a parallel run
If Blackboard and Moodle stay open for students at the same time, instructors may edit the same course in both systems and create two versions of the truth. Decide which system is the record for each course, lock or archive the other copy, and tell instructors where to make changes.
Integrations discovered late
Single sign-on, roster feeds, video tools, plagiarism checks and publisher content links often sit outside the course content and are missed in the inventory. List every connection to Blackboard, including the ones administrators have forgotten, and confirm each has a Moodle plugin or a rebuild plan before the cutover date is set.
Target server requirements not met
The current host may run a PHP, database or web server version that the target Moodle release does not support, and the upgrade path can require a minimum starting version. Check the requirements of the release you plan to run against your hosts early, and confirm the web server document root will point to the required public directory.
Content owners not signing off before cutover
Instructors who never review their migrated courses often discover missing files, broken links or wrong due dates in the first week of term. Assign each course an owner, give them a fixed review window with a checklist, and make sign-off a condition for the cutover decision.
Questions buyers ask before hiring help with a Blackboard to Moodle migration
How much does a Blackboard to Moodle migration cost?
The cost follows the written scope, and no fixed figure applies to every migration. Moodle core is licensed under GPL-3.0 and can be downloaded, so the software license is not the cost driver. The cost is the labor and the infrastructure. The labor covers inventory of courses and question banks, export and conversion work, rebuilding gradebook setups and integrations, testing with content owners, and cutover. Infrastructure, hosting, backups and patching are separate and recur. The biggest variables are the number of courses and their age, the volume of media, how many Blackboard-specific features are in use, the complexity of the gradebook, and how many integrations must be rebuilt or re-tested. When you request a quote, ask for the work itemized by phase, the assumptions behind each line, what is excluded, and how change requests are priced.
How long does a Blackboard to Moodle migration take?
The timeline is set mostly by the inventory and the content sign-off cycle, not by the file export. Export and conversion are usually the shortest phases. The longer phases are deciding what to migrate and what to archive, waiting for course owners to review converted content, rebuilding gradebook structures and integrations, and running test cycles with real users. Integration work also depends on the availability of the teams that own your identity provider, student information system and video tools. Ask for a milestone plan that names the dependency for each phase, the number of review rounds assumed for content owners, and the date by which each client input is needed. A plan that does not show who signs off each phase is likely to slip at the sign-off stage.
What access and people does the migration need from us?
The work needs four things from your side. First, administrator or export-level access to the source Blackboard Learn environment, so the team can take course exports and question bank exports. Second, a target environment for Moodle, including a test instance and a production instance, with server access that the implementation team can use. Third, named owners who can approve converted content for each department or program, because content accuracy is a decision for the academic owner, not the technical team. Fourth, integration contacts for the systems that connect to Blackboard today, such as identity, the student information system, video conferencing, plagiarism checks and file storage. Confirm with your Blackboard administrator which export permissions your license and configuration allow before the project starts.
Can our own team migrate Blackboard to Moodle without a partner?
Yes, a capable internal team can run a migration, and the decision depends on skills, capacity and risk tolerance more than on the software. The team needs Moodle administration experience, server operations for a PHP and database stack, and enough time to run the content review with academic owners. The conversion of course content is one part of the work. The larger part is often the rebuild: gradebook categories and weighting, LTI tools, single sign-on, roster or enrolment sync, and the verification that each of them behaves correctly for each user type. Ask yourself whether the team has done a cutover before, who will own the project if priorities change, and how the team will test before students arrive. A partner is usually scoped to specific deliverables, so compare that scope with your own plan.
Which Moodle release should we target for a migration?
Target a supported release whose support window covers your go-live date and the years after it, and choose a long-term support release when you want a stable base. Because you are building a new site rather than upgrading an existing Moodle, install the current release that fits your planning window. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. 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. It also removes the Classic theme from core, so confirm the theme plan early. Check the release notes on the day you start, because schedules and support windows can change.
What happens to our Blackboard data after cutover?
The Blackboard data stays where it is until your institution decides what to do with it, and that decision should be written down before cutover. Agree on a final export archive, a read-only period for the Blackboard instance, a retention schedule for course content, grades and student records, and the date the instance is decommissioned. Confirm what evidence your institution needs that data was deleted or transferred, and who signs it off. Check your contract with the Blackboard provider for termination terms and data return obligations. Student records can carry obligations under privacy laws and accreditation rules, so involve your records office and legal team. Also confirm which historical data Moodle will carry over, such as grade history, submissions and user activity, because the conversion of course content does not automatically move every data type.
Which integrations and gradebook items must be rebuilt by hand?
Course content can be moved through the import formats and converters, but gradebook structures and integrations usually need to be rebuilt or checked by hand. Expect to rebuild grade categories, weighting, grade items and any custom calculations, and then compare results against the Blackboard figures for a sample of students. For sign-in, Moodle core ships authentication plugins for LDAP, external database, LTI, OAuth 2, Shibboleth and web services. SAML 2.0 is commonly provided by the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, which lists support for Moodle 2.7 through 5.1. Confirm the plugin version against the Moodle release you select before you commit to it. Roster sync, LTI tools and any Blackboard building blocks in use need a list of owners and a test plan, because they rarely convert on their own.
How DeployOpen works on this
DeployOpen plans and delivers the move from Blackboard Learn to a self-hosted Moodle in infrastructure you control. The work starts with a written scope that separates what converts through Moodle's import tools from what must be rebuilt, then moves through build, testing, documentation and handover, with ongoing support available as a retainer.
How we scope
- Inventory courses, question banks, gradebook setups and integrations that Blackboard Learn currently provides to your teams.
- Classify each item as importable with Moodle's Blackboard format or IMS Common Cartridge, or as a manual rebuild.
- Agree the target Moodle release, database engine and PHP version in writing before any build begins.
How we build
- Import a sample of question exports and course packages into a staging Moodle to measure what converts cleanly.
- Rebuild gradebook categories, weighting and grade items by hand from the agreed scope, then test them against source records.
- Reconnect identity and other integrations, then check user access, enrolments and course visibility before cutover.
How we hand over
- Deliver a migration record listing each course, question bank and integration, with its import method and status.
- Document the import steps, mapping decisions and manual rebuilds so your administrators can rerun or audit them.
- Walk your administrators through the production environment, web server configuration and the runbook for routine tasks.
How we support
- Offer post-cutover support for issues found by instructors and students during the first term of use, as the agreed scope defines.
- Plan Moodle upgrades around the release and minimum-version rules published for your target version, with you confirming the timing.
- Make ongoing support, upgrades and continuous testing available as a retainer after handover.
