Export data from Cornerstone before your contract ends: what you can take
Transcripts, certification history and user data leave Cornerstone through documented export paths, so a renewal, licensing change or residency requirement does not have to end your learning records. The transcript and certification export runs through the Data Exporter API, which draws on the Real-time Data Warehouse. SCORM, AICC and xAPI packages do not need to be pulled out of Cornerstone at all: reload them from the original authoring source, such as the authoring tool project files or the vendor's package archive, because those are the files you will load into the new platform. Before you start, confirm which OData entities your Cornerstone tenant exposes and which service account roles can read them, since an exporter role that lacks read access to completion or certification objects will produce partial files without an obvious error.
Some things will not leave with the data. Attestations that Cornerstone holds for its own compliance programs, its audit reports and certifications, and licensed content from third-party libraries such as LinkedIn Learning, Coursera and Skillsoft stay with the vendor or the content provider, so you will need new licenses or replacement material for those courses. Platform configuration, including assignment rules, recertification logic and custom fields, is usually documented in your admin console but is not exported as a portable file, so plan to record it yourself before the contract ends. Ask Cornerstone to confirm in writing the exact object list, file formats, row limits, any export caps and the retention window for historical data. Those answers, not general assumptions, should set the scope of your export project.
Which Cornerstone data types export, by method and format
This table maps each Cornerstone data type to its export route, output format and limits. Where the supplied documentation does not confirm a format or limit, the cell lists what to request from Cornerstone before planning the migration. The main takeaway is that records come out through the Data Exporter API while course content leaves in its original package form.
| Data type | Export method | Output format | Limits and what to request from Cornerstone |
|---|---|---|---|
| Transcripts and completion history | Data Exporter API over the Real-time Data Warehouse | Confirm with Cornerstone (not stated in supplied documentation) | Request the object list, row limits, date filters and whether completions include attempt-level detail |
| Certification and recertification records | Data Exporter API over the Real-time Data Warehouse | Confirm with Cornerstone (not stated in supplied documentation) | Request certificate issue and expiry dates, renewal history and whether recertification rules are exported or only results |
| User and organization records | Data Exporter API over the Real-time Data Warehouse | Confirm with Cornerstone (not stated in supplied documentation) | Request user, job, manager and org unit objects, plus how inactive or terminated users are included |
| Internally built course content | Original content package from the authoring tool or Cornerstone library | SCORM, AICC or xAPI package in its original form | Confirm which package versions are stored and whether original ZIP files are retrievable; re-check the source files held by your authoring team |
| Third-party library content | Not a Cornerstone export; use the licensing source | Depends on the provider | Confirm license terms allow reuse outside Cornerstone before planning a reload |
What does not export from Cornerstone and how to work around it
A data export moves records, not everything that makes a Cornerstone tenant work. The items below sit outside the exported objects, so each one needs a named owner and a workaround before the cutover date is set.
Cornerstone's own control attestations
Cornerstone describes its learning platform as holding ISO/IEC 27001, SOC 2 Type II and FedRAMP Moderate authorization. These attest to Cornerstone's own hosted environment, so no export carries them. Ask Cornerstone for the current certificates, reports and authorization documentation through your account team or procurement channel. Once you move to a self-hosted Moodle, the attestations for the hosting environment become your responsibility, and an independent auditor or certification body must assess them. DeployOpen prepares evidence for those assessments but does not issue them.
Licensed third-party library content
Courses from LinkedIn Learning, Coursera and Skillsoft are integrated into Cornerstone, but the content itself is licensed to Cornerstone's customers under each provider's terms. Export tools return catalog links and completion records, not the course files. Pull the list of third-party assets assigned to each learner group, then confirm with each provider whether your license allows access from a different platform. Plan for either a new subscription or removing these courses from the target catalog.
Certification rule logic and renewal triggers
The rules that decide when a certification expires, how long a renewal window runs and which event restarts the clock are configuration, not data. The exported certification history shows dates and outcomes but not the logic that produced them. Document each certification's expiry, grace period and renewal trigger from the Cornerstone admin screens, then rebuild those rules in Moodle, typically with completion conditions and scheduled checks. The compliance lead should sign off on the rebuilt rules against a sample of learners.
Workflow, notification and HRIS integration settings
Assignment workflows, reminder emails, escalation steps and the feeds that create or deactivate users from your HRIS are configured inside Cornerstone. None of these appear in a user or transcript export. Inventory every workflow and each integration endpoint, field mapping and sync schedule, then assign a platform engineer to recreate them in the target. Test user provisioning and deprovisioning with a small pilot group, because a missed HRIS feed leaves leavers with active training access.
Custom report definitions
Custom reports built in Cornerstone hold filters, column choices, scheduled delivery and audience permissions. The Data Exporter API returns the underlying records, so each report must be rebuilt from those records in the target's reporting tools. Keep a list of reports that compliance or management relies on, and compare the rebuilt output against a recent Cornerstone report for the same period before retiring the original. Assign ownership to the team that consumes each report.
Audit trail detail outside exported objects
Who changed a training assignment, when a due date was edited or which administrator reset a record may sit in Cornerstone's internal audit logs rather than in the exported objects. Confirm with Cornerstone which audit events are retained, for how long and in what format, and request a copy before the tenant closes. If your records must remain defensible, archive that history in your own storage and document the retention period. The records owner should decide this before cutover.
How the Data Exporter API and OData skills fit into the export
The Data Exporter API is the route an engineering lead should plan around, and it reads from Cornerstone's Real-time Data Warehouse rather than from the live application screens. Requests are written against Cornerstone's data model using OData queries, so the export is a data engineering task with a defined contract, not a report download. Before scoping it, confirm with Cornerstone which OData version the API exposes, which entity names hold transcripts, certification records and user attributes, and whether those entities join cleanly on user and course identifiers. Ask for these in writing, because entity names and relationships determine every query your team writes.
Staffing is the constraint most teams underestimate. You need people who can write and test OData filters, handle server-side paging, run incremental pulls keyed on modification timestamps, and reconcile records when a pull is interrupted. Confirm with Cornerstone the API credentials and their scope (read-only versus broader access), any rate or volume limits, how timestamps are stored and time zoned, and the support path when a query returns an error or incomplete data. Also confirm whether historical certification renewals appear as separate rows, since that affects how you rebuild expiry dates later.
Run a pilot pull on one bounded population, such as a single business unit with a known set of certifications, before the full run. Compare row counts and a sample of individual transcripts against what Cornerstone's administrators see in the product. The extract will contain personal data about employees and contractors, so the pilot output should be stored under your own retention and access rules from the first file, with named owners and a deletion date for working copies. Treat the pilot as the test of your assumptions about paging, timestamps and entity joins, and do not start the full run until those assumptions hold.
Export data from Cornerstone in six steps, with a check at each one
This sequence moves transcripts, certification history and user records out of Cornerstone in a controlled order, so each extract can be reconciled against its source before anything is loaded into the target platform.
Inventory objects and date ranges needed
Your compliance or L&D owner lists every object the target must hold: transcripts, certification awards and expiry dates, user profiles, org units and course catalog references. For each object, record the date range, the reporting population and the fields that drive recertification rules. Confirm the list with the people who sign off on training records, since missing a field here is expensive to fix later. Done when you have a signed inventory that names each object, its date range and its owner, and the source report that shows its expected counts.
Request API access and confirm limits
Your Cornerstone administrator requests access to the Data Exporter API and the Real-time Data Warehouse, and confirms which OData entities your account can read. Ask Cornerstone in writing which entities are exposed, how the OData skills and query syntax apply to each, what row or request limits exist, and how changed records are identified for incremental runs. Keep the written answers with the inventory. Done when you hold a dated record of the entities, permissions and limits, and your engineers have tested a single read against each entity.
Run a pilot extract and reconcile counts
Pick one small, well-understood population, such as a single org unit with a known number of completions, and extract its transcripts, certifications and user records. Compare row counts, distinct learner IDs and completion totals with the source report run for the same filters on the same day. Investigate every difference, including paging, time zone handling and inactive users, before you scale up. Done when the pilot counts match the source report or each variance has a documented cause and fix, and the reconciliation sheet is saved with the query text.
Run the full extract into staging
Run the full extract with the approved queries into a staging store that is separate from the target LMS. Each output file gets an extraction timestamp, the query version, the row count and a checksum, and the run log records any errors or retries. Keep raw responses unchanged so the run can be repeated. Done when every file has its metadata and checksum recorded, and the run log shows no unexplained failures.
Collect and test-load content packages
Gather SCORM, AICC and xAPI packages from the original authoring sources, such as the course owner's repository or the authoring tool project, rather than relying only on files downloaded from the platform. Compare each package's checksum against the original where possible, then load a sample into the target LMS and confirm launch, completion reporting and score capture. Note any package that depends on a third-party library, since those may need to be replaced. Done when each package has a load result and an owner, and the test-load log lists the packages that failed and why.
Reconcile records against the source report
Compare record counts, certification expiry dates and completion dates in staging with the source Cornerstone report for the full population, using the same filters and cut-off time as the extract. Sample a set of learners across several course types and check their records by hand. Any mismatch is either corrected in the extract or recorded as an accepted exception signed by the data owner. Done when the reconciliation report shows matching totals for every object, the sample checks are signed, and the exceptions list is approved.
Re-using SCORM, AICC and xAPI packages after leaving Cornerstone
The original content packages are the portable part of your Cornerstone library, so start by finding the files your authors first produced in their authoring tools. Cornerstone supports internally built training content in SCORM, AICC and xAPI formats, so the courses you built yourself should exist as standard packages somewhere in your organization, usually in the authoring tool's project folder, a content team's shared drive or the original vendor's delivery folder. Ask each course owner for the source file and the published package, and record which standard each one uses. Where a course was edited inside Cornerstone after upload, confirm whether the current version exists outside the platform before you rely on a file you cannot trace back to its author.
Before any bulk load, test a representative package of each standard in the target LMS. Pick one SCORM 1.2 course, one SCORM 2004 course, one AICC course and one xAPI package, each with a quiz or score, and confirm that it launches, reports completion and passes a score back. Moodle's core behavior for these standards is a useful test target, but treat it as a starting point and confirm the exact supported versions in the documentation for the release you deploy, since support differs between versions. Also check how the target handles package size, because Docebo's documented limit of 2 GB per ZIP upload is a vendor figure and not a general rule for other platforms.
Completion history and learner records do not travel inside the package. A SCORM or xAPI file carries the course logic and, at most, the state of one learner's session, so transcripts, completion dates, scores and certification history must come from the Cornerstone export and be loaded separately. Plan that load as its own workstream with its own validation, and decide in advance which records are authoritative for recertification. Third-party library content from providers such as LinkedIn Learning, Coursera or Skillsoft is governed by each provider's own license terms, so ask each provider whether you may host the content on your own servers, whether the license transfers to a new platform, and whether you need a new agreement before you move anything.
Export and import paths for Moodle and Open edX
Moodle loads records into its own tables for users, course enrollments and course completions, so the Cornerstone export should be split into those three groups and loaded in order. Each record must point to an account or course that already exists. Confirm with your Moodle provider which bulk upload method and file layout your installed version supports, because the Data Exporter output will likely need a transform before it fits.
- Export file shape: Ask for one file per entity with a stable learner key, such as an employee ID, repeated in every file. Confirm field names, date formats and encoding with Cornerstone before writing the transform.
- Load sequence: Create or sync user accounts first, then enrollments, then completions. A completion row for a missing user or course will fail, so keep the order fixed and rerun the full load on a test site.
- Completion mapping: Map each Cornerstone completion to a Moodle course completion only where the course and its completion criteria already exist. Keep the original completion date and certificate reference in a custom field or retained document, because recertification dates depend on them.
- Sign-in features: Moodle core ships authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, and a SAML 2 plugin is available on the Moodle marketplace. Choose the method your identity provider supports before go-live so account identifiers match the export.
- Version prerequisites: Moodle 5.1 requires 64-bit PHP 8.2 or later and upgrades start from Moodle 4.2.3 or later. Moodle 5.3 requires PHP 8.3 or later and upgrades start from Moodle 4.4 or later.
Confirm the import tooling, the upgrade path and the supported sign-in method with your Moodle provider before you choose a version.
Open edX organizes learning around courses built in Studio and delivered through the LMS, so the Cornerstone export has to be planned around courses you rebuild or reload. Course structure comes first, and learner records attach to it afterward. Confirm with your Open edX service provider or Tutor deployment whether a bulk loader exists for users, enrollments and grades, because that determines how much custom work the migration needs.
- Export file shape: Agree on one file per entity, a stable learner key and an external course key that matches the Studio course you create. Confirm the layout with Cornerstone and your provider before anyone writes a loader.
- Load sequence: Build the course structure in Studio, then load learner accounts, then enrollments, then completions. Completion history for a course that does not exist yet has nothing to attach to.
- Completion mapping: Record each Cornerstone completion against the matching Open edX course and keep the original completion date and certificate ID as an audit reference. Aspects analytics captures tracking logs as xAPI statements, which helps you check new activity against loaded history.
- Sign-in features: Third-party authentication supports OAuth2 providers (Google, Facebook, LinkedIn and Azure Active Directory by default), SAML 2.0, Shibboleth and LTI, with older provisional support for CAS. LDAP is not in that list, so confirm it with your provider if your directory is LDAP-based.
- Deployment choice: The maintainers recommend a service provider or Tutor for production because bare-metal installation is complex. Tutor supports Kubernetes and plugins, which is where a custom loader would typically run.
Ask your provider to confirm the loader, the supported identity protocols and the release you will deploy before you commit to a build plan.
Whichever target you choose, reconciliation is what proves the load worked. Compare counts and sample records against the export before anyone uses the new platform for compliance tracking. Keep the evidence of the comparison with the load logs, since auditors and your own compliance team will ask what moved and how you know.
- Row counts: Compare user, enrollment and completion totals for each file with the export totals, and log every rejected row with its reason.
- Sample audit: Select learners across departments and check that name, identifier, course and completion date match the source record.
- Duplicate accounts: Confirm that the stable learner key prevents duplicate accounts once sign-in is connected to your identity provider.
- Content launch: Confirm that the SCORM, AICC and xAPI packages you reloaded launch and report completion on the target before you retire the source. Note that packages carry course content, not learner history.
- Retention: Keep the original export, transform scripts and load logs under your records retention rule, since they are the evidence of the migration.
Confirm the reconciliation method and log format with your platform provider and with the owner of your training records before cutover.
How much effort and cost does a Cornerstone data export take?
What drives the effort of a Cornerstone data export?
The effort scales with four things: the number of learner and transcript records, how many years of completion and certification history you keep, how many SCORM, AICC and xAPI content packages must be re-used, and how much OData query work your team can absorb in-house. Record volume and history depth affect extraction runs and validation time. Package count affects how many items need a test launch in the target LMS. OData skills decide whether one engineer can build the queries or whether the work needs a specialist for several weeks of iteration. No public figure for these drivers is supplied here, so ask Cornerstone and any partner to size each driver separately in writing before comparing offers.
Can our team export Cornerstone data without an outside partner?
Yes, if you have people who can work with the Data Exporter API, the Real-time Data Warehouse and OData queries, and who can check the output against your compliance records. Many teams handle a small, well-documented export this way. The risk grows when transcripts must match certification expiry dates, when user identifiers must map cleanly to an HRIS feed, or when auditors will ask how each file was produced. In those cases, an internal team typically needs a documented extraction method, a reconciliation step and a sign-off from the data owner. Confirm the API access level and export options with Cornerstone before committing to a self-run plan.
How long does a Cornerstone export take, and what sets the schedule?
The schedule depends mostly on how quickly Cornerstone responds to access and API questions, how many extraction cycles a pilot needs before the output matches source reports, and how long your data owner takes to approve retention decisions. A pilot on a representative subset is usually the best way to learn these timings for your tenant. No duration is supplied for this work, so ask for a timeline tied to named milestones: access granted, pilot extract reconciled, full extract validated, and handover of files and documentation. Any engagement should be fixed in writing with scope, deliverables and dates agreed before work starts.
What must our organization provide before an export starts?
Four inputs are needed before extraction begins:
- Administrator access to the Cornerstone tenant, with rights to view transcripts, certifications and user records
- API credentials and confirmation of which Data Exporter and Real-time Data Warehouse endpoints your contract covers
- A named data owner who can approve field mappings and resolve questions about records
- Written retention decisions on which history to keep, how long, and where the files will be stored
Without the retention decision, teams often export everything and then pay twice, once to extract and again to store and review. Ask your data owner to confirm the legal basis for keeping each record class before the first run.
How do costs split between internal staff, Cornerstone and outside help?
Costs fall into three groups. Internal staff time covers the data owner, administrators, the person running queries and the reviewers who check the output. Cornerstone charges depend on your contract, so ask whether API access, warehouse access or professional services are included or billed separately. Outside help is billed for planning, query build, pilot reconciliation, documentation and handover. One-time work includes the initial export, mapping and validation. Recurring costs appear if you need refreshed extracts during a parallel run, or ongoing support after cutover. Ask each party for its cost components in separate line items so you can see which work moves if the scope changes.
What should a fixed-scope quote for a Cornerstone export include?
A fixed-scope quote should name the object types in scope, such as transcripts, certifications, user records and content packages, along with the date range and the target format. It should list the systems involved, the validation method, the acceptance criteria and the handover package, including query scripts, field dictionary and reconciliation reports. Ask how many pilot cycles are included, what happens if Cornerstone access is delayed, and which tasks sit outside the quote. DeployOpen plans and delivers fixed-scope engagements in writing before work starts, and ongoing support is available as a separate retainer if you need it after cutover.
Does the export cover re-using SCORM, AICC and xAPI packages?
Content packages and learner records are handled as separate workstreams. Standard SCORM, AICC and xAPI packages from authoring tools can usually be reloaded into an open-source LMS, but completion history and learner records must be exported and migrated on their own. Each package needs an inventory, a launch test in the target platform and a check that completion events are recorded. Packages that depend on a vendor-specific player, or on a third-party library licensed to Cornerstone, may need a different path. Confirm the license terms for each third-party library before you plan reuse.
What to plan before the Cornerstone renewal or termination date
Most of the export risk is decided in the contract, not in the API. Check these items with your Cornerstone account team and your legal and procurement owners before the notice date, because each one sets a deadline or a right that the export depends on.
Notice period and export completion date
Confirm the notice period in the order form and the date by which a full export must finish, counted back from the end of service. Ask who owns the date on the Cornerstone side and who owns it on yours. Build the export plan backward from that date, and include time to validate transcripts and certification records against a sample of known learners before access ends.
Data return and deletion terms
Read the data return and deletion clauses in the master agreement and any data processing addendum. Confirm the format in which Cornerstone returns data, whether it is included in the fee, and how long it keeps copies after termination. Ask for written confirmation of the deletion timeline and a certificate of deletion, since your records may be needed for audits after the contract ends.
Export window and post-termination API access
Ask whether the Data Exporter API and the Real-time Data Warehouse remain available after the termination date, and for how long. If access stops at termination, the export must be finished earlier, so the export window becomes the real deadline. Request the access terms in writing, including rate limits and any limit on the number of export runs.
Record retention for training evidence
Identify which training and certification records you must keep, for how long, and under which regulation or internal policy. Transcripts and completion evidence often need longer retention than the platform license. Confirm with your compliance lead that the exported files, including completion timestamps and certificate history, will be stored in a form your auditors accept.
License terms for content and third-party libraries
Separate content you authored, which you usually own, from third-party library content from providers such as LinkedIn Learning, Coursera or Skillsoft, which is normally licensed to the subscriber for use on the platform. Ask the vendor and each content provider whether exported SCORM, AICC or xAPI packages may be hosted on your own servers, and whether licensed courses can be retained after the subscription ends.
Freeze on course and certification rules
Set a change freeze on course versions, completion criteria, passing scores and recertification intervals for the migration period. If rules change in Cornerstone during the export, the exported history will not match the rules you rebuild in Moodle. Assign one owner to approve any exception and record it in the migration log.
How DeployOpen scopes and delivers a Cornerstone data export
DeployOpen treats a Cornerstone export as a scoped piece of work with named data sets, agreed formats and a documented destination. We plan, build, test and hand over the export pipeline inside your own infrastructure, so transcripts, certification records and user data land where your open-source LMS can use them.
How we scope
- Engagements are fixed-scope, with the data sets, formats and deliverables agreed in writing before work starts.
- The scope lists which transcript, certification and user fields are in or out, including any Data Exporter API permissions your team must grant.
- We confirm with your administrators which OData skills and API access the export account needs, and who approves them.
- Ask for a written inventory of SCORM, AICC and xAPI packages and their source authoring tools before pricing content reuse.
How we build
- We build the extraction over the Real-time Data Warehouse and Data Exporter API, using your credentials and stored in your environment.
- Exported records are mapped to the target LMS schema, with completion history and certification dates kept as separate, traceable fields.
- Content packages are checked for reloadability into the target platform, and any that fail are listed in a remediation log.
- Test runs compare record counts and sample learner histories against Cornerstone reports before any production load.
How we hand over
- Deliverables include the export scripts, field mapping documents, validation reports and a runbook for repeating the export.
- We document which records were exported, when, by which account, and how hashes or counts were checked, to support your own records retention decisions.
- Knowledge transfer sessions walk your team through the pipeline so they can rerun or adjust it without us.
- Evidence is handed over to you as a package. DeployOpen prepares records for review, while independent auditors and certification bodies assess them.
How we support
- Post-handover support, upgrades and re-testing are available as a retainer, scoped separately from the export itself.
- Ask for the support hours, response channels and escalation path in the written quote, since these vary by engagement.
- If Cornerstone changes its export API or the target platform releases a new version, we can re-test the pipeline under a retainer.
- Confirm with us and your vendor in advance which parts of the export depend on contract terms, such as data return clauses.
