When Moodle SCORM packages fit your course catalog
If a vendor has sold you SCORM or IMS content packages, the first decision is whether Moodle core can host them without a custom build. The SCORM and IMS content package modules ship in core Moodle, so for most catalogs the answer depends on what the packages need from the platform: how they report completion and scores, how they launch, and how large they are. Course designers, LMS administrators and compliance or training leads usually share this decision. Designers judge whether a course suits the activity, administrators judge hosting and upload limits, and compliance leads decide which completion evidence must be kept. Confirm each of these against your own vendor packages before committing to a design.
Start with an inventory. For each package, ask the vendor which SCORM or IMS edition it targets, what data it sends back (completion status, score, time spent), and whether it depends on an external launch host, video stream or API call. Check whether it opens in a single window or in pop-ups, because browser behavior affects testing. Request the package file itself so you can import it into a test course on a staging site. Record the size of the largest package, since the upload limits and storage quota of your Moodle instance and web server will decide whether it can be stored at all.
A partner is most useful when the catalog is large, when packages must support regulated training records, or when the platform is new to your team. Typical work includes the hosting decision, a test import of representative packages, configuring completion and grade settings in the activity, and checking reporting through the gradebook and logs. Version choice matters here. Moodle 5.1 requires the web server document root to point to the /public directory, and Moodle 5.3 requires PHP 8.3 or later, so confirm your target release before building the course structure. Ask any partner for a written scope that lists the packages, the tests and the handover.
Decide early which courses will stay as SCORM or IMS packages and which should be rebuilt in native Moodle activities. Packages you cannot edit carry the vendor's content forward unchanged, so updates depend on the vendor issuing a new file. Ask who owns the package files, who may replace them in a course, and how retired versions leave the catalog. Also confirm how learner attempts are handled when a package is replaced, because a changed file may reset tracking for enrolled learners. Write these answers into the catalog plan before the first import so the team does not settle them course by course.
What the core SCORM and IMS modules do
Moodle's core SCORM and IMS content package modules cover five steps that a course team handles in sequence: getting a vendor package into the site, launching it, recording results, placing it in a course, and reviewing what learners did. Each capability below lists what the team configures and what to confirm in the documentation for your Moodle version.
Uploading and deploying a package
The course team adds a SCORM package or IMS content package activity and uploads a zip file of the vendor's courseware. Moodle reads the package manifest, which describes the launch files and the content format, and unpacks the package for delivery. Check which SCORM and IMS versions your release accepts, the maximum upload size set by Moodle and by your web server and PHP settings, and how an updated vendor package replaces the existing one. Confirm the exact behavior in the documentation for your Moodle version.
Launching the package in a course
Display settings decide how learners reach the content: embedded on the course page, opened in a pop-up window, or shown in a full window. The team also sets navigation options and the number of attempts a learner may make. Test the launch in each browser and device class your learners use, because vendor content often depends on window sizing and pop-up handling. Confirm the display and attempt options available in your version.
Recording completion and score
The package sends status and score data to Moodle through the SCORM runtime calls, and Moodle stores that data against the activity. The team decides which result counts toward course completion and the gradebook, and which attempt is used when a learner has several. Agree these rules with the instructional designer before launch, then run a sample learner path to confirm the stored status matches what the vendor intended. Confirm how each SCORM version reports score and completion status.
Placing packages alongside other activities
A package is one activity among quizzes, assignments, labels and resources, so its position in the course sequence shapes what learners see. Teams use activity completion conditions and access restrictions to require a package before the next step, and they weight its grade alongside other graded items. Map each package to a learning outcome, and check how dependent activities behave when a package does not report completion. Confirm the completion and restriction options available in your release.
Reviewing attempt and tracking data
Tracking data from each attempt is the evidence that training and compliance owners usually request. The team decides who can view attempt reports, which fields instructors can see, and how long records are kept under the institution's retention rules. Export and reporting options can differ between releases and plugins, so test an export with a sample attempt before learners start the course. Confirm which tracking elements are retained and exportable in your version, and whether your privacy process covers them.
How SCORM completion and scores reach the gradebook
The learning record for a SCORM or IMS content package is created when a learner launches the package. The package runs in the browser, decides what counts as completed or passed, and reports that status and any score back to Moodle through the API the package standard defines. Moodle stores the report against the learner's attempt and, where the activity is set up to pass grades, writes the result to the gradebook. That means completion rules, the grade method, and attempt settings are not global defaults. Each package needs its own decisions, and the course designer should record them before the package is added to a course.
Start with completion. In Moodle, the activity completion settings define when the activity is marked complete for a learner, and the options available depend on what the package reports. Some packages report a pass or fail status, some report only that content was viewed, and some report a score without a clear status. Decide whether completion should follow the package's own status, a minimum score, or simply the learner opening the package. Then decide how that completion feeds course completion and any dependent activities, since a mismatch here is the most common reason a learner appears stuck.
Next, decide the grade method and the attempt settings together. The grade method determines which attempt's score is recorded when a learner makes more than one attempt, and the attempt settings determine how many attempts are allowed and whether the package resumes or restarts. These choices interact with what the package stores between sessions. A package that does not save its own progress will restart on each launch, so a learner's best score may not reflect the full course. Confirm these behaviors with the package vendor rather than assuming them from the Moodle settings screen.
Tracking depends on two things outside Moodle's control: the package standard and what the vendor's package actually reports. SCORM and IMS content packages use different runtime interfaces and different data models, and vendors implement them to different depths. Some packages report reliably, some send incomplete or late status updates, and some report only in certain browsers. Ask the vendor which standard and version the package uses, which data elements it sets for completion and score, and whether its reporting has been tested against a learning management system. Treat those answers as claims to verify, not as proof of behavior.
Before rollout, test each package with a test learner in a non-production course that mirrors the real settings. Launch the package, complete it in every way a learner might, including partial completion, failing, resuming after leaving, and retrying, then check the activity report, the completion status, and the gradebook entry after each step. Record what Moodle shows against what the package claims. Repeat the test after any change to the completion, grade, or attempt settings, and after Moodle or browser upgrades, because reporting problems often appear only when the surrounding platform changes.
Which SCORM package settings to decide before upload
This table compares the decisions to settle before a vendor package reaches a Moodle course, with the options for each and the points to confirm. Read each row before the first upload, because several choices, such as hosting and grading rules, are hard to change once learners have started attempts.
| Decision | Options | When each fits | Confirm with the vendor |
|---|---|---|---|
| Package standard and edition | SCORM edition the package was built for, or an IMS Content Package | Match the edition the vendor declares. Imports fail or report incorrectly when editions differ | Exact SCORM edition, IMS content package version, and manifest structure |
| Hosting location | Package uploaded to Moodle, or referenced from an externally hosted URL | Upload for control and backups. External hosting suits very large packages or vendor-managed content | Whether the vendor allows Moodle-side hosting, and any content delivery restrictions |
| Completion and grading rules | Completion from the lesson status or completion status the package reports, with a grade method for multiple attempts | Choose the reporting element the package actually sends. Mismatches leave learners stuck or mark them complete too early | Which data elements are reported, the passing score, and whether scores are sent per attempt |
| Attempt limits and display | Limited or unlimited attempts, and whether a previous attempt is shown or retained | Compliance training often needs fixed attempts. Open practice content usually needs unlimited attempts | Whether the package expects resume data, and how it behaves on a retake |
| Who may upload packages | Course editors, a restricted teacher role, or site administrators only | Restrict uploads where content is vetted before release. Allow course editors where teams publish their own courseware | Whether the vendor requires a specific content review or version sign-off before import |
| Course scope and reuse | Package used in one course, or the same package duplicated across several courses | Single-course use is simpler to track. Reuse across courses multiplies completion data and upload effort | Whether the license covers multiple courses, sites or tenants before reuse begins |
How a SCORM package moves from vendor file to live course
The sequence takes a vendor's SCORM or IMS content package from a zip file to a course learners can use, with a check at each stage. Each step closes with a record the client keeps, so the package can be audited, reproduced and supported after handover.
Intake and validate the vendor package
DeployOpen receives the package and checks its structure, including the manifest file, the launch and resource references, and the SCORM or IMS version it declares. We also confirm what the vendor says it supports: the SCORM edition, expected completion and score reporting, browser requirements and any external URLs the content calls at runtime. Questions go back to the vendor in writing before anything is installed. The step closes when the package register entry is complete: file name, checksum, declared standard, vendor contact, licence terms and open questions. Only validated packages move on.
Align the test environment with Moodle
We build or confirm a test Moodle site that matches the production target: the same Moodle release line, PHP version, database engine and web server layout. Supported versions are listed in the Moodle release notes, and the site must meet the requirements for its release, including the public directory document root that Moodle 5.1 introduced. Any gap between test and production is recorded. The step closes with a test record stating the exact Moodle, PHP and database versions, plugin versions and configuration settings used for testing, so later results can be reproduced.
Upload and run the launch test
The package is imported into a test course through the SCORM or IMS content package activity, and the team confirms that the course structure, titles and launch page appear as the vendor intended. We open each sco or resource, check that content loads without console or security errors, and confirm that navigation and the content's own pages work inside the Moodle frame. Large packages are checked for load time and for any assets blocked by the web server or browser policy. The step closes with a test record listing each launch, the browser and device used, and any defects reported back to the vendor.
Verify completion and grades with a test learner
A test learner account, separate from real users, completes the course in several ways: a full pass, a partial attempt, a fail and an interrupted session that is resumed. For each path, we compare what the content reports to the SCORM runtime with what Moodle records in the activity completion and gradebook. Score scaling, passing thresholds and completion criteria are checked against the vendor's specification. Gaps are recorded in a grading map that states, for each course, which runtime values feed completion, which feed the grade and how the two are mapped. The step closes when the grading map has been signed off by the client's course owner.
Run pilot courses with real learners
The course is released to a small, agreed group of real learners in a pilot category or enrolment group, under the same settings planned for production. The team monitors launch failures, reported completion problems, browser issues and support requests during the agreed pilot period. Feedback is sorted into vendor defects, Moodle configuration issues and content questions, each with an owner. Changes go through the test environment first and are re-verified against the grading map. The step closes with a pilot report listing the issues found, how each was resolved and the criteria the client used to approve the course for general release.
Hand over the course and runbook
The client receives the finished course and a runbook that describes how to add, replace and retire packages, how to check completion after a Moodle upgrade, and who to contact at the vendor. We walk the client's administrators and course owners through the runbook and the grading map, and record which team owns each recurring task. The package register is updated with the live course identifier and the version of each package deployed. The step closes when the client accepts the handover in writing, which starts the support arrangement agreed in the scope, if one was included.
What makes a SCORM rollout cost more than expected
This table lists the drivers that change effort and cost in a SCORM or IMS content package rollout, with whether each one is mainly one-time or recurring. Use it before requesting a quote, and check the last column for what the written scope should state. The main takeaway is that package quality and the Moodle upgrade path cause the most surprises, so both need explicit scope.
| Driver | One-time or recurring | Why it moves cost | What to ask for in a quote |
|---|---|---|---|
| Number and size of packages | Mostly one-time import and testing, plus recurring storage | Each package needs import, launch and tracking checks, and large files add storage and backup load. | Package count, total size, largest file, and which packages are in test scope. |
| Standard version and file quality | Mostly one-time | Mixed SCORM and IMS versions and malformed manifests need repair or vendor correction before launch. | Who fixes defective packages, and whether vendor re-delivery is included. |
| Grade and completion mapping | One-time design, recurring checks | Completion rules, scores and pass thresholds must match the gradebook and be tested with sample learner attempts. | A written mapping table, test cases, and a sign-off step for each course. |
| Courses and roles involved | Recurring course administration | Each course adds teacher, designer, reviewer and administrator steps that repeat whenever content changes. | Named roles, approval steps, and the number of courses in the first phase. |
| Hosting capacity and storage | Recurring | Package storage, upload limits and concurrent learners drive server sizing and backup volume. | Sizing assumptions, storage growth assumptions, and backup retention for package files. |
| Upgrade path across Moodle releases | Recurring, at each major or minor release | Moodle 5.1 needs PHP 8.2 or later; 5.3 needs PHP 8.3 or later. Packages need retesting after each upgrade. | Target release, required database versions, and whether package regression tests are included. |
| Web server configuration | One-time, then recurring at upgrades | From Moodle 5.1 the web root must point to the /public directory, or the site may show listings or errors. | Confirmed web server configuration and a post-change test of package launch. |
| Vendor updates and support | Recurring | Courseware updates and security patches reopen package testing and mapping work. | Support scope, response expectations, and how content updates are handled. |
Running large packages on infrastructure you control
Large SCORM and IMS packages fail in predictable places, and most of those places sit outside Moodle itself. Before you import vendor courseware, confirm the upload ceiling at three layers: the PHP directives that cap request and upload size, the web server limit on request body size, and any proxy or load balancer in front of the site. A package that uploads cleanly on a test server can fail on production because a different layer enforces a smaller limit. Ask the vendor for the largest package it expects you to host, then test that exact file against your real stack.
Storage growth is the operational issue that surprises teams most. Each imported package is unpacked into the course content area in the Moodle data directory, so one large course can consume far more disk than the uploaded archive suggests, and a course copy or backup restore can duplicate that content. Plan the data directory on storage with room to grow, decide whether packages are retained after import, and make sure the backup scope covers the data directory as well as the database. A database-only backup restores course records that point to files you no longer have. Confirm the backup tool, retention period and restore test with your operations team, not just the vendor.
Browser performance depends on the package more than on the server. Heavy content with many media files, large video or deeply nested scripts can slow a learner's machine even when the server responds quickly. Test representative packages on the browsers and devices your learners use, including older laptops and shared lab machines, and check how the package behaves on a slow connection. If a package loads slowly, ask the vendor whether assets can be reduced before you host it, and record that finding before you accept the package into production.
Server requirements change between Moodle releases, so the target version determines the hosting plan. From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, along with MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Check the release notes for your target version, confirm your current version can upgrade to it, and verify every PHP and database setting in your own environment before you import large packages.
How SCORM content connects to grades, sign-in and reporting
Package delivery touches the gradebook, sign-in, reporting, any external record store and the storage that serves package files to learners. Each connection has its own settings and its own questions for the courseware vendor, so confirm them before the first import.
Gradebook and completion rules
The package reports completion and score back to Moodle, and the activity's grade settings decide what reaches the gradebook. Check which SCORM or IMS version the vendor's package declares, whether it reports a score, and whether pass or fail is set by the package or by a Moodle grade threshold. Confirm how course and activity completion are calculated and whether the vendor's status values map onto what Moodle expects. Test one learner's record from launch to gradebook before you publish the course to students.
Sign-in through core authentication
Learners reach packages through whatever sign-in method the site uses. Moodle core ships authentication plugins for LDAP, OAuth 2, Shibboleth, LTI, external database and manual accounts. Confirm which method your identity source supports, which user fields Moodle maps on first sign-in, and whether one identifier is used across Moodle and any external system. SAML 2.0 is usually added through the community SAML2 plugin, which is not part of core, so confirm its support for your Moodle version before you rely on it.
Reporting and exports
Moodle's reports show completion and grades per learner, and course-level exports can feed analysis or audit evidence. Decide which fields the business needs, such as attempt count, time spent and final score, and confirm whether the package sends those values. Vendor-specific data elements often stay inside the package and may not appear in standard reports, so ask for a sample report from a test course. Plan who reviews exports and how long they are kept, since learner progress is personal data.
External learning record store
Some vendors require an external learning record store (LRS) that receives activity statements outside Moodle. Confirm with the vendor whether their package needs one, which endpoint and credentials it uses, and where the store is hosted. Then check in Moodle's documentation whether the activity module you plan to use can reach that store, since the package and the LMS may report to different places. Ask who owns the store, how long records are retained, and whether it sits inside the same data boundary as the Moodle site.
Package file storage and serving
Uploaded package files are stored in Moodle's file area and served to browsers through the web server, so disk capacity and web server settings both affect large packages. Confirm the maximum upload size in PHP and the web server, the data directory's disk and backup plan, and whether package files share a host with the site. From Moodle 5.1, the web server document root must point to the public directory, otherwise the site may show directory listings or errors. Test a large package through the production proxy and TLS settings.
What buyers ask before bringing in a Moodle SCORM partner
How much does it cost to host SCORM packages in Moodle?
Cost depends on the scope written into the quote, not on the file format alone. Most of the spend is labor: reviewing vendor packages, configuring each activity and its completion settings, testing every launch path, and fixing packages that do not behave as the vendor described. Some costs recur, including storage for large packages, re-importing when a vendor sends a new version, and any support retainer you keep for later changes. Costs rise with the number of packages, the number of tracking rules per package, links to your gradebook or reporting, and the amount of testing across browsers and devices. DeployOpen does not publish a price list. Ask any partner for a quote that lists each package, its tracking rules, the testing scope, the hosting work, and which items are one-time and which recur.
How long does a Moodle SCORM import project usually take?
Timing depends mostly on how many packages arrive and how complete the vendor files are. A small set of packages with clear completion rules moves quickly. A large catalog with unclear rules, missing test accounts or broken packages moves at the pace of the vendor's responses. Ask for a schedule that separates intake, test imports, grading review, fixes and sign-off, and assign a named owner to each vendor response. Hosting access and a staging Moodle site also set the start date, because no package can be tested without them. DeployOpen agrees timelines in the written scope before work starts, so the schedule in your proposal should reflect your package count and review cycle rather than a generic estimate.
What do we need to give a partner before work starts?
Your team supplies the courseware, the grading rules and the access. Expect to provide:
- The vendor package files (SCORM or IMS zip files) and any vendor release notes or known-issue lists.
- Completion, pass and score rules for each package, written down, including the passing score and attempt limits.
- Test learner and instructor accounts on the staging site.
- Hosting access to a staging Moodle, including server or container access and the ability to change PHP and web server settings.
- A named decision-maker who approves the grading rules.
Also ask the vendor how each package was authored and what data it reports to a learning platform. Vendors often hold the answer to tracking questions, and that answer affects how long testing takes.
Can our internal team import and test SCORM packages alone?
Yes, if your team has Moodle administration skills and time for testing. One administrator can import a few packages and configure completion, but the work becomes risky when tracking must match gradebook rules, packages are large, or the site runs live courses at the same time. Internal teams often underestimate testing: each package needs launches in each browser, completion checks, score checks, and a review of what the gradebook records. Check whether your staff can read a package manifest, reproduce a learner attempt, and read Moodle and server logs. If they cannot, a fixed-scope engagement can handle the imports while your staff takes over routine operations. The decision depends on skill, capacity, and how often new courseware arrives.
How do IMS content packages differ from SCORM in tracking?
SCORM packages report progress and scores back to Moodle while the learner works. IMS content packages are mainly a delivery format. SCORM content calls a runtime interface in the browser, so Moodle can record completion, status and score when the package sends them. An IMS content package describes how content is organized and launched. Tracking usually depends on what the content does on its own, so Moodle may not receive completion or scores the way it does from SCORM. Confirm this for your Moodle version and for each vendor package by completing a full attempt on staging and checking the recorded results. A package that imports cleanly has not yet proven that it tracks.
What operational issues come with very large SCORM packages?
Large packages create problems with upload limits, server timeouts, storage growth and learner load time. Moodle's upload size and execution time depend on PHP and web server settings, so a package that imports on a test machine can fail on a production host with stricter limits. Media-heavy packages also grow your backups and can slow the first launch for learners on weak connections. Check upload limits, execution time, disk capacity and backup size before the first import, and test launch time from typical learner networks. From Moodle 5.1, the web server document root must point to the public directory, so confirm that setting during any upgrade. Ask your partner which limits they will test and how they will record the results.
Why do SCORM completion results sometimes not reach the gradebook?
Results usually fail to reach the gradebook because the activity settings, the package's reporting, and the grade item setup do not agree. Check first that the activity tracks completion, that the package sends a status or score, and that the grade item is linked with the expected maximum. Then confirm whether the learner finished an attempt or only launched the content, and whether the attempt limit and passing score in Moodle match the rules you and the vendor intend. Reproduce the problem with a test learner account on staging and review the attempt records for that activity. If the package never reports a score, the gradebook cannot receive one, so the fix may sit with the vendor's package rather than with Moodle settings.
How DeployOpen scopes and delivers SCORM package hosting
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Moodle SCORM and IMS content package delivery, that means agreeing the package inventory, tracking rules and hosting limits in writing before the build starts, then handing over a working, documented setup your team can run.
How we scope
- Inventory every vendor SCORM and IMS package with its version, size and launch behavior before estimating build work.
- Record which completion, success and score rules each course must report to the gradebook.
- Agree in writing which Moodle release, PHP version and database engine the site will run.
- Confirm which packages need migration from another LMS and which will be replaced by newer versions.
How we build
- Configure the SCORM and IMS content package activities, upload and validate sample packages in a staging Moodle first.
- Test completion, pass and score reporting against each tracking rule in the scope, with a documented test script.
- Tune web server, file storage and upload limits for the largest packages, and document the settings used.
- Set up backups and restore tests that cover the course files, package storage and the database together.
How we hand over
- Deliver a written configuration record covering package locations, activity settings, tracking rules and hosting limits.
- Provide the test scripts and results so your course designers can repeat checks after each new package.
- Document the steps for importing a new vendor package, including the checks that catch broken launch paths.
- Walk your administrators and course teams through the runbook and confirm acceptance against the written scope.
How we support
- Offer ongoing support, Moodle upgrades and testing as a retainer, scoped separately from the initial build.
- Plan each Moodle upgrade against the package inventory so content is retested on the target release before go-live.
- Review storage growth and upload behavior for large packages as part of routine maintenance.
- Ask for a quote built from the written scope, which sets out what is one-time work and what recurs.
