Why keeping an existing SCORM and LTI library working is the hard part of an LMS move
Moodle covers SCORM 1.2 natively and reaches xAPI through plugins, while Open edX relies on LTI for external tools and its own analytics stack for learning records, so the platform choice depends on which standards your library actually uses. If most of your packages are SCORM 1.2, Moodle is the shorter path. If you depend on SCORM 2004 features, xAPI statements feeding a learning record store, or tools that already speak LTI Advantage, each platform needs a different build. Start with an inventory of every package and tool, not with the license, because the license is the same cost regardless of which library you bring.
The library drives the build. Moodle's SCORM FAQ states that Moodle passes the ADL conformance test suite 1.2.7 for SCORM 1.2, but that SCORM 2004 is not supported apart from parts of the basic API, and it points to a Rustici Software plugin connected to SCORM Cloud for full SCORM 2004 support. That plugin is a separate component with its own licensing, hosting and upgrade path to plan for. Ask your team to sort the library by standard, version and whether each package makes external calls, since packages that call out to a hosted service will behave differently on your own network. Confirm each package launches and reports completion on the target version before any migration is scheduled.
External tools need the same discipline. Moodle's LTI documentation describes deploying an LTI Advantage tool by entering its registration URL, registering legacy LTI 1.1 tools with a cartridge, and notes that IMS Global has deprecated LTI 2. Make a list of every tool, its LTI version, who owns its contract and which courses depend on it, then test each one against the new platform with real learner accounts. Open edX states that its current Verawood release added LTI Advantage Complete certification, but the tool vendor's support for your target platform still needs written confirmation. Budget for the testing and vendor coordination as part of the move, since they are the parts most often left out of the plan.
Which content and tool requirements change the build
This table compares the content standards and tool integration methods that shape an LMS build, including SCORM, xAPI, AICC and LTI. Read each row for the source of the requirement, how Moodle and Open edX handle it, and the work it adds to your plan. The main takeaway is that legacy packages and tools need a test and retirement plan before the move, not after.
| Requirement | What the sources say | What it means for the build |
|---|---|---|
| SCORM 1.2 | Moodle passes the ADL conformance test suite 1.2.7 for SCORM 1.2 (Moodle SCORM FAQ). | Native support in Moodle. Test each legacy package in a staging site against the target Moodle version and confirm completion and score recording. |
| SCORM 2004 | Moodle does not support SCORM 2004 beyond parts of the basic API. Full support comes through a Rustici Software plugin connected to SCORM Cloud (Moodle SCORM FAQ). | Confirm the licensing and hosting terms for the plugin and any external service before committing. Inventory which packages use 2004 features and plan testing or re-export. |
| xAPI and learning record store | Moodle supports Tin Can through third-party plugins, including logstore xAPI for sending logs to an external learning record store and mod_tincanlaunch for launching packages (Moodle SCORM FAQ). | Decide early whether you need a learning record store. Budget for plugin testing, store hosting and retention rules. Open edX handles xAPI differently through Aspects analytics. |
| AICC packages | Moodle supports AICC packages from Moodle 2.1 (Moodle SCORM FAQ). | Confirm whether any archive still uses AICC. Test launch and score return on the target release, since older packages often fail on newer browsers. |
| LTI 1.1 cartridges | Legacy LTI 1.1 tools are registered in Moodle with a cartridge (Moodle LTI External tools documentation). | List every tool in use and its owner. Plan a retirement or re-registration date for each, because cartridge-based tools may not offer the same data exchange as newer standards. |
| LTI Advantage | Moodle deploys an LTI Advantage tool by entering its registration URL. Open edX Verawood added LTI Advantage Complete certification (Moodle LTI documentation; Open edX Verawood release notes). | Prefer LTI Advantage for new integrations. Confirm each vendor's support for your Moodle or Open edX release and test grade passback and deep linking. |
| LTI 2 | IMS Global has deprecated the LTI 2 specifications (Moodle LTI External tools documentation). | Treat any LTI 2 tool as a migration item. Ask the vendor for a supported replacement before the move, or budget for replacing the tool. |
| Platform release fit | Open edX supports only the latest named release, Verawood, and plans Willow for December 2026 (Open edX release notes). Moodle 5.3 is the next LTS release. | Test packages and tools on the release you will run. Frequent Open edX upgrades mean content and LTI tests recur, so plan them as part of the support scope. |
How Moodle and Open edX handle SCORM, xAPI and LTI
Moodle's SCORM module is the most direct path for an existing library. Moodle states that it passes the ADL conformance test suite 1.2.7 for SCORM 1.2, so packages built to that version are the lowest-risk content to carry over. Test them in a staging copy rather than assuming a clean run, because course-specific settings such as completion tracking, score passback and attempt limits are set per activity and do not always move with the package.
- Conformance baseline: Moodle passes the ADL 1.2.7 suite for SCORM 1.2, which gives a documented starting point for vendor and internal content.
- Completion and scoring: Confirm that completion and pass criteria written into each package map to the Moodle activity settings your reports depend on.
- Package inventory: Sort the library by SCORM version and by any authoring tool used, since older tool exports are the usual source of failures.
- Content hosting: Check whether packages call external servers, fonts or video hosts, because those calls affect both performance and air-gapped or EU data rules.
- Reporting history: Decide whether historical attempts must be imported or whether a dated cutover with archived reports is acceptable.
Ask the implementation partner for a test log per package showing launch, progress, score and completion records in the target environment.
SCORM 2004 is the area where Moodle needs the most planning. Moodle's own SCORM FAQ states that SCORM 2004 is not supported, apart from parts of the basic API. For full SCORM 2004 support, the FAQ points to a plugin from Rustici Software that connects to SCORM Cloud, which is a hosted service. Whether that connection is acceptable depends on where your learner data may go, so the choice is a governance decision as well as a technical one.
- Native gap: Moodle does not provide full SCORM 2004 support on its own, so 2004 packages cannot be assumed to behave as their authors intended.
- Rustici plugin route: The documented option is a Rustici Software plugin connected to SCORM Cloud, which introduces an external service into the learning flow.
- Data flow review: Confirm what learner and attempt data would leave your environment through that connection and whether your data protection terms allow it.
- Alternatives: Ask whether 2004 content can be republished as SCORM 1.2 or as xAPI, and whether the authoring vendor will provide that output.
- Plugin ownership: Confirm who will maintain, patch and test the plugin after go-live and how it is handled during Moodle upgrades.
Before committing, ask for a written list of 2004 packages, their features, and a test result for each on the chosen route.
Moodle handles xAPI (Tin Can) through third-party plugins rather than core features. Moodle's SCORM FAQ names two options: logstore xAPI, which sends logging data to an external learning record store, and mod_tincanlaunch, which launches Tin Can packages. AICC packages have been supported since Moodle 2.1. This split matters because a record store receives statements from both the LMS and the content, so you need to decide which source is authoritative for each completion.
- Outbound statements: logstore xAPI sends Moodle logging data to an external learning record store, which is useful for cross-platform reporting.
- Tin Can launch: mod_tincanlaunch launches Tin Can packages inside a course, so confirm that the package's statements reach the record store.
- Dual sources: Decide whether the LMS or the package is the system of record for completion, to avoid duplicate or conflicting records.
- AICC legacy: AICC packages are supported from Moodle 2.1, but confirm each package still launches on your current version.
- Store selection: The learning record store is a separate system to host, back up and secure, with its own access controls.
Ask for a sample statement set from each package type, showing what the record store received, before approving the reporting design.
Open edX takes a different approach to content. Studio is the authoring service and the LMS delivers courses to learners, and course content is built within the platform rather than imported as standard packages. The supplied facts do not confirm native SCORM or xAPI package support for Open edX, so treat any assumption about imported packages as an open question to test. Tutor, the Docker-based distribution, handles deployment, not content compatibility.
- Native support unconfirmed: The supplied facts do not confirm SCORM or xAPI package import in Open edX, so verify it against the current release before planning.
- Current release: Verawood is the current named release, and Open edX supports only the latest named release.
- Tracking pipeline: Aspects routes tracking logs through event-routing-backends as xAPI statements, stored in ClickHouse via Ralph or Vector and shown in Superset, which is a reporting path rather than a package player.
- LTI Advantage: Verawood adds LTI Advantage Complete certification, which is relevant to external tool launches.
- Rebuild effort: Packages that do not run may need conversion into Open edX course content, which should be scoped and priced as migration work.
Ask the partner to run your three most complex packages through a test course on the target release and report what works, what is rebuilt, and what cannot move.
Which LMS fits a SCORM and LTI-heavy library
Moodle and Open edX both handle SCORM, xAPI and LTI, but they do it through different routes and carry different upgrade and hosting obligations. Canvas LMS is a third option that needs to be checked against your specific content and tool list. Each card sets out the criteria to test against your library before you choose.
Moodle for broad SCORM and LTI support
Moodle is licensed under GPL-3.0 and is maintained by Moodle HQ, so you can self-host it or move to managed hosting later. Its SCORM 1.2 support passes the ADL conformance test suite 1.2.7, but SCORM 2004 needs a Rustici Software plugin connected to SCORM Cloud for full support. Check that every SCORM 2004 package in your library runs in that route, and confirm the plugin's licence and hosting terms before you rely on it.
Moodle xAPI through plugins
Moodle does not run xAPI natively. Teams usually add the logstore xAPI plugin to send logging data to an external learning record store, and mod_tincanlaunch to launch Tin Can packages. Test each plugin against your target learning record store and your Moodle version before migration, because the plugin owns the data path for training evidence.
Moodle LTI Advantage deployment
Moodle deploys an LTI Advantage tool by entering its registration URL, while legacy LTI 1.1 tools are registered with a cartridge. IMS Global has deprecated the LTI 2 specifications, so any tool still requiring LTI 2 needs a replacement plan. Inventory your tools by LTI version and confirm vendor support for Advantage before you commit to a library migration.
Open edX Verawood and LTI Advantage
Open edX is licensed under AGPL-3.0 and its current named release is Verawood, which added LTI Advantage Complete certification. Open edX supports only the latest named release at a time, so every upgrade becomes a platform event that your content and tools must survive. Confirm that each external tool in your stack is on the certified path before you choose Open edX for an LTI-heavy library.
Open edX Aspects for xAPI analytics
Open edX Aspects captures tracking logs through the event-routing-backends plugin as xAPI statements, stores them in ClickHouse through Ralph or Vector, and presents them in Superset dashboards. This suits teams that need learning analytics on their own infrastructure, but it adds components to size, secure and back up. Ask for the data flow and retention settings in writing before you assume the reports will answer audit questions.
Canvas LMS to confirm against the library
Canvas LMS by Instructure is licensed under AGPL-3.0, so it is worth evaluating alongside Moodle and Open edX. Confirm which SCORM and xAPI versions it supports, how it launches your existing packages, and which LTI Advantage tools your teams depend on. Treat it as an option to verify against your content inventory, not as a default choice.
What to test before moving a SCORM and xAPI library
Start with an inventory, because every package behaves according to its standard and version. List each SCORM package by version (1.2 or 2004), each xAPI or Tin Can package, and each AICC package, then record the authoring tool that produced it and whether it calls any external host. On Moodle, SCORM 1.2 is the well-supported path: the SCORM FAQ states that Moodle passes the ADL conformance test suite 1.2.7. SCORM 2004 is not supported beyond parts of the basic API, so any 2004 package needs a decision before the move: confirm whether the target platform setup (for example, a third-party plugin connected to an external service) meets your reporting needs, or rebuild the content. Confirm these details with your platform partner, because support depends on the plugin and version you deploy. Run each package in a test course on the target platform, not just a launch check. For every package, verify that a learner who completes it is marked complete, that the score lands in the gradebook with the same scale and passing threshold as before, and that suspend and resume work across a logout. Compare the results with the source system for a sample of learners. Then test the external calls: packages that load fonts, videos, analytics or scripts from outside your network can fail silently on a locked-down or air-gapped server, and a blocked call can break navigation or completion tracking. Log every outbound request the package makes and decide whether each one is acceptable. LTI and xAPI need their own checks. Re-register each LTI Advantage tool on the new platform by its registration URL, then confirm launch, grade passback and deep linking for each course that uses it. Legacy LTI 1.1 cartridges are a separate workstream: because IMS Global has deprecated LTI 2, plan to retire 1.1 cartridges on a schedule instead of copying them across unchanged. For xAPI, decide whether historical statements stay in the old learning record store, move to a new one, or are archived as exported files with a retention label. Confirm that the statement IDs and actor identifiers still match learners, since broken identifiers make old records unusable for audits.
How the content migration rollout runs in phases
The sequence moves an existing e-learning library and its tool connections onto a new LMS in controlled stages, so each course, launch path and completion record is tested before learners depend on it. Each phase closes with a document the buyer can review and sign off.
Inventory content and external tools
The team lists every SCORM, xAPI, AICC and LTI item in use, with its package version, authoring source, launch method, assigned audience and the system that receives its results. Owners of the content and the external tools confirm the list, and the output is a content and tool inventory with one row per package or tool and a named owner for each. The phase is complete when no course in the current LMS is missing from the inventory.
Build the standards test matrix
Each package is tested against the target platform's launch and reporting behavior, recording SCORM 1.2 and SCORM 2004 results, xAPI statement delivery to the learning record store, and LTI launch and grade return. For Moodle, SCORM 1.2 is supported and passes the ADL conformance test suite 1.2.7, while SCORM 2004 needs a plugin connected to an external service; for Open edX, the test checks how the chosen release handles each format. The output is a standards test matrix that shows pass, fail or workaround for every package, which the buyer can review line by line.
Decide the platform and plugin set
Based on the matrix, the team selects the LMS and the plugins that close the gaps, such as an xAPI logstore or a SCORM 2004 connector on Moodle, and confirms the version line. For Moodle, the target release sets prerequisites: Moodle 5.1 requires PHP 8.2 or later with PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, and sites must be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must run Moodle 4.4 or later. Each plugin is checked for maintenance status, license and compatibility. The output is a signed platform and plugin decision record.
Register LTI tools and set identity
Each LTI Advantage tool is deployed from its registration URL, and legacy LTI 1.1 tools are registered with their configuration, while LTI 2 is treated as deprecated. Single sign-on is configured with the identity provider, and the team confirms that launches carry the correct learner role and course context. The output is an LTI and identity register listing each tool, its keys or registration state, the claims it receives and a successful test launch for each role.
Migrate and test a pilot course
One representative course per content type is moved into a staging environment, with package files, launch settings and assignment rules copied across. Testers complete the course as learners and as managers, then compare the completion status, score and time recorded in the new system with the legacy record and the external learning record store. The output is a pilot report with each discrepancy logged, its cause and its fix, and a clear pass or fail for each content type.
Cut over and reconcile records
Content, enrollments and historical completion records are moved in a scheduled window, and the old system is set to read-only so no new attempts are split across platforms. Record counts, completion dates and scores are reconciled between the legacy source, the new LMS and the learning record store, with exceptions signed off by the records owner. The output is a reconciliation report showing matched totals, listed exceptions and the retention location for the legacy export.
Monitor launches after the move
For an agreed period set in the support plan, the team watches launch failures, xAPI delivery errors, LTI grade return, login problems and completion mismatches, and triages them against the standards matrix. Plugin and platform updates are tested in staging before production, and any change is recorded. The output is a post-move monitoring log and a closure memo confirming that the open items have owners and that the support handover is complete.
Evidence that proves completion and tool integrity
This table lists the records a training or compliance assessor is likely to request, the component that produces each one on Moodle or Open edX, and what to confirm before relying on it. Read each row as a question to answer during design, not as a guarantee that the evidence will satisfy any specific assessment. The main takeaway is that completion, conformance, statement retention and tool access come from different components, so each needs its own retention and export plan.
| Evidence item | Produced by | What to confirm before go-live |
|---|---|---|
| Completion and score per learner | Moodle gradebook and SCORM activity reports; Open edX LMS progress records | Which completion rule each package uses, and whether the export includes timestamps, attempts and scores in a format your assessor accepts |
| SCORM 1.2 conformance | Moodle passes the ADL conformance test suite 1.2.7 (per Moodle SCORM FAQ) | Your own conformance result for each vendor package, since Moodle's pass does not validate third-party content |
| SCORM 2004 runtime records | Rustici Software plugin connected to SCORM Cloud, per the Moodle SCORM FAQ | Whether the plugin, its SCORM Cloud dependency and its data location meet your hosting rules, and whether 2004 sequencing behaves as the packages expect |
| xAPI statement retention | logstore xAPI plugin sending statements to an external learning record store | Retention period in the LRS, backup of statements outside the LRS, and whether statements are signed, stored and queryable for the full audit window |
| Open edX event statements | Aspects event-routing-backends, stored in ClickHouse via Ralph or Vector and shown in Superset dashboards | Whether the Aspects stack is in scope for your deployment, how long ClickHouse data is kept, and who can query it |
| LTI registration records | Moodle External tools registration for LTI Advantage tools; Open edX LTI configuration | A written register of each tool, its issuer, client ID, deployment ID, owner and approval date, kept outside the LMS admin screens |
| External tool access logs | Web server and LMS logs for launches; tool-side logs held by the vendor | Which logs your team holds, which sit with the tool vendor, and how you obtain them on request during an assessment |
| Administrator and plugin change history | Moodle logs and plugin version records; change tickets in your own system | Whether changes to LTI tools, SCORM plugins and authentication settings are logged and tied to a named approver |
What buyers ask before moving SCORM and LTI content
Can SCORM 2004 packages run on Moodle without the Rustici plugin?
Not for full SCORM 2004 behavior. Moodle passes the ADL conformance test suite 1.2.7 for SCORM 1.2, but its own FAQ says SCORM 2004 is not supported apart from parts of the basic API. Full SCORM 2004 support comes through a Rustici Software plugin connected to SCORM Cloud. Before migration, run a sample of your packages on a test site and check sequencing, completion and score reporting, since packages that rely on navigation rules or multiple attempts behave differently. Confirm current plugin terms and any external service dependency with the plugin vendor, because that choice affects both the licensing and the data path.
What does a learning record store need to hold after the move?
A learning record store (LRS) holds xAPI statements, which record who did what in which content and when. Moodle reaches xAPI through third-party plugins: logstore xAPI sends logging data to an external LRS, and mod_tincanlaunch launches Tin Can packages. Your LRS must hold statements from the old system if you need a continuous history, so plan an export or a rule for keeping the old records queryable. Ask for a data map that lists each statement type, retention period and who can read it. Retention periods are set by your own policy and regulators, not by the platform.
Will our LTI 1.1 tools keep working on Moodle?
Moodle supports LTI Advantage tools by entering the tool's registration URL. Legacy LTI 1.1 tools are registered with a cartridge, which is a different path, so each tool needs a check. The IMS Global specifications for LTI 2 are deprecated, so any tool that depends on LTI 2 should be replaced or re-evaluated. Build an inventory of every external tool with its LTI version, launch settings, grade passback and roster use, then test each one against the target Moodle version. Ask the tool vendors whether they offer LTI Advantage, because that determines your long-term maintenance path.
How long does a content migration take, and what drives the effort?
The duration depends mostly on the number of packages, their SCORM version, how many external tools are involved and how much testing your content owners require. No duration is given here because the supplied facts do not provide one. A typical effort driver list includes package count, SCORM 2004 versus 1.2 share, custom JavaScript inside packages, video hosting, grade and completion rules, and whether historical completion records must move. Ask any implementation partner for a written scope that lists packages by type and a test plan for each category before agreeing to a timeline.
Can our internal team migrate SCORM content without outside help?
Often yes for a small library of SCORM 1.2 packages, if an administrator who knows Moodle can run course imports, check completion and manage plugins. The work grows when packages need SCORM 2004 behavior, xAPI statements go to an external LRS, LTI tools must be re-registered or Moodle must be upgraded across long-term support releases. Those tasks need skills in Moodle administration, web server configuration and integration testing. Assess the skills in your team against the list of requirements in your inventory, and decide which items to keep in house and which to scope to a partner.
What changes if we use SCORM Cloud or another external service?
An external service such as SCORM Cloud changes where the content runs, where learner data flows and who you depend on for availability. The Moodle FAQ points to a Rustici Software plugin connected to SCORM Cloud for SCORM 2004, so learner interaction data leaves your own infrastructure in that setup. Review the data processing terms, data location, subprocessors and exit options before approving it, especially in regulated sectors. If you need everything inside your own network, ask whether an alternative runtime or an offline option is available and test it with your packages.
How do we confirm a Moodle or Open edX version is still supported for our content?
Check the support window for the release you plan to run before you choose it. Moodle 5.3 was released on October 5, 2026, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, and it is the next long-term support release. Open edX supports only its latest named release, Verawood, published on July 30, 2026, so a platform on an older release will need an upgrade path. Plan content migration around the support window to avoid moving packages twice. Confirm the schedule on the Moodle releases page and the Open edX release notes.
Questions to ask an implementation partner before signing
Start with how the partner proves a SCORM package works before it is published. Ask whether they test SCORM 1.2 packages against the ADL conformance suite and what they do for SCORM 2004, because Moodle's own documentation says SCORM 2004 is not supported apart from parts of the basic API and points to a third-party plugin connected to SCORM Cloud for full support. Ask which plugin they would install, who licenses it, and whether they run each package in a staging course with a test learner and a reset of the tracking data. Also ask who owns the cmi data model mapping when a course reports scores or suspend data differently from what the gradebook expects.
Next, pin down the xAPI and LTI design. Ask which learning record store they connect to, how the logstore xAPI plugin or the mod_tincanlaunch plugin is versioned, and whether statements are sent to the LRS with a tested retry path when the LRS is unavailable. For LTI Advantage, ask how each tool is registered from its registration URL, who holds the platform client ID and deployment ID, and how keys are rotated. For legacy LTI 1.1 tools, ask for the inventory of cartridges still in use, the date each one will be disabled, and how learners and instructors are told which courses lose a tool. Confirm the retirement plan in writing.
Finally, settle records and upgrades. Ask how completion records are reconciled after cutover: which source is authoritative, how a sample of learners is compared between the old and new systems, and who signs off on the variance. Ask who owns plugin compatibility across each Moodle long-term support cycle, who checks the plugins against the next release before the upgrade window, and what happens if a plugin is abandoned. Confirm that the partner's support scope covers both the content library and the plugins, and that any retainer terms state response expectations in writing.
How DeployOpen scopes and supports SCORM, xAPI and LTI work
The sequence turns an existing e-learning library and a list of external tools into a written scope, a tested Moodle or Open edX setup, and a handover your team can run. Each step ends with a named output so you can check progress before the next one starts.
Agree a written scope before any work starts
DeployOpen and your team agree the scope in writing: which platform (Moodle or Open edX), which content standards, which external tools, which identity provider and which hosting environment. Deliverables, exclusions and the acceptance criteria are recorded in the same document, and no build work begins until both sides sign it. The output is a scope document that names every content package and tool in the first release.
Inventory the content library and tool estate
DeployOpen reviews every SCORM package, xAPI activity, AICC package and LTI tool your teams rely on, recording the SCORM version each package declares, how it reports completion and score, whether it calls external servers, and which LMS features it depends on. Your team confirms which packages are still in use and who owns each one. The output is a content inventory with a standard, launch method and owner for each item.
Build a test matrix for each standard and tool
From the inventory, DeployOpen builds a test matrix that pairs each content type with the platform feature it needs, such as SCORM 1.2 tracking, SCORM 2004 sequencing, xAPI statement delivery to a learning record store, or LTI Advantage launch and grade return. Packages that need capabilities the chosen platform handles through a plugin or a third-party service are flagged for a decision. The output is an approved test matrix with a pass or fail rule for each row.
Configure content support, plugins and tool connections
DeployOpen installs and configures the content handling for each standard in the matrix, such as the SCORM support in Moodle core, third-party plugins for xAPI and Tin Can packages, or the SCORM and xAPI route in Open edX, and registers each LTI tool using the method the platform supports. Plugins and tools are pinned to versions that match the platform release, and any gap that needs custom code is written into the scope before it is built. The output is a configured staging environment with a change record for every plugin and tool.
Test every package and tool against the matrix
DeployOpen runs each content package and tool through the test matrix on staging, checking launch, completion status, scores, bookmarks, and the data that arrives in the learning record store or gradebook. Failures are logged with the package, standard and platform version involved, and are fixed or escalated through the scope change process. Your subject matter experts confirm that the learner experience matches the course design. The output is a signed test report showing the result for each row.
Migrate content and verify learner records
DeployOpen moves approved packages into the production environment, imports enrollments and existing completion records where the source allows it, and checks a sample of learners against the source data. Records that cannot be migrated are listed with the reason and a proposed procedure for keeping the original evidence available. The output is a reconciliation report showing which packages and records moved, and which were retained separately.
Hand over documentation and run the operating model
DeployOpen delivers runbooks covering how each standard is launched, how plugins and tools are updated, how to add a package or tool, how to troubleshoot a failed launch, and how upgrades to the platform's supported release are planned. Your administrators are trained on these procedures and sign off on them. The output is a handover pack and a recorded walkthrough that your team can use without DeployOpen present.
Decide on retainers for upgrades and testing
Because Moodle and Open edX move through supported releases on fixed schedules, DeployOpen and your team decide whether ongoing support, upgrades and continuous testing should run under a retainer. The retainer scope sets which releases are covered, how the test matrix is re-run after each upgrade, and who responds to failures. DeployOpen prepares compliance evidence, such as configuration records and completion reports, but does not issue audit reports or certifications; independent auditors and certification bodies do. The output is a retainer scope or a documented decision to run without one.
