How to migrate from Cornerstone to Moodle without losing training records
Packages and content reload, but transcripts, certification history, recertification rules and HRIS feeds have to be exported and rebuilt. A compliance or L&D team weighing a Cornerstone renewal, or a data residency requirement, against self-hosted Moodle should treat the content library and the records as two separate workstreams. SCORM, AICC and xAPI packages from authoring tools can generally be uploaded again to Moodle, since both platforms run these standards. Completion history, certification expiry dates and the user records behind them do not travel with the package and must be pulled out of Cornerstone through its Data Exporter API and mapped into Moodle. Usually an internal platform team owns the decisions (which record types are regulated, who signs off on retention, which HRIS field is the system of record), and an implementation partner or a Moodle-experienced engineer handles the extraction scripts, the Moodle plugin work and the test loads. Confirm with your Cornerstone administrator which OData skills and reporting access the export account has before you schedule any work.
Effort and risk concentrate in three places: recertification logic, identity and HRIS sync, and record integrity. Moodle's completion and certificate features can model renewal periods, but you will need to recreate each rule for each course family and test it against sample learners whose due dates you already know. Check how the /public document root is configured on the new server, since a misconfigured web root will expose the wrong files or fail to load the site. For sign-in and HRIS feeds, Moodle core includes LDAP, OAuth 2, LTI and web services authentication, and a SAML2 plugin is available from the Moodle marketplace; decide which user provisioning path your HR system will drive and run a reconciliation of active users before cutover.
Cornerstone's attestations do not transfer. Its ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate statements describe Cornerstone's own service, and a self-hosted Moodle carries none of them. Your organization must provide the equivalent controls, evidence and independent audits for the environment it runs, and auditors will ask for them under your own scope. Ask your assessor early which evidence they will accept for access control, backup, change management and retention of completion records, and plan a parallel-run period in which both systems hold the same learners before Cornerstone is switched off.
Which Cornerstone capabilities map to Moodle, and which need rework
This table compares the main Cornerstone training capabilities with what Moodle core and plugins provide, and labels each row clean, needs rework or gap. Read the status column as a planning signal: clean rows can usually move with configuration, rework rows need build effort, and gap rows need a plugin decision or a process change before cutover.
| Capability | Moodle position | Status |
|---|---|---|
| SCORM, AICC and xAPI content hosting | Moodle hosts standard packages for SCORM and xAPI content; reload original authoring-tool ZIPs and test each package in the target version | Clean |
| Completion and pass status for packages | Completion is recorded per learner and activity; confirm that imported historical completion dates can be written back, since learner records must be migrated separately | Needs rework |
| Certification and renewal rules | Moodle has no native equivalent of Cornerstone's certification expiry and recurring assignment logic; rebuild with completion conditions, cohorts and a plugin, and confirm plugin support for your workflow | Needs rework |
| Transcript and certification history | Historical records come from the Cornerstone Data Exporter API output and must be loaded into Moodle reporting or an external archive; no automatic import is assumed | Needs rework |
| Compliance reporting and dashboards | Standard course and activity reports cover many needs; audit-style reports for recertification due dates usually require custom reports or a reporting plugin | Needs rework |
| HRIS-driven enrollment and user feeds | Moodle supports user and enrolment sync through its web services and external database options; the HRIS feed must be rebuilt and tested against your source data | Needs rework |
| Single sign-on | Core ships LDAP, LTI, OAuth 2, Shibboleth and web services authentication; SAML2 is available as a marketplace plugin, so confirm it meets your identity provider requirements | Clean |
| Third-party content libraries such as LinkedIn Learning or Coursera | Cornerstone's native library integrations do not carry over; Moodle connects to external content through LTI or package import, and each licence must be confirmed separately | Gap |
| Attestations and certified controls | Cornerstone holds ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization for its cloud service; a self-hosted Moodle does not inherit these and the organization must produce its own evidence | Gap |
What data to export from Cornerstone and what to rebuild in Moodle
Cornerstone holds training records in several places, and Moodle needs each one rebuilt or reloaded differently. The cards below separate what you export from Cornerstone, what you reload as course content, and what you configure again in Moodle so compliance training keeps its deadlines and evidence.
Transcripts through the Data Exporter API
The documented export path for Cornerstone data runs through the Data Exporter API over the Real-time Data Warehouse. Confirm with Cornerstone which transcript fields, course identifiers and completion dates the API returns for your tenant, because your import into Moodle depends on those exact keys. Ask for a sample export for one completed compliance course and check that the learner identifiers match the ones your directory uses.
OData skills the export team needs
The export depends on writing OData queries against the warehouse, so the team needs someone who can filter by date, join learner and course tables and page through large result sets. Confirm whether your Cornerstone administrator or a partner holds that skill today. Budget for this as an internal or contracted task, because a query that misses a join will silently drop learners from the transcript history.
Certification history and expiry dates
Certification records are the evidence auditors ask for, so export the award date, expiry date, issuing course and the version of the course that granted the credential. Moodle does not infer these from completion data alone. Map each certification to a Moodle course completion or custom certificate and decide whether historical expiry dates are imported as fixed values or recalculated from the original award.
SCORM, AICC and xAPI packages
Standard SCORM, AICC and xAPI packages from authoring tools can usually be reloaded into Moodle without rebuilding the content itself. Collect the original package files from your authoring tool or content owners, not from Cornerstone's player, and confirm each package's version. Completion history and learner records do not travel with the package, so migrate them separately as described in the transcript card.
Recertification rules rebuilt in Moodle
Cornerstone recertification schedules, due-date windows and reminder rules must be written again as Moodle course completion conditions, enrolment rules or plugin-based automation. Document each rule as a test case with an expected due date for a sample learner. Check how your current rules handle a learner who changes role or department mid-cycle, because that case is where manual rebuilds most often diverge from the original.
HRIS user feeds and SSO
Moodle needs its user accounts, cohorts and role assignments fed from your HRIS, not typed in by hand. Core authentication plugins include LDAP, external database, OAuth 2 and Shibboleth, and the SAML2 plugin is available from the Moodle marketplace for SSO. Confirm which identity source is authoritative, how leavers are deactivated, and whether learner records for former employees must be retained after deprovisioning.
The migration sequence from inventory to Cornerstone decommission
This sequence moves compliance training from Cornerstone to Moodle in controlled stages, so each step produces a verified record before the next one depends on it. The end state is a Cornerstone environment retired only after its records are retained and reconciled.
Inventory courses, certifications and recertification rules
Export the course catalog, assignment rules, certification definitions and recertification cycles from Cornerstone, then list every compliance program that depends on them. Record which content packages are SCORM, AICC or xAPI, which are third-party library items, and which rules trigger renewals automatically. The team that owns compliance reporting should sign off on the list. Done means every active program maps to a named course set, a renewal interval and an owner in a single inventory document.
Confirm content packages reload into Moodle
Pull the original SCORM, AICC and xAPI packages from the authoring tools or content repository, since Cornerstone exports do not replace the source files. Upload a sample of each package type to a non-production Moodle instance and test launch, completion and score reporting. Note any third-party library items that need a license or a replacement source, because those cannot be reloaded from your own files. Done means each package type has a documented pass or fail result and a list of items needing a new source.
Pilot one compliance program end to end
Choose one compliance program with a bounded learner group and a clear recertification cycle. Rebuild its courses, enrollment rules and recertification logic in Moodle, then run learners through it while keeping Cornerstone as the system of record. Compare Moodle completion and expiry dates with Cornerstone for the same learners. Done means a reconciled pilot transcript set exists, every difference has a recorded cause, and compliance leads have accepted the results in writing.
Run both systems in parallel
For the remaining programs, let learners complete training in whichever system the cutover calendar assigns, while both platforms record completions. Compare completion, certification and expiry records each reporting period and investigate mismatches in the HRIS feed, enrollment rules or package scoring. Done means reconciliation reports show no unexplained differences for a full cycle, and each exception has an owner and a fix.
Cut over enrollment and HRIS feeds
Switch the user provisioning and enrollment feeds from the HRIS to Moodle, starting with the authentication method your identity setup supports, such as LDAP, LTI, OAuth 2 or SAML2 through a plugin. Confirm that new hires, role changes and leavers update in Moodle as they do in Cornerstone, then disable the Cornerstone feed. Done means a signed cutover checklist covers feed ownership, rollback steps, the final enrollment set and the named approvers.
Decommission Cornerstone with retained records
Before the Cornerstone subscription ends, export final transcripts, certification history and user data, and store them in an archive your records policy and legal team approve. Confirm the retention period and access requirements with your compliance and legal owners, since the archive must remain available for audit requests. Done means the archive has been verified by a test restore or sample lookup, the decommission checklist is signed, and the owner has confirmed no active programs still point to Cornerstone.
How the move differs for regulated, government and multi-country teams
A regulated enterprise moving compliance training from Cornerstone usually has the heaviest evidence burden. Cornerstone describes its platform as holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization, so some of the assurance your auditors have relied on sits with that vendor. Once training runs on Moodle in your own infrastructure, those controls become yours to operate, document and show to an independent auditor. DeployOpen prepares systems, controls and evidence for assessments, but audit reports and attestations come from independent auditors and certification bodies.
- Control ownership: Map each training control you relied on from Cornerstone to a named owner, hosting process or Moodle configuration in your environment.
- Completion evidence: Confirm that transcripts, certification dates and recertification history export with timestamps and learner identifiers your auditors accept.
- Access reviews: Set up role-based access and periodic review of course managers, graders and report viewers in Moodle.
- Change control: Plan Moodle upgrades around the release schedule, since each major release has a defined support window and PHP and database requirements.
- Records retention: Agree retention periods for completion records with legal and compliance before the cutover.
Before committing, ask your compliance lead which Cornerstone attestations are cited in your own assessments and what replacement evidence they will accept.
A public sector team that relies on Cornerstone's FedRAMP Moderate authorization must keep the same level of control inside its own authorized environment. The move is not a like-for-like swap of a cloud service. The agency becomes responsible for the hosting boundary, the authorization package for that boundary and the operating controls that Cornerstone previously carried. The detailed treatment of FedRAMP-style authorization, records retention and control inheritance sits on the sibling page for government agencies.
- Authorized boundary: Confirm which environment will host Moodle and whether it already holds the authorization your agency requires.
- Inherited versus owned controls: Separate controls the hosting provider covers from those your team must implement and evidence.
- Data location: Document where learner records, transcripts and backups are stored and who can access them.
- Authentication: Use your agency identity provider through the SAML2 Single sign on plugin or another supported method, and check it against your policy.
- Records and retention: Confirm how long training records must be kept and how they are disposed of.
Ask your authorizing official or security office which controls they will expect the agency to own before you set a migration date.
A global team moving from Cornerstone usually faces many languages, several HRIS sources and different employment entities, each with its own user population and records rules. Cornerstone's integrations with third-party content libraries are not something Moodle replicates out of the box, so the content and user feed work is larger than the course reload alone. Moodle core ships authentication options including LDAP, external database, OAuth 2 and web services, which give you several ways to feed users in from more than one HRIS, but the mapping rules are your responsibility.
- Language packs and translations: Inventory which courses exist in which languages and whether translations were separate packages or in-course content.
- Multiple HRIS sources: Decide which system is the source of truth for each population, and how conflicts are resolved when two sources disagree.
- Identity mapping: Standardize user identifiers across regions so the same person is not created twice.
- Recertification rules by region: Rebuild regional due dates and renewal rules separately, since they often differ by country.
- Data transfer rules: Check cross-border transfer requirements for learner data before you replicate it to a shared Moodle instance.
Illustrative example: a team with three HRIS systems might run an interim feed for one region while the others are migrated in waves. Confirm the feed design with your HR and privacy teams first.
What drives the cost and duration of the Moodle migration
This table lists the factors that change the effort and cost of moving Cornerstone training to self-hosted Moodle, with the reason each one matters and how to keep it down. Read it before requesting a quote, because the same driver can add work in one row and reduce it in another. The main takeaway is that most of the cost sits in data mapping, recertification rules and evidence you must produce yourself, not in the Moodle software itself.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Active courses and SCORM, AICC and xAPI packages | Each package must be tested in Moodle, and content with dependencies on Cornerstone-specific launch or tracking behavior may need rework or re-authoring. | Retire stale courses before migration, confirm which packages are current with content owners, and archive the rest. |
| Volume and age of transcript and certification history | Historical completions, scores and certificate records must be exported, mapped to Moodle data and checked for gaps, which grows with the number of years kept. | Agree a retention cut-off with legal and records owners, archive older history in read-only form, and migrate only records you must keep active. |
| Number of recertification rules | Each renewal period, expiry trigger and due-date rule must be rebuilt and tested, since Moodle does not carry Cornerstone rule logic over automatically. | Inventory rules by compliance program, merge duplicates, and remove rules tied to courses that have been retired. |
| Number of HRIS sources and user feeds | Each source needs its own field mapping, matching keys, update schedule and error handling for joiners, movers and leavers. | Reduce the number of authoritative sources to one where possible and document one field dictionary before building feeds. |
| Integrations with third-party content libraries | Libraries such as LinkedIn Learning, Coursera or Skillsoft that Cornerstone connects to need new connections, licensing checks and reporting paths in Moodle. | List which libraries are used by which audiences, and drop those with low usage before rebuilding the connection. |
| SSO and authentication complexity | Moodle core provides several authentication options, but mapping your identity provider, group claims and role assignments to Moodle roles takes testing with real accounts. The SAML2 plugin is a separate plugin to evaluate. | Confirm the identity protocol your provider supports, define role mapping in writing, and test with a small pilot group first. |
| Controls and evidence the organization must produce itself | Cornerstone holds ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization for its platform. In a self-hosted Moodle, backup, access reviews, change management and log retention become your responsibility and must be evidenced to auditors, who are independent of DeployOpen. | Ask your auditor which evidence they will request, map each to an owner, and decide early which controls the hosting environment already provides. |
| Recurring hosting, upgrades and support | Moodle is free software, but hosting, database operations, Moodle major and point releases, PHP and database version upgrades and plugin updates recur for the life of the system. Moodle 5.1 also requires the web server root to change to the /public directory. | Plan a fixed upgrade cadence, choose an LTS release where your policy requires it, and agree who performs and who tests each upgrade. |
| One-time migration and build work | Scope covers export, content load, rule rebuild, feed build, testing, cutover and training for administrators and content owners. Each is priced by the written scope, not by Moodle licensing. | Ask for a fixed scope listing each deliverable, the source data assumed, and what is excluded, so the quote can be compared line by line. |
What usually goes wrong when moving compliance training to Moodle
Compliance training migrations rarely fail on content. They fail on the records and rules around the content: completion history, recertification dates, user identity and the server configuration that Moodle expects. Each card below names one risk, why it matters for a Cornerstone exit, and the check to run before go-live.
Completion history left behind
Reloading SCORM, AICC or xAPI packages gives you the course content, but not the learner's past attempts, scores or completion dates. Those live in Cornerstone's transcript records and must come out through the Data Exporter API output and be loaded as historical records in Moodle. Before cutover, pick a sample of learners with multi-year certification histories and confirm that each completion date and score appears in Moodle exactly as it did in Cornerstone. Reloaded packages alone will show learners as untrained.
Recertification dates shifting
Recertification windows are often calculated from a completion date, a rolling expiry or a due date set by policy. If Moodle recalculates these from the import date rather than the original completion date, learners appear to owe training they already finished, or lose time they had left. Export the expiry date for every active certification, rebuild each recertification rule in Moodle, and compare the computed due dates with the Cornerstone values for a sample of each rule type before any learner receives a reminder.
Duplicate or missing HRIS users
Moodle identifies users by username, email or an external identifier, and a feed from your HRIS can create a second account for someone whose record changed in the middle of the migration. Completions then split across two profiles, and some learners are missing from assignments entirely. Decide which field is the stable key before the first load, match Cornerstone user IDs to Moodle accounts in a staging run, and reconcile counts of active, leaver and transferred users against the HRIS source of truth.
SCORM behaving differently in Moodle
Packages that passed in Cornerstone can report different completion or score values in Moodle because of how each LMS reads the SCORM runtime, handles suspend data, or applies pass thresholds. Some xAPI statements also depend on the LRS that Cornerstone provided. Test every high-stakes course end to end in Moodle with a learner account, including bookmarking, retakes and a failed attempt, and confirm the completion status written to the gradebook matches the policy text. Ask the content owner to confirm the expected behavior before signing off.
Document root set to the wrong folder
From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder. If the web server still serves the old root, learners and administrators may see directory listings or errors instead of the login page, and an outage can look like a content problem. Set the document root during server build, confirm the site loads through the production hostname and the reverse proxy, and include this check in the cutover runbook. Confirm the PHP and database versions for your chosen release at the same time.
What the organization must own once Cornerstone's attestations are gone
The central change in this migration is that the organization, not a vendor, becomes responsible for the controls behind training records. Cornerstone describes its learning platform as a cloud application holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization, according to its learning platform page. Those attestations cover Cornerstone's environment. Once training runs on a self-hosted Moodle, the equivalent hosting controls, patching, backups, access reviews and log retention are yours to design, operate and evidence. Before cutover, ask your compliance lead to map each control the current assessment relies on to a named owner in your team, and to confirm which of those controls, if any, are inherited from Cornerstone's attestations rather than from your own environment.
Start with the Moodle-specific items. Moodle 5.1 requires the web server document root to point to the /public directory, not the main Moodle folder, so a misconfigured server can expose directory listings or errors. Database and PHP versions are fixed by the release you choose (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). Your team must also own the upgrade cadence: Moodle ships minor point releases every two months and the security support windows differ between releases, so write down which version you will run and who applies security fixes. Access reviews should cover Moodle administrator and course manager roles, the authentication plugins you enable, and any service accounts used by the HRIS feed.
DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the scope of their assessment should be agreed with them before the migration starts, since they will decide whether your Moodle environment, its hosting provider and its backups fall within scope. Ask your auditor which evidence formats they accept for training completion, certification and retention records, and whether the migrated history from the Cornerstone export is acceptable as the source of record for the transition period.
Questions buyers ask before moving from Cornerstone to Moodle
What drives the cost of moving from Cornerstone to Moodle?
The cost depends on how much training content, history and integration work sits behind the move. Cornerstone is paid as a subscription, while self-hosted Moodle replaces that with infrastructure, database and PHP operations, staff time, and any migration and integration work you buy. The main drivers are the number of SCORM, AICC and xAPI packages to reload, how many years of transcripts and certification history must be exported, how many HRIS feeds and recertification rules must be rebuilt, and whether Moodle plugins are needed. Ask any quote to itemize one-time migration work separately from recurring hosting, support and upgrade effort, and to state which content library licenses you will still pay for elsewhere.
How long does a Cornerstone to Moodle migration take?
The duration depends on scope, not on a fixed number. A move with a small content set, one HRIS feed and simple recertification rules is far shorter than a move covering many compliance programs, multiple regions and years of certification records. Before accepting any timeline, confirm which items are in scope: content reloads, transcript export, certification rules, user feeds, parallel running and cutover. Ask for the schedule to be tied to written deliverables, and ask what your own team must provide and approve at each stage.
What does my team need to provide for the migration?
Your team needs to supply the people and access that only your organization holds. Expect to name a training owner who can approve compliance rules, a HRIS owner who can describe and test user feeds, a Cornerstone administrator with rights to run the Data Exporter API output, and a security or compliance lead who signs off on where records will live. You will also need the original SCORM, AICC and xAPI packages from authoring teams, plus a list of mandatory courses and their renewal periods. Confirm these responsibilities in the written scope before work begins.
Can we migrate from Cornerstone to Moodle ourselves?
Yes, a capable internal team can move content and run Moodle, but the risky parts are the certification and recertification logic and the user feeds. Standard packages usually reload with little change, while completion history, renewal dates and HRIS-driven enrollments need careful mapping and testing against your existing records. Decide which parts your staff will own, such as day-to-day administration after go-live, and which you will hand to a specialist, such as the export mapping and the cutover checks. A DeployOpen engagement is fixed-scope, so the split of work is agreed in writing before it starts.
Do SCORM and xAPI packages reload into Moodle?
Standard SCORM and xAPI packages generally reload into Moodle, but the packages and the learner records are separate problems. The course files carry over when they follow the standard formats that Cornerstone supports for internally built content, which include SCORM, AICC and xAPI. Completion history, scores and attempts do not come with the package and must be exported and mapped separately. Test a sample of each package type in a staging Moodle site, check launch, tracking and completion, and confirm any content that depends on a Cornerstone-specific feature or a third-party library integration such as LinkedIn Learning, Coursera or Skillsoft.
Will Cornerstone certifications and renewal dates carry over?
Certification records do not move automatically, so you must rebuild them as data and rules in Moodle. Export transcripts and certification history from Cornerstone, map each credential to a Moodle completion or badge rule, and recreate the renewal intervals, due-date logic and reminders that drive recertification. Validate the result against a sample of real learner records before cutover, and keep the exported Cornerstone records as your evidence archive. Whether those records meet a specific regulatory or audit requirement is a question for your compliance function and any external auditor, not something the migration can certify.
How do we run Cornerstone and Moodle in parallel during cutover?
Run both systems for a defined period with a clear rule for where each new enrollment and completion is recorded. A common approach is to freeze new Cornerstone assignments for a single program, deliver it from Moodle, and reconcile completions back to the archive before moving the next program. Keep HRIS feeds pointed at one system at a time to avoid duplicate enrollments, and agree who resolves mismatches. Confirm the parallel period, the reconciliation checks and the rollback path in the written scope, since these are the points where compliance records are most likely to diverge.
Which Moodle version and server requirements should we plan for?
Plan for the version your upgrade path and support window need, and confirm server versions before procurement. Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Sites must be on Moodle 4.2.3 or later to upgrade to it, and from 5.1 the web server document root must point to the new /public directory. Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must run Moodle 4.4 or later to upgrade. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next LTS per the Moodle releases page. Confirm the choice with your platform team against the release notes.
What does a fixed-scope DeployOpen engagement cover?
A fixed-scope engagement covers the items written into the agreed scope, which for this migration typically means planning the target Moodle environment, implementing and hardening it in your own infrastructure, mapping and reloading content, designing the transcript and certification migration, rebuilding user feeds and recertification rules, testing, documenting and supporting cutover. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside your cloud accounts, data centers or air-gapped networks. DeployOpen does not issue audit reports or certifications, so any evidence it prepares is for your independent auditors to assess. Ongoing upgrades and support are available as retainers. There is no published price list, and a quote follows from the written scope.
How DeployOpen scopes, runs and supports a Cornerstone to Moodle migration
DeployOpen plans and implements self-hosted Moodle inside your own cloud accounts, data centers or air-gapped network, with the integrations and data handling that a compliance training move needs. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the courses, SCORM, AICC and xAPI packages, and recertification rules that compliance training depends on.
- Map HRIS user feeds, single sign-on and certification history to specific Moodle plugins and data sources.
- Agree in writing which transcript, certification and audit evidence fields move, and which stay in Cornerstone's records.
How we build
- Install Moodle in your environment on a supported PHP and database combination, with the web root set to the /public directory.
- Reload packages from your authoring tools, then test launch, completion and score reporting for each content type.
- Rebuild recertification rules and user feeds, and test them against a sample of real user records in a staging copy.
How we hand over
- Document the configuration, data export and import steps, and the rules behind each recertification workflow.
- Provide backup and restore procedures and an upgrade plan that follows Moodle's published support windows.
- Walk your administrators through daily operation, plugin management and the evidence your auditors will ask for.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete.
- Prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any reports.
- Confirm with your own team which controls, such as access reviews and retention, remain your responsibility after go-live.
