Migrate courses to Moodle with IMS Common Cartridge

Whether a Common Cartridge package converts cleanly into Moodle depends on two things you do not control on your own: what the source LMS wrote into the package, and what Moodle's built-in converter accepts in the release you plan to run. Confirm both in writing before you commit to this path. A package that imports without error can still arrive with missing activities, flattened structure or lost settings, so the import log alone does not answer the question.

A Common Cartridge package is a compressed archive with three parts that matter here. The manifest, a file named imsmanifest.xml, lists the organizations (the course structure), the resources (the files, web links and content items) and the dependencies between them. Metadata describes the package and its items, such as titles, descriptions and classifications. The resources hold the actual content. The version of the specification determines which content types and metadata fields are expected. Version 1.0 and version 1.1 differ in what they can carry, so a package exported as 1.1 may contain item types that a 1.0 reader does not recognize. Ask the source LMS vendor which version the export uses and which content types it writes into the manifest.

Moodle does not map every manifest element to an activity. Its converter reads what it recognizes and creates the matching course content, so the gap between what the source system exported and what Moodle created is where the rework lives. Ask the team that will run the migration to confirm, for the exact Moodle release you plan to run, which Common Cartridge versions and item types the converter handles. Do not assume a version is supported because a neighboring release supports it. Record the answer with the release number, because converter behavior can change between releases.

Before you migrate the full course catalog, run a short test with one representative course per content type. Choose a course that uses each element you need to keep: a plain page, a file set, a web link, a discussion, a quiz with several question types, an assignment with a rubric or grading scheme, and any embedded media. Export each from the source LMS, import it into a non-production Moodle site on the planned release, and compare the result item by item against the source. Log which items arrived as the intended activity, which arrived as a generic file or link, and which were dropped. Those results decide which courses move by import and which are rebuilt by hand.

Treat the test as a decision tool, not a pass or fail gate. A course that converts with only cosmetic losses may be worth importing and tidying. A course whose assessments, grade items or completion rules fail to convert usually costs less to rebuild than to repair after import. Keep the test results, the exported files and the Moodle release number together so that the decision can be reviewed later, and repeat the test when you upgrade Moodle or change the source export settings.

Once the IMS Common Cartridge package has been imported, the course exists in Moodle, but it does not yet behave like the course it came from. Plan a dedicated pass on every course before anyone treats the migration as finished. Start with activity settings. Due dates, submission types, attempt limits, availability windows and completion conditions often arrive with defaults, or with values that the source system interpreted differently. Work through these as a checklist for each activity type, and record each exception so the same fix can be applied to every course that shares the pattern. Also confirm that links, resource references and embedded items still point to the correct targets, because relative paths and cross-references are among the first things to break when content changes platforms.

The gradebook is the next area that most projects rebuild by hand. Check the category structure, aggregation methods, item weights, hidden items and locked grades against the source gradebook. A Common Cartridge package can carry the activities without the grading logic that connected them, so do not assume the totals will match. Then review the people layer. Reassign course roles so that teachers, non-editing teachers and students map to the Moodle roles your policy requires. Confirm that enrolment methods such as manual enrolment, cohort sync or external database enrolment are configured the way your institution expects. Restore groups and groupings, and rebuild completion rules and activity dependencies that once guided learners through the course.

Integrations need separate work. Video and conferencing activities usually reference an external meeting tool, tenant or account, and those references must be re-linked to the systems you operate and to the authentication settings that govern them. Test embedded media, plagiarism detection and external tool launches from a learner account as well as an administrator account, since permissions and sign-in paths differ. Settle the theme decision before course review starts. Moodle 5.3 removes the Classic theme from core, so any course that depends on its layout will need a supported theme or a maintained custom theme plugin. If the theme changes after reviewers have approved layouts, every course must be checked again. Confirm which theme your target version will use before the first course is reviewed.

Content owners must review each course against the source. This is usually the largest recurring effort in the project, because the import can move files and structure correctly while still changing wording, images, links, question feedback or the order in which material appears. Give each owner the original course and the converted copy side by side, a shared checklist and a defined sign-off step. Expect the review to repeat in later terms whenever courses are updated. When you request a quote, ask the partner or internal team to price the content review separately from the technical import, so the recurring cost is visible and can be planned against teaching calendars.

The parallel run is the period when the legacy LMS and the new Moodle site both exist, and the most important decision in it is which system is the record of truth for each term or cohort. During a parallel run, grades, submissions and enrolments keep changing in the old system while teachers and students begin to use Moodle, so two sources drift apart quickly. Decide this per term or per cohort, in writing, before the first course is opened to students. For example, an illustrative plan might keep the spring cohort's gradebook in the legacy LMS until the term closes, while the autumn cohort starts in Moodle with imported enrolments. Name the owner of each decision, and state what happens to submissions that arrive in the wrong system during the overlap.

Cutover checks should be run against the Moodle server before any student-facing announcement. Start with enrolment reconciliation: compare the count of active enrolments per course and per role in the legacy system with the count in Moodle, and investigate every difference, including suspended users, guest access and users enrolled through more than one method. Next, compare grades for a sample of courses, covering courses with weighted categories, manual overrides, hidden grades and late penalties, because these are where imported values most often differ. Then test access for each role, including students, non-editing teachers, editing teachers, managers and any external or observer accounts, and confirm that each role sees only the courses and grades it should.

The Moodle server itself must be ready before any of these checks mean anything. Confirm that the database engine, PHP version and web server meet the requirements of the Moodle release you are installing, and check the official release notes for that version. For Moodle 5.1 onward, the web server document root must point to the new /public directory rather than the main Moodle folder. If it does not, the site can show directory listings or errors, which can look like a failed import to users. Ask the implementation partner or your own platform team to record the web server configuration in the cutover runbook, and confirm the PHP and database versions on the production hosts, not only on a test server.

A rollback plan has to name who can reverse the cutover, under what conditions, and how long the legacy system stays available for reads and writes. Define the trigger conditions in advance, such as an unresolved enrolment mismatch in a named set of courses or a grade discrepancy above a threshold agreed by the academic owner. Name the single person with authority to call the rollback, and a deputy. Then document the reverse path: how enrolments and submissions created in Moodle during the window are carried back, and who signs off that the legacy gradebook is current. A reverse path that has never been run is not a plan, so rehearse it on a copy of the production database before the cutover date and record how long it takes.

Plan the cutover so that the reverse path is tested on the same version and configuration that will go live, not on an earlier build. Confirm with the vendor and with your hosting team which database backups can be restored, how point-in-time recovery is configured, and where the legacy export files are kept. Ask for a written cutover and rollback runbook as a deliverable, with checks, owners and sign-off points, so that the decisions made in the room are the ones that get executed under pressure.