Cornerstone vs Moodle: which to choose

When Cornerstone or self-hosted Moodle is the right fit for your training program

Choose Cornerstone when your priority is a managed talent suite that already carries the assurance paperwork your auditors ask for. 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. That matters most when a renewal lands on a team with no spare security or compliance staff, or when training sits alongside talent and performance processes you do not want to rebuild. You keep paying a subscription, and the content library licenses and integration work recur with it.

Choose self-hosted Moodle when you want GPL-3.0 software, control over where training records live, and the ability to run the platform inside your own cloud account or data center. Moodle is only cheaper or more controllable if your team can take on the work: patching to each release, meeting the server requirements for the version you run, managing backups, and producing the access reviews and change records that an assessor will request. Moodle 5.1 also requires the web server document root to point to the new /public directory, a small detail that shows how much operational attention a self-hosted install needs. Confirm your staffing before you commit.

The decision turns on three questions. First, how complex are your certification and recertification rules, and can they be expressed as course completions with expiry dates in Moodle or do they depend on workflows Cornerstone provides? Second, which integrations are non-negotiable, including your HRIS user feeds and any third-party content libraries you already license. Third, who will run and evidence the platform after go-live. Write those answers down, then compare them against the sibling pages on migration and cost before you request a quote.

Which platform fits which training scenario

This table matches common Cornerstone replacement scenarios to the platform that usually fits best, based on hosting model, attestations and operating effort. Read each row as a starting point, then confirm the points marked in the cell against your own environment and your auditor's expectations.

Scenario	Better fit	Reason
Regulated bank that needs recertification tracking and audit evidence	Cornerstone, unless you can staff the controls	Cornerstone describes ISO/IEC 27001 and SOC 2 Type II coverage for its platform. A self-hosted Moodle moves those control operations, evidence and recertification rule testing to your team.
Public agency that must run training in an authorized environment	Moodle in an authorized agency environment, if the agency can accredit it	Cornerstone describes FedRAMP Moderate authorization for its cloud service. Moodle authorization depends on where and how the agency hosts it, so confirm the authorization path before choosing.
Small HR team that wants less operational work	Cornerstone, or a managed Moodle provider	Self-hosted Moodle adds patching, PHP and database upgrades, backups and plugin maintenance. A managed option reduces that load, but still requires you to manage content and records.
Organization that must keep training data on its own servers	Self-hosted Moodle	Moodle is GPL-3.0 and can run on infrastructure you control, so learner records, completions and uploaded content stay in your environment.
Company with a mixed content library of SCORM, AICC and xAPI packages	Moodle, after testing package behavior	Cornerstone integrates third-party libraries such as LinkedIn Learning and Coursera. Moodle reloads standard packages, but you must confirm each third-party library's license terms.
Team planning for Moodle major release upgrades	Moodle, on a planned upgrade cycle	Moodle 5.1 requires PHP 8.2 or later and sites must be on Moodle 4.2.3 or later to upgrade. Plan a supported LTS line and test each upgrade against your plugins.
Organization that relies on Cornerstone's talent suite beyond learning	Cornerstone, or plan a separate system	Moodle covers learning delivery and reporting. Talent management, succession and broader HR workflows will need a different platform or custom integration.

What hosting control and attestations change for a regulated training program

Moving from Cornerstone to Moodle changes who hosts the training records, who holds the security attestations and who produces the evidence auditors ask for. The cards below separate what Cornerstone supplies today from what your team would operate, document and defend. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports and certifications.

Data location and residency

Cornerstone runs its learning platform as a cloud application, so the provider chooses where training records and learner data are stored and processed, and your contract and data processing terms define what you can rely on. With Moodle, the database, file storage and backups sit wherever you deploy them, whether in your own data center, your cloud account or a managed partner environment. Confirm in writing where each copy of learner data lives, including backups, logs and any third-party content services that receive learner identifiers.

Hosting model and ownership

Cornerstone is a cloud application that you consume. Moodle can be downloaded and self-hosted by your team, or run through MoodleCloud or a Moodle Partner, and each option moves a different share of patching, scaling and availability work onto your staff or the provider. Choosing self-hosting makes your team the operator of the web server, PHP runtime, database and upgrade path. Choosing a partner keeps the platform in your control only if the contract names the hosting location and the operating responsibilities.

Attestations Cornerstone holds

Cornerstone describes its learning platform as holding ISO/IEC 27001 certification, SOC 2 Type II reporting and FedRAMP Moderate authorization. These reports cover the provider's controls and reduce the evidence you must gather for the parts of the stack it runs. Request the current certificates and reports under nondisclosure, check their scope and dates, and confirm which Cornerstone modules and regions they cover before assuming they extend to your training program.

Controls you must operate and evidence

With Moodle, no third-party attestation covers the platform for you. Your organization becomes responsible for access reviews, change management, vulnerability patching, backup restore tests, logging and incident response for the Moodle stack. Map each control your auditor expects to a named owner, a procedure and a recurring record. DeployOpen can prepare these systems, controls and evidence for an assessment, but an independent auditor or certification body must issue any report or certification.

Identity integration and access control

Training access usually follows the workforce directory, so sign-in and role assignment decide who can take mandatory courses and who can view completion records. Moodle core includes LDAP, LTI, OAuth 2 and Shibboleth authentication plugins, and a SAML2 single sign-on plugin is available from the Moodle marketplace. Confirm that your identity provider, group mapping and deprovisioning process match what Cornerstone does today, and test that a leaver loses access to learner records as well as courses.

Compliance readiness you must prepare

Regulated training programs need evidence that the right people completed the right content on time, and that records were not altered. Before replacing Cornerstone, define the retention period, the audit trail expectations and the sign-off process for each training program, then test them on Moodle with sample records. Ask your compliance lead which regulations, internal policies and customer contracts apply, because those requirements decide whether a self-hosted Moodle can meet them without additional controls.

How Moodle release cycles and server requirements shape operating effort

Moodle's release cadence is the main recurring operating task, and it is set by the project, not by your change calendar. Moodle ships major releases every six months, in April and October, and minor point releases every two months in February, April, June, August, October and December. Each point release can carry security fixes, so the team that runs a self-hosted Moodle needs a standing process to test, stage and deploy them. The Moodle releases page lists the current support windows, and that page is the first place to check before planning a year of maintenance. The choice of branch decides how often you must take a major upgrade. Moodle 4.5 is a long-term support release from 7 October 2024 with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next LTS, with general support until 4 October 2027 and security support until 1 October 2029. An organization that stays on an LTS branch takes fewer major upgrades, but it still has to move off a branch when its security support ends. Confirm which branch your compliance program accepts before you commit, because an unsupported branch can fail an assessment even if the site still runs.

Server requirements change between majors and set the platform budget. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported, and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Each runtime bump is a patch, test and rebuild cycle for the web, PHP and database tiers. From Moodle 5.1, the web server document root must point to the public directory rather than the main Moodle folder, or the site can expose directory listings or show errors. Update the virtual host configuration as part of every upgrade plan, and check it in a staging environment first. Upgrade paths also have floors. Sites must be on Moodle 4.2.3 or later to upgrade to 5.1, and on Moodle 4.4 or later to upgrade to 5.3, so an older site may need intermediate upgrades before the target version. Ask your team to record the current version, PHP and database versions, and any custom plugins in an inventory, and to confirm each plugin supports the target release. Budget for this as recurring labor: patch review, staging tests, plugin compatibility checks and rollback rehearsals. Whether an external partner or in-house staff does this work, the decision should rest on that inventory and a written upgrade calendar.

Questions buyers ask before replacing Cornerstone with Moodle

What does it cost to move from Cornerstone to self-hosted Moodle?

The switch cost is the sum of components, not a single licence swap. Cornerstone is a subscription you stop paying, while Moodle's software is free under the GNU General Public License version 3, so the new costs are hosting, database and backup infrastructure, a Moodle administrator, integration work with your HRIS and single sign-on, content migration, and the audit work your own environment now needs. Ask any partner for a quote broken into those components, marking which items are one-time and which recur each year. The largest drivers are how many courses and certification rules you rebuild, how many systems feed user data, and how much completion history you must move. Content library licences you already pay for from third parties, such as course catalogues, need to be checked separately because they may not transfer.

How long does a Cornerstone to Moodle migration take?

No duration can be promised before the scope is known, so the timeline is set by what you migrate. The main drivers are the number of SCORM, AICC and xAPI packages to reload and test, the number of recertification rules to rebuild, the HRIS user feeds to reconnect, and the volume of transcripts and certification history to export and load. Moodle's release calendar also affects planning: major releases arrive in April and October, and the current long-term support release is the safer target for a production build. Your validation and sign-off cycle often takes longer than the technical move, so build it into the written scope before work starts. DeployOpen's engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins.

What does the migration need from our internal staff?

Your staff must own the business rules, while the technical team handles infrastructure and integrations. Compliance owners need to define which courses are mandatory, how long a certification stays valid and what triggers renewal, because those rules have to be rebuilt in Moodle rather than copied automatically. HRIS and identity owners must confirm user attributes, org units and deprovisioning rules. Platform engineers take on hosting, PHP and database upgrades, backups and patching. Plan for a named Moodle administrator after go-live, since no one else in the organization is likely to know the platform. Ask any partner which of these roles they cover and which stay with you.

Can our own team migrate from Cornerstone to Moodle without outside help?

A capable team can do it, but the risk sits in the parts most teams have not done before: exporting transcripts and certification history from a SaaS system, rebuilding recertification logic, and documenting controls for an audit. Before deciding, check whether your team has someone who has run Moodle in production and can follow the upgrade rules in the release notes, including the public directory change that applies from Moodle 5.1. If those skills are missing, outside help can be scoped to specific deliverables, such as the export and load, the integration work or the hardening, with the rest kept in-house. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and any role split should be written into the scope.

What happens to completion history and certifications when we leave Cornerstone?

Course packages and learner records move separately. SCORM, AICC and xAPI packages are standard formats, so the original files from your authoring tools can usually be reloaded into Moodle. Completion history, transcripts and certification records are not part of the package and must be exported from Cornerstone through its data export tooling, then mapped and imported into Moodle. Keep the original completion dates, expiry dates and issuing authority for each record, because auditors will ask whether a record in the new system matches the source. Also decide whether historic certificates stay as read-only evidence in an archive. Confirm with Cornerstone which export formats and fields your contract covers before you start.

Can self-hosted Moodle meet FedRAMP Moderate or 21 CFR Part 11 needs?

Moodle itself is not a FedRAMP authorized service or a validated system for 21 CFR Part 11, so neither status transfers to a self-hosted install. Cornerstone describes its platform as holding FedRAMP Moderate authorization and ISO/IEC 27001 and SOC 2 Type II attestations, which cover Cornerstone's own environment. Your deployment would need its own authorization or validation effort, covering hosting, access control, audit trails, electronic signatures and change control. Whether a given Moodle configuration satisfies a specific requirement needs review by your compliance team and an independent assessor. Ask for the authorization scope in writing before deciding.

Who is responsible for audit evidence after the move?

You are responsible for audit evidence for your own environment, and that responsibility does not pass to Moodle or to an implementation partner. Cornerstone's certifications cover its cloud service, so once training runs in your infrastructure, your team must produce access reviews, change records, backup and restore tests, patch records and training completion logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Agree in the written scope which evidence will be produced, in what format, and who keeps it.

How a move from Cornerstone to Moodle is structured

The sequence separates content, learner records and recertification rules so each can be checked before users are moved, and it ends with Cornerstone switched off only after a verified parallel run. Each step produces a artifact your compliance team can sign off on.

Inventory content and certification rules
Your team lists every course, learning path and certification in Cornerstone, along with the rule behind each one: which roles require it, how often it renews, and what grace period applies. DeployOpen can help map these rules into a written register, but the compliance owner must approve it. Done means every certification has a named owner, a renewal interval confirmed by policy, and a list of the content packages it depends on. Confirm with your compliance lead whether any rule is defined only inside Cornerstone configuration.
Export transcripts and certification history
Learner completions, scores, dates and certification records are pulled out of Cornerstone through its data export interfaces, which need an administrator with the right permissions and the skills to query them. This is handled as a separate data stream from course content, because completion history does not travel inside SCORM, AICC or xAPI packages. The exported data is checked against record counts in Cornerstone and stored in a controlled location. See the export topic for the mechanics and the required skills.
Reload SCORM, AICC and xAPI packages
Original packages from your authoring tools are uploaded into Moodle and launched to confirm that each one reports completion, score and bookmarks as expected. Packages that fail are fixed or rebuilt at the source, not patched by hand inside the LMS. Moodle's support for these formats is confirmed against your specific package versions during testing. Done means every package in the register launches, reports to the gradebook and passes a sample learner test.
Rebuild recertification rules in Moodle
The certification rules from the register are configured in Moodle using its course completion, activity restriction and enrolment settings, and the renewal triggers are tested with test accounts whose dates are set to expire. Because Moodle does not carry Cornerstone's rule engine over automatically, every rule is rebuilt and reviewed by the compliance owner. Done means each rule has a test case with an expected outcome and a documented result. Confirm any feature you need, such as a specific certificate or expiry format, against the Moodle version you plan to run.
Connect HRIS user feeds
Your HR system remains the source of truth for who is employed and in which role, so the user feed from HRIS into Moodle is built and tested before cutover. Moodle core authentication options, such as LDAP, external database or web services, are evaluated against your identity setup, and provisioning, role changes and deprovisioning are tested with sample records. Done means a leaver loses access and a role change reassigns the right courses in the test environment. Confirm with your identity team which method fits your directory and security policy.
Run parallel and cut over
Both systems run side by side for a period your compliance owner agrees in writing, with completions recorded in Moodle and compared with Cornerstone for the same learners. Discrepancies in completion dates, renewal due dates or assignments are investigated and resolved before any learner is moved. Cutover happens only when the reconciliation report shows agreed differences, and learners are told where to go. Done means a signed reconciliation and a communication sent to the affected population.
Decommission Cornerstone after verification
Cornerstone is switched off only after the archived records, retention copies and audit evidence are confirmed as complete and readable. Your records retention policy determines how long exported transcripts and certification history must be kept, and that decision is recorded before access is removed. Access reviews and the contract end are handled with your procurement team. Done means an archive is verified, access is revoked, and the closure record is filed with your compliance evidence.

Which cost components change when you move training off a subscription

A Cornerstone subscription bundles software, hosting and vendor-held evidence into one recurring fee. Moving to Moodle splits those costs apart, and some are one-time while others recur every year. The cards below separate them so you can ask vendors and partners for quotes that line up with your own environment.

Subscription and content licenses

Cornerstone charges a recurring subscription, and third-party libraries such as LinkedIn Learning, Coursera and Skillsoft are usually licensed separately. Moodle core is licensed under GPL-3.0, so the platform itself carries no license fee. The content libraries do not disappear with the subscription, though. Check whether those library licenses are tied to the Cornerstone tenant and whether you can keep access to course content after you leave.

Hosting and infrastructure

In a self-hosted Moodle, you pay for servers or cloud accounts, databases, storage, backups and network capacity. These costs recur monthly or yearly and grow with learner count and retained media. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, so database licensing and support choices also affect this line. Ask your team to size for peak course launches, not average use.

Integration and data export work

Connecting Moodle to your HRIS, identity provider and content feeds is largely one-time project work, though the feeds need upkeep when systems change. Exporting transcripts, certification history and user records out of Cornerstone is a separate task, and it is often underestimated. Price this as a fixed-scope project with named deliverables, and confirm which data fields Cornerstone's export covers before you agree on scope.

Staff time for upgrades and evidence

Moodle ships major releases in April and October and minor releases every two months, so someone must schedule and test upgrades. Compliance evidence that Cornerstone holds for you, such as its security attestations, now sits with your own team. This work recurs for as long as you run the platform. Ask who on your staff owns upgrades, patching and audit evidence, and how many hours a quarter that realistically consumes.

Support and maintenance contracts

Cornerstone support is included in the subscription, while Moodle support comes from Moodle Partners, managed hosting providers or an in-house team. Commercial support and retainers are recurring costs that you choose to buy. Ask any provider whether the quote covers upgrades, security patches, backup testing and incident response, and whether it is fixed-scope or billed by the hour.

One-time migration effort

Moving training content, rebuilding recertification rules and cutting over users are one-time costs that land before the subscription ends. SCORM, AICC and xAPI packages can usually be reloaded, but completion history must be exported and migrated separately. Plan for a parallel run period in which both platforms are live. Ask for the migration plan in writing, including rollback steps and the cutover date.

How the switch looks for HR, compliance and IT teams

For HR and learning and development owners, the daily work of assigning courses, tracking completions and sending reminders stays familiar, but the tools behind it change. Moodle organizes training around courses, activities and cohorts, so mandatory curricula and recurring requirements have to be rebuilt as course structures, enrolment rules and completion conditions instead of being carried over as settings. Cornerstone's catalog and auto-enrolment behaviors do not transfer on their own, so each recurring assignment needs an owner who can describe it in plain terms before anyone configures it.

Course and curriculum rebuild: Map every mandatory curriculum to Moodle courses, activities and completion rules, and record which ones rely on Cornerstone-specific behavior.
Content reuse: Reload SCORM, AICC and xAPI packages where the authoring tool output is intact, and test each package before it reaches learners.
Learner communications: Reproduce due-date reminders and manager notices, which Moodle does not send out of the box in the same form.
Catalog governance: Decide who approves new courses and who retires old ones once the self-hosted system is the record.
Transcript questions: Confirm with HR which historical completions must stay visible to learners and managers after cutover.

Before deciding, ask your vendor and your own HR team which Cornerstone features your learners use every week, and test those specific flows in a pilot.

What to confirm before you choose

Settle the attestation question first, because it decides who carries the compliance burden. Cornerstone describes its learning platform as holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization, according to Cornerstone's learning platform page. Ask your auditors which of those reports they rely on today and whether they accept evidence from a self-operated environment for the same control areas. Moodle does not come with an audit report or authorization. Your organization, or an independent assessor, would have to produce the evidence for access control, change management, logging, backup and encryption, and the scope of that work depends on which auditor reports you currently present to regulators or customers.

Next, count the rules, not the courses. Map every certification that expires, every recertification trigger tied to a role, a region or a regulation, and every course that must be completed in a fixed order. Moodle supports completion conditions, cohorts and enrollment rules, but whether those cover your recertification logic without custom development is a question for a pilot. Also list your content libraries and HRIS connectors. Each third-party library such as LinkedIn Learning, Coursera or Skillsoft needs a licence arrangement you can keep paying for, a single sign-on path and a completion feed, and each HRIS feed needs an owner who keeps user data current. Ask Cornerstone for the exact integration list you use, and ask each library provider whether a self-hosted LMS can receive its completions.

Finally, test your internal capacity against the operating load, not the installation. Moodle ships major releases in April and October and point releases every two months, and each upgrade has its own minimum PHP, database and upgrade-path requirements, so confirm who will plan, test and apply them. Confirm who owns backups, restore tests, reporting and security patching, and whether your reporting team can rebuild the dashboards that managers use today. A short written pilot with a few real certification paths, one content library and one HRIS feed will show whether the internal team can run the platform before you commit to a migration.

How DeployOpen helps you evaluate, implement and support a self-hosted Moodle

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a Cornerstone to Moodle decision, we start by writing down which training records, attestations and certification rules you must still prove, then build and hand over a Moodle environment that you control.

How we scope

Written scope lists the course catalog, SCORM, AICC and xAPI packages, and user sources to be carried into Moodle.
Scope defines which certification and renewal rules are rebuilt, and which records remain in Cornerstone for retention.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We install Moodle in your cloud account, data center or air-gapped network, using the database and PHP versions your chosen release requires.
Integrations cover your identity provider, HRIS user feeds and content reloads, configured and tested against the agreed scope.
Security testing and hardening cover the web server, document root, backups and access controls before any learner data is loaded.

How we hand over

Deliverables include architecture notes, configuration records, runbooks for upgrades and backups, and a record of tests run.
We prepare the controls, logs and evidence your own auditors will need, but we do not issue audit reports or certifications.
Your team receives documentation and knowledge transfer so operations do not depend on a single contact.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Moodle release upgrades, patching against the support windows you choose, and periodic restore tests.
Ask any provider to confirm in writing who owns recertification rules, record retention and the audit trail after go-live.

Cornerstone vs Moodle