The L&D caption checklist for LMS migrations: what caption data survives the move, what breaks, and how to audit before cutover

Why LMS migrations break captions

Caption compliance is the last item on most LMS migration checklists because it is the last item to be audited in the first place. Most L&D teams arrive at their LMS migration having already established WCAG-compliant caption production — they have caption files for their training library, a captioning vendor under contract, and a documentation trail that proves compliance. The assumption going into the migration is that these assets will survive the platform switch. In the majority of cases, at least one of the five caption data types does not survive intact.

Three structural characteristics of LMS architectures cause the problem:

Characteristic 1: Caption files are sidecar data, not video properties. A video file (MP4, WebM) does not contain caption data unless the captions are burned in — a delivery method that is non-compliant with WCAG 2.1 AA SC 1.2.2 because it denies the user the ability to turn captions off. The standard-compliant delivery method is a separate caption file (SRT, VTT, TTML) served alongside the video by the LMS player. That caption file and its association with the video are stored as database records, not as part of the video file. Migration tools that move video files without also migrating the caption database records move the video without its captions.

Characteristic 2: Track metadata lives in the LMS database, not in the caption file. A VTT caption file is a plain text file with timestamps and text. It does not record which video it belongs to, what language it is, whether it should be on by default, or whether it is tagged as "captions" rather than "subtitles." All of that metadata is stored in the LMS's content management database. When the caption file moves to the destination LMS, the metadata does not move with it — the destination LMS starts with blank metadata for the imported file, and the L&D administrator has to re-enter language codes, labels, and default-on settings for every caption track.

Characteristic 3: Glossary configurations are external to the LMS. The domain-specific vocabulary that makes WCAG 2.1 AA–grade captions possible on technical, medical, or safety content is not stored in the LMS. It lives on the captioning vendor's platform, connected to the LMS via an integration that uses a customer identifier to route new caption jobs to the right vocabulary model. When the destination LMS sets up its captioning vendor integration, it needs to pass the same customer identifier — or explicitly link to the existing vocabulary configuration — or new caption jobs in the destination LMS will run against the default model, not the tuned model. The result looks like captions (there are words, they are synchronised), but the accuracy on proper-noun-dense content drops from 99%+ back to the pre-glossary baseline of 83–88% WER depending on vertical.

These three characteristics combine to produce the most common post-migration caption failure: the migration declares success (all content objects migrated, all users migrated, all completion records migrated), the first round of post-migration testing shows video playback working, and everyone moves on. Three weeks later, an L&D administrator checks a video and finds no captions. Or a hearing-impaired employee files an accommodation complaint because captions that were available before the migration are gone. Or an OCR (Office for Civil Rights) inquiry asks for caption compliance documentation and the organisation cannot produce records that were decommissioned with the source LMS.

None of this is specific to any particular LMS platform. It is a structural consequence of how modern LMS architectures store and serve caption data, and it affects every LMS migration regardless of which platforms are involved.

The five caption data types

A caption migration is not one task — it is five parallel tasks, each covering a distinct type of caption data. Understanding what each type is, where it lives, and how it moves (or doesn't) is the foundation of any migration caption plan.

Data type 1: Caption files

The caption file — the SRT, VTT, TTML, or SBV text file that contains the timed transcript — is the most visible caption data type and the one most migration checklists at least attempt to address. Caption files are plain text and can be downloaded, stored, and re-uploaded. The risk is not loss of the file itself but loss of the association: after migration, the file needs to be attached to the correct video in the destination LMS, with the correct track metadata applied. A folder of 300 VTT files without a mapping from file to video asset is essentially useless — re-attaching them manually takes as long as re-captioning from scratch.

Migration requirement: Export a CSV with three columns — source asset ID, video title (for human reference), and caption file path. This mapping is what you need to re-attach files correctly in the destination LMS. Without it, the caption files are data without context.

For full guidance on format-level details — the differences between SRT, VTT, TTML, and SBV and which formats each LMS accepts — see the SRT/VTT/TTML/STL caption format guide. Format compatibility is an underestimated migration risk: a caption file that plays correctly in the source LMS may be rejected by the destination LMS due to format variant differences (missing WEBVTT header in a VTT file, timestamp format variations in an SRT, encoding issues in a TTML export).

Data type 2: Track metadata

Track metadata is the collection of properties that the LMS assigns to a caption track, separate from the content of the caption file itself. The four critical metadata fields are:

• Language code: The BCP 47 language tag applied to the track (en-US, fr-FR, de-DE, es-MX, etc.). This tag determines which track a hearing-impaired user's browser or assistive technology selects automatically when multiple language tracks are available.
• Track label: The human-readable label shown in the player's caption menu ("English Captions," "Auto-generated (unverified)," "Captions for English Audio"). The label determines whether a learner can distinguish a verified WCAG-compliant track from an unverified auto-generated track.
• Track type: Whether the track is tagged as "captions" (includes speaker IDs and sound descriptions, intended for viewers who cannot hear the audio) or "subtitles" (provides a translation of the audio, assumes the viewer can hear). WCAG 2.1 AA SC 1.2.2 requires "captions" not "subtitles" for training video content.
• Default on/off: Whether the caption track activates automatically for all learners or must be manually enabled. For content covered by ADA Title II or Section 508, the default-on setting is increasingly expected by OCR enforcement guidance — a caption track that requires a three-step process to enable is not meeting the functional requirement for accessible delivery.

Migration requirement: Export track metadata alongside caption files. The export CSV should include: source asset ID, caption file path, language code, track label, track type, default on/off setting. This metadata must be re-applied explicitly in the destination LMS after the caption file is imported — it will not carry over automatically.

Data type 3: Timing data integrity

Within the caption file, the millisecond-level timing data that keeps captions synchronised with audio can be silently corrupted during format conversion. The most common corruption scenarios:

• SRT to VTT conversion: Low risk if a standards-compliant converter is used. The main risk is the missing WEBVTT file header — technically required by the spec, tolerated by most players but rejected by some strict validators (including Workday Learning's).
• TTML/DFXP to SRT or VTT: Moderate risk. TTML supports per-character timing and style regions that have no SRT/VTT equivalent. A TTML-to-SRT converter that handles these correctly will merge overlapping cue regions; a badly implemented converter may add small timing offsets or lose cues entirely.
• SBV (YouTube format) to SRT or VTT: Low risk. SBV is a simple format close to SRT. The main risk is timestamp precision — SBV uses comma separators in timestamps where SRT uses commas too, but some converters output with incorrect decimal precision (100ms vs 1ms).
• Frame-rate-dependent timing: If caption files were produced against a specific frame rate (23.976fps for NTSC-sourced video, 25fps for PAL) and the destination LMS serves video at a different frame rate, all timing values will be off by a systematic offset. This is rare in modern web delivery (browser video is frame-rate-agnostic) but affects SCORM packages with embedded video.

Migration requirement: After any format conversion, spot-check timing synchronisation on 10% of converted files before uploading to the destination LMS. Play the video with captions visible and verify that caption text appears within one second of the corresponding audio on at least three timestamps per clip (beginning, middle, end). Any systematic offset indicates a converter problem, not a file-level issue — fix the converter, then re-convert the full batch.

Data type 4: Glossary / vocabulary configuration

The per-customer vocabulary model is the least visible but highest-impact caption data type. The glossary — the domain-specific term list that biases the ASR system toward your product names, drug names, OSHA citation codes, engineering abbreviations, and other proper nouns — is stored on the captioning vendor's platform, not in the LMS. The connection between the LMS and the vocabulary model is maintained through a customer identifier that the LMS passes to the vendor API on each new caption job.

When a new LMS integration is set up with the same captioning vendor, the customer identifier must be explicitly configured in the new integration — it is not automatically inherited from the old integration. If the new integration is configured without the customer identifier, every new caption job submitted through the destination LMS runs against the vendor's default model. The accuracy result is the pre-glossary baseline: 83–88% WER on OSHA safety content, 86–89% WER on engineering onboarding content, 85–88% WER on medical training content, depending on content type. For a glossary built over two or three years of correction feedback, this represents a complete loss of the compound accuracy advantage documented in the caption feedback loop post.

Migration requirement: Before cutover, test the destination LMS captioning integration explicitly. Submit a 60-second sample of the most vocabulary-dense content in the catalogue (a clip with at least 15–20 domain-specific terms). If WER on the sample is at the pre-glossary baseline, the glossary connection is broken. Contact the captioning vendor to confirm that the customer identifier is correctly configured in the destination LMS integration before the migration completes.

For full documentation of glossary architecture — how the vocabulary model is built, maintained, and connected to caption production — see the customer glossary architecture post.

Data type 5: Caption accuracy history

The accuracy history — the record of which caption files were produced when, by which vendor or tool, with what accuracy score, and whether they have been QC-reviewed — is the compliance documentation that proves WCAG 2.1 AA compliance in an audit or legal investigation. This data lives in the captioning vendor's dashboard, not in the LMS. It is not part of the content migration. It will not be available in the destination LMS. Once the source LMS is decommissioned and the captioning vendor integration is switched to the destination LMS, historical accuracy records for pre-migration content may no longer be accessible through the vendor dashboard.

Migration requirement: Export all accuracy records, QC logs, and correction history from the captioning vendor dashboard before migration starts. Requested format: a CSV with columns — asset title, source LMS asset ID, caption production date, vendor/tool, accuracy score or QC claim, reviewer name (if applicable), notes. This export is your offline compliance archive. Store it in a shared drive accessible to the compliance officer, independent of both the source and destination LMS. For the documentation structure that satisfies OCR and legal audit requirements, see the documentation dimension of the LMS caption audit methodology post and the documentation framework in the compliance program build post.

Caption migration capability matrix

The table below shows the common source-to-destination LMS migrations and the caption migration risk level for each. Risk level is assessed based on: (a) whether the source LMS's standard migration tools include caption files, (b) whether the destination LMS auto-generates captions on import (which can clobber manually uploaded files), and (c) whether track metadata survives the transition. Every migration carries at least moderate risk for the glossary and accuracy history data types, regardless of platform pair — those are always manual export tasks.

The matrix above covers caption file and metadata risk. Glossary configuration and accuracy history risk are HIGH for every platform combination — these are always manual export tasks that require coordination with the captioning vendor, regardless of which LMS platforms are involved.

Pre-migration caption audit: the 5-day sprint

Before any migration starts, the caption baseline needs to be established. Running the migration without knowing the current state of caption coverage, format compliance, accuracy, and documentation means the post-migration validation has no benchmark to compare against — you can't measure what broke if you don't know what worked before. The pre-migration caption audit runs in parallel with the migration planning phase, not after it.

The full methodology for running a WCAG caption compliance audit is in the LMS caption audit methodology post. The migration-specific version below is a focused five-day sprint designed to produce the three outputs the migration plan needs: (1) a complete caption file inventory with source LMS asset IDs, (2) a format and accuracy status for each file, and (3) a documentation export that becomes the offline compliance archive.

Day 1: Coverage inventory

Objective: produce a complete list of every training asset in the source LMS that has a caption file, every asset that has an auto-generated (unverified) caption track, and every asset that has no caption coverage at all.

Method: use the source LMS's content export API or admin reporting feature to generate a CSV of all content objects. For each content object, record: asset ID, title, video file type (MP4/YouTube embed/external URL/SCORM-embedded), caption presence (yes/no), caption type (manually uploaded VTT/SRT, LMS-native auto-generated, YouTube auto-generated, burned-in). Most LMS platforms have an admin report for course content that includes caption status — check the LMS admin documentation for the specific export path. Where the platform does not provide a native caption status report, run the export and manually sample 20% of assets by playing each and checking for caption track presence.

Output: a coverage inventory spreadsheet with one row per training asset. This spreadsheet becomes the master migration tracking document — every subsequent action (file export, format validation, accuracy check, metadata documentation, destination LMS upload) is recorded as additional columns on this sheet.

Day 2: Format validation

Objective: download all caption files in the source LMS and validate that each file meets the format requirements of the destination LMS.

Method: for each asset with a manually uploaded caption track, download the caption file. Validate it against the WCAG 2.1 AA caption format standards and against the destination LMS's specific format requirements (see the per-destination-LMS import checklists below for format requirements by platform). Run a format validator tool (the W3C Nu HTML Checker for VTT, an SRT validator for SRT files) on the full batch. Flag any files that fail validation and record the failure reason in the coverage inventory spreadsheet.

For assets with LMS-native auto-generated captions (not manually uploaded), record these as "auto-generated — unverified" in the coverage inventory. These files are potentially non-compliant regardless of format — they need an accuracy spot-check on Day 3.

Output: coverage inventory updated with format status column (pass/fail/auto-generated). A folder of downloaded caption files, named by source LMS asset ID to maintain the mapping to the coverage inventory.

Day 3: Accuracy spot-check

Objective: verify that caption files in the top compliance priority tier meet the WCAG 2.1 AA accuracy requirement before migration. Identify files that would fail a post-migration compliance audit.

Method: use the DCMP spot-check protocol documented in the caption QA methodology post. Apply the spot-check to all Tier 1 assets (mandatory compliance training, safety training, mandatory onboarding) and to all assets with auto-generated captions. For each asset, play a 60-second clip from the middle of the video and count word errors (substitutions, insertions, deletions) against the verbatim audio. Record the spot-check result (pass/fail, WER, error type breakdown) in the coverage inventory spreadsheet.

Assets that fail the accuracy spot-check before migration should be flagged for pre-migration remediation if they are Tier 1 priority, or for post-migration remediation with a documented deadline if they are lower priority. Do not migrate known Tier 1 accuracy failures without a remediation plan — this is an audit risk regardless of which LMS platform the content lives in. For the remediation decision framework, see the audit methodology post.

Day 4: Glossary documentation and export

Objective: document the current glossary configuration and establish what needs to be verified in the destination LMS integration.

Method: contact the captioning vendor account manager and request a glossary export — a list of all terms in the per-customer vocabulary model, including phoneme variants, context signals, and priority weights where available. Record the glossary term count, the date of the last update, and the most recent WER on the glossary-validation test clip (the 60-second sample used to verify glossary connection in the post-migration validation protocol). This documentation is what you need to verify that the destination LMS integration is using the same glossary, not the default model.

Also on Day 4: ask the captioning vendor to confirm the integration architecture for the destination LMS. Which customer identifier is used to route caption jobs to the per-customer vocabulary model? Is that identifier LMS-platform-agnostic (a GlossCap account ID, for example) or LMS-platform-specific (a Cornerstone tenant ID)? If LMS-platform-specific, the vendor needs to configure the destination LMS's identifier in the vocabulary routing table before cutover. This confirmation should be in writing — email or vendor support ticket — for the compliance record.

Day 5: Accuracy history export

Objective: create the offline compliance archive that will survive the source LMS decommissioning.

Method: export all accuracy records from the captioning vendor's dashboard. The vendor should provide an export that includes: asset title, caption production date, accuracy score or QC claim, QC reviewer name (if applicable), and any correction events. If the vendor does not provide a bulk export, pull the data manually from the dashboard — prioritise Tier 1 assets first. Supplement with any internal QC records from the QA methodology process that are stored outside the vendor dashboard (spreadsheets, Notion pages, shared drives).

Store the combined export as a CSV in a shared drive accessible to the compliance officer, separate from both the source LMS and the destination LMS. This archive needs to be accessible if the destination LMS experiences an outage, if the captioning vendor relationship ends, or if an OCR inquiry arrives after the source LMS has been decommissioned.

At the end of the 5-day sprint, the coverage inventory spreadsheet should have: one row per training asset, format status, accuracy status, glossary status, and accuracy history export status. This is the complete caption migration brief — the document that drives every action in the per-source-LMS export checklists below.

Per-source-LMS export checklists

The checklists below cover the eleven most commonly migrated LMS source platforms. Each covers: where caption files are stored in the platform, how to export them, what format they come in, and platform-specific risks. All checklists assume you have completed the 5-day pre-migration audit and have the coverage inventory spreadsheet ready.

TalentLMS (source)

TalentLMS stores caption files in two locations depending on how content was added: (a) SCORM packages, where caption files are embedded within the SCORM package ZIP as VTT files referenced by the package's HTML structure, and (b) native video uploads (Course units with video type), where TalentLMS stores an auto-generated VTT caption file in the course content directory.

Export method: For SCORM-based content, download the SCORM package from the course unit and extract the ZIP. Caption files are typically in a /captions/ or /assets/ subfolder. For native video content, download the course export from TalentLMS Admin → Courses → Export, which includes a ZIP with the video file and associated caption VTT. Third method: use the TalentLMS REST API's GET /courses/{id}/units endpoint to retrieve unit metadata; caption file URLs are available via the unit's content_url field for video units.

Format: VTT. Note that TalentLMS's auto-generated VTT files (from the built-in Whisper integration) sometimes use a simplified timestamp format that lacks the sub-millisecond precision required by the strict WebVTT spec. This causes failures in Workday Learning's VTT validator. Run all TalentLMS VTT exports through format validation before uploading to the destination.

Risk: YouTube-embedded course content is the primary risk. When a TalentLMS course embeds a YouTube video, the displayed captions are YouTube auto-captions — not uploaded VTT files, and not within TalentLMS's caption management. These auto-captions will carry over to the destination LMS as YouTube auto-captions. They need to be replaced with manually uploaded, verified VTT files in the destination LMS.

Docebo (source)

Docebo uses external video hosting (Kaltura, Wistia, Vimeo, or YouTube) in most enterprise configurations. Caption files in these configurations live on the video hosting platform, not in Docebo itself. Docebo's content management database stores references to the hosted video and its properties, but the caption file is managed by the video host.

Export method: First, determine your Docebo video hosting architecture. Log in to Docebo Admin, go to a training course with video, and check where the video is hosted (Kaltura, Wistia, Vimeo, YouTube, or Docebo Central Repository). For Kaltura-hosted video: use the Kaltura Caption Asset API to export all caption assets (see the Kaltura section below). For Wistia-hosted video: use the Wistia API's GET /medias/{hashed_id} endpoint to retrieve caption URLs. For Vimeo-hosted: use the Vimeo API texttracks endpoint. For Docebo Central Repository (native upload): use Docebo's Learning Object API to retrieve attachment URLs.

Risk: If your Docebo migration also involves a video hosting platform switch (e.g., Docebo + Kaltura → New LMS + native video hosting), you need two separate migration plans: one for Docebo metadata and one for Kaltura media + captions. Conflating these into a single migration plan is the most common reason Docebo caption migrations fail.

Cornerstone OnDemand (source)

Cornerstone OnDemand stores caption files at the content object level. There are two types: manually uploaded VTT files (stored in Cornerstone's content management layer) and Cornerstone-native auto-captions (generated by Azure Cognitive Services and stored in a separate auto-caption database layer).

Export method: In Cornerstone Admin, navigate to Content → Manage Online Training → select the content object → Media Caption. The caption management UI shows all caption tracks for the object and provides a download link for each. For bulk export, use the Cornerstone Reporting API's Training Object report, which provides content object IDs — then loop through IDs with the Content API's GET /content/{id}/captions endpoint to retrieve caption file download URLs. Allow 20–30 seconds per content object for the API loop.

Risk: Cornerstone's auto-captions (Azure Cognitive Services) are stored separately from manually uploaded captions. If the Cornerstone API returns auto-caption tracks as if they were verified tracks, the coverage inventory may incorrectly classify them as compliant. Manually verify which tracks are auto-generated (check the track creation date against when the content object was first published — auto-captions are created within minutes of publishing, while manually uploaded tracks are created days or weeks later).

Workday Learning (source)

Workday Learning stores caption files as media attachments on learning objects. Caption files are not included in Workday's standard GIS (Global Implementation Suite) data extract — the data extract that most Workday Learning migrations use for content metadata. Caption files require a separate API extraction using the Learning Objects REST API.

Export method: Use the Workday REST API's GET /learningContent endpoint to retrieve a list of all learning objects. For each learning object, use GET /learningContent/{id}/mediaContent to retrieve the media attachment URLs. Caption files are returned as attachment objects with MIME type text/vtt or text/srt. Download each caption file using the attachment URL, naming each file by the learning object ID to maintain the mapping. Total time: approximately 15–20 minutes per 100 learning objects, plus download time for the files themselves.

Risk: High. Many Workday Learning implementations lack manually uploaded caption files entirely — the learning object's caption coverage is provided by an external video hosting platform (YouTube, Vimeo, or a DAM system) whose caption tracks are served via iframe embed and are invisible to the Workday REST API. If your Workday Learning catalogue has a significant proportion of iframe-embedded video, the API export will return fewer caption files than the actual coverage (because the external platform's captions are not in Workday's database). Audit your video hosting architecture before relying on the Workday API export.

Kaltura (source)

Kaltura has a dedicated Caption Asset API that makes it the most migration-friendly platform for caption data of the major video LMS platforms. The Caption Asset API supports bulk export with full metadata preservation.

Export method: Use the Kaltura API's GET /service/caption_captionasset/action/list endpoint with an entry ID filter to retrieve all caption assets for a given media entry. The response includes: caption asset ID, language code, label, default flag, format, and status. Use GET /service/caption_captionasset/action/getUrl with the caption asset ID to retrieve a download URL for each caption file. Automate with a script: pull all entry IDs from the Media API, loop through with the caption asset list call, generate a CSV of (entry ID, caption asset ID, language code, label, default flag, format, download URL), then download each file. For a catalogue of 500 entries with an average of 1.3 caption tracks each, expect approximately 45–60 minutes to generate the export CSV and 2–3 hours for the file downloads.

Format: Kaltura exports caption files in the format they were uploaded (SRT, VTT, DFXP, SBV, or DXFP). The export preserves the original format — convert to the destination LMS's required format after downloading, not before.

Risk: Low for caption files and metadata. The Kaltura API export is reliable. The risk is the Kaltura REACH service (automatic caption generation) — if REACH is configured as the default for new entries, any media without an existing caption track may have an auto-generated REACH caption that is not in the manual-upload database. Pull all caption assets (not just manual uploads) and verify which are REACH-generated by checking the createdByType field in the caption asset record.

Panopto (source)

Panopto stores captions as .srt files associated with each session (recording). The Panopto API's Session endpoint provides metadata including caption file URLs.

Export method: Use the Panopto REST API's GET /sessions/{id} endpoint to retrieve session metadata. Caption files are returned in the Captions array, with a FileUrl property for each. For bulk export, use the GET /sessions endpoint with pagination to retrieve all sessions, then loop through to collect caption URLs. Note that Panopto's ASC (Automatic Speech Captioning) generates SRT files by default for all sessions — the export will include ASC-generated files alongside manually uploaded or vendor-provided captions. There is no API flag to distinguish ASC-generated from manually uploaded captions; check the session creation date against caption file creation date (ASC captions are generated within 30–60 minutes of recording completion).

Format: SRT. All Panopto captions are exported in SRT format regardless of the original upload format. For destination LMS platforms that require VTT (Workday Learning, some Kaltura configurations), convert SRT to VTT after export.

Risk: Panopto's ASC accuracy on technical and domain-specific content is generally below WCAG 2.1 AA threshold (80–86% WER range for OSHA, engineering, and medical content in our benchmarks — see the Whisper accuracy benchmarks by vertical for context on what this means in practice). Treat all Panopto ASC-generated captions as unverified in the coverage inventory and run the Day 3 accuracy spot-check on Tier 1 assets before migrating.

SAP Litmos (source)

SAP Litmos stores caption files as module-level attachments. The platform supports manually uploaded SRT, VTT, and SBV files through the module editor. Litmos also has an AI Captions feature (using Google Speech-to-Text) that stores generated captions in a separate platform-managed database layer.

Export method: For manually uploaded caption files: in Litmos Admin, navigate to the module, click Manage → Content, and download the caption file from the caption attachment list. For bulk export, use the Litmos REST API's GET /modules/{id} endpoint — caption attachment URLs are available in the captions array of the response. For Litmos AI Caption files: these are NOT downloadable as standalone files through the standard Litmos interface or API. If your catalogue has a significant proportion of AI Caption tracks, plan to re-caption those modules at the destination LMS.

Risk: The inability to export AI Caption tracks as standalone files is the primary Litmos source migration risk. Build a column in the coverage inventory for caption type (manually uploaded vs. AI Caption) and identify the re-captioning scope before migration planning is finalised. Modules with AI Captions that are Tier 1 priority need a re-captioning plan that can execute within the migration cutover window.

LearnUpon (source)

LearnUpon stores caption files as course content attachments. The storage structure varies by plan tier and content type. For SCORM-based courses, caption files may be embedded within the SCORM package. For native video courses, caption files are stored at the module level as sidecar attachments.

Export method: Download the full course ZIP from LearnUpon Admin → Courses → Export. Extract the ZIP and inspect the folder structure. Caption files for native video courses are typically in a /captions/ subfolder. For SCORM-based courses, look in the SCORM package's /assets/, /content/, or /captions/ subfolder. If the SCORM package does not contain a caption file, the captions may be served by the LMS as sidecar files — download these from the module's caption management UI.

Risk: LearnUpon's caption implementation varies enough between plan tiers and content types that there is no single export path. Budget 30–40 minutes to inspect the structure of a representative sample of course exports before building the export automation script.

Absorb LMS (source)

Absorb LMS stores manually uploaded caption files (VTT and SRT) as course object content attachments accessible through the Course Builder. Absorb also has an Intelligent Assist feature that includes auto-captioning for course videos, stored separately.

Export method: In Absorb Course Builder, navigate to the video course object, click on the caption track, and download the file. For bulk export, use the Absorb REST API's GET /courses/{id}/chapters/{id}/lessons endpoint, which returns lesson-level metadata including caption file attachment URLs. Download each file and name it by the lesson ID to maintain the mapping.

Risk: Absorb Intelligent Assist auto-captions are the primary risk. Like Litmos AI Captions, these platform-generated tracks are stored separately from manually uploaded files and may not be exportable in the same way. Identify which lessons use Intelligent Assist captions vs. manually uploaded files before building the export plan.

Bridge LMS (source)

Bridge LMS (by Instructure) stores caption files as course content attachments. Bridge does not provide a bulk caption export API or admin export tool — caption files must be downloaded one by one through the Bridge Admin course content editor. For catalogues larger than 50 videos, this is a significant time investment.

Export method: In Bridge Admin, navigate to Content → select the course → select the video → click the caption track → download. There is no API endpoint that provides direct caption file download URLs. For the Bridge API, use GET /courses/{id}/contents to retrieve content metadata — caption file information may be in the metadata, but the download URL requires a separate API call to the Bridge media delivery endpoint, which requires authentication and is not documented in the public API reference.

Risk: Bridge's Practice video role-play recordings are a specific edge case. Practice recordings are structured as learner submissions (recorded video + assessor feedback) and their transcript files are not interchangeable with standard caption files. If your Bridge catalogue includes Practice modules that are required to be accessible, plan a separate workflow: export the recording, generate a new caption file from scratch using a compliant captioning tool, and upload to the destination LMS as a standalone video with caption.

Per-destination-LMS import checklists

The checklists below cover the most common destination platforms. Each covers: accepted caption file formats, the import mechanism (UI vs. API), platform-specific gotchas (auto-generation clobber, format validator strictness, metadata re-entry requirements), and the validation step to confirm successful delivery.

Docebo (destination)

Docebo accepts VTT caption files in its native video hosting (Docebo Central Repository). For enterprise deployments using Kaltura as the video host, captions must be uploaded directly to Kaltura — Docebo does not intermediary the caption upload to the Kaltura layer.

Import mechanism: For Docebo Central Repository: navigate to Admin → Learning Object → select the video → Captions tab → Upload. Supports VTT only (SRT is not accepted natively). For Kaltura-hosted Docebo deployments: use the Kaltura Caption Asset API to upload caption files directly to the Kaltura entry. Set the language code, label ("Captions"), and default flag via the API — these metadata properties will flow through to the Docebo player.

Auto-generation clobber risk: Medium. Docebo generates auto-captions (via the REACH service if Kaltura is the host, or via a built-in ASR if Central Repository) for any video uploaded without an existing caption track. Upload the caption file within the same session as the video import — before Docebo's auto-generation job triggers — to avoid creating a parallel auto-generated track.

Metadata: Language code and label must be set manually for each uploaded track. Default-on setting is configured at the player level in Docebo (not per track), so verify the player default caption setting is set to "on" after migration.

Workday Learning (destination)

Workday Learning requires WebVTT format specifically. The file must begin with a WEBVTT file header on the first line. Files without this header are rejected at upload time with a validation error. This is the strictest format validator of any major LMS platform.

Import mechanism: In Workday, navigate to Learning Content → Edit the learning object → Media Content → Upload Caption File. SRT, TTML, and SBV files are not accepted directly — convert all caption files to WebVTT before upload. For the conversion, ensure the WEBVTT header is added, the timestamp format is preserved (HH:MM:SS.mmm format with millisecond precision), and there are no invalid characters in the text.

Auto-generation clobber risk: Low. Workday does not auto-generate captions on video import. A video uploaded without a caption file will show no captions — it will not generate captions automatically.

Metadata: Workday Learning's learning object database stores the language tag and caption track metadata. These must be set via the Workday Admin UI per learning object — there is no bulk import for caption metadata. Allow 2–3 minutes per learning object for metadata entry.

Kaltura (destination)

Kaltura accepts all caption file formats (SRT, VTT, DFXP/TTML, SBV) and has the most capable bulk import API of any platform covered here. This makes Kaltura the lowest-friction destination for caption migration.

Import mechanism: Use the Kaltura Caption Asset API's POST /service/caption_captionasset/action/add endpoint to create a caption asset record, then POST /service/caption_captionasset/action/setContent to upload the caption file. The add call accepts: entry ID, language code, label, default flag, and format. Automate with a script that reads the export CSV from the source LMS and loops through to upload each file. Validation: after upload, use GET /service/caption_captionasset/action/list to confirm all caption assets are present and in READY status.

Auto-generation clobber risk: Low if REACH is not configured as default. If your Kaltura configuration has REACH set to automatically generate captions for all new entries, disable REACH default auto-generation at the account level before the migration content import begins, then re-enable after caption file upload is complete.

Cornerstone OnDemand (destination)

Cornerstone accepts VTT and SRT files uploaded per content object via the content management UI. Cornerstone's auto-captioning (Azure Cognitive Services) is triggered on video import for content objects without an existing caption track — this is the highest auto-generation clobber risk of any destination platform.

Import mechanism: After importing the content object, navigate to Content → Manage Online Training → select the content object → Media Caption → Upload Caption File. Upload the VTT or SRT file within the same session as the content import — ideally within 5 minutes — to pre-empt the auto-caption generation job. If auto-captioning has already run, the generated track appears in the Media Caption list alongside any uploaded tracks. Delete the auto-generated track explicitly — it does not disappear when a manual upload is added.

Auto-generation clobber risk: High. To prevent auto-generation from running on any content during migration, submit a support ticket to Cornerstone to temporarily disable the auto-caption feature at the tenant level. This is standard practice for large content migrations and Cornerstone support is familiar with the request.

TalentLMS (destination)

TalentLMS accepts VTT files uploaded per course unit via the course editor. SRT files can be converted to VTT using TalentLMS's built-in conversion — but the conversion result should be validated, as TalentLMS's SRT-to-VTT converter does not always add the WEBVTT file header.

Import mechanism: In the TalentLMS course editor, open the video unit, click "Add Captions," and upload the VTT file. There is no bulk caption upload API. For a catalogue of 300+ video units, plan 2–3 minutes per unit for the UI-based upload, including navigating to the unit, uploading, and saving.

YouTube embed gotcha: TalentLMS courses that embed YouTube videos display YouTube auto-captions by default. You can upload a VTT file alongside the YouTube embed URL — TalentLMS will prioritise the uploaded VTT over the YouTube auto-captions. This override is the correct approach: it gives learners the verified, compliant caption track rather than YouTube's auto-generated track. Do not assume YouTube auto-captions are sufficient — they typically achieve 80–88% WER on domain-specific training content.

SAP Litmos (destination)

SAP Litmos accepts SRT, VTT, and SBV files uploaded per module via the module editor. The Litmos AI Captions feature (Google Speech-to-Text) auto-generates captions for video modules uploaded without existing caption files — disable this feature at the account level during the migration import phase to prevent unverified auto-generated tracks from appearing in the destination system.

Import mechanism: In the Litmos Module editor, navigate to the video module, click "Add Subtitles/Captions," select the language, and upload the file. There is no bulk upload API for caption files — plan approximately 2 minutes per module for the UI workflow.

LearnUpon (destination)

LearnUpon accepts VTT and SRT files uploaded per module. For SCORM-based courses where captions are embedded within the SCORM package, the package is uploaded as a whole — caption files within the package are served by the SCORM player without separate upload.

Import mechanism: For native video modules: in the LearnUpon Course Builder, select the video module, click the Captions tab, and upload the VTT or SRT file. For SCORM-based courses with embedded captions: upload the SCORM package — the embedded captions will be served from within the package. Validate post-upload by playing the SCORM content as a learner and confirming caption delivery.

360Learning (destination)

360Learning accepts SRT and VTT files uploaded per video activity in the course editor. 360Learning's collaborative learning architecture means video activities can be reused across multiple courses — uploading a caption file to a video activity makes it available in every course that uses that activity, which is the highest-leverage caption upload in the platform.

Import mechanism: In 360Learning, navigate to the course, open the video activity, click the captions icon, and upload the SRT or VTT file. Set the language and verify the track label. There is no bulk API for caption upload; plan 2 minutes per video activity.

Rippling LMS (destination)

Rippling LMS accepts VTT and SRT files for custom content uploaded to the platform. Rippling's automated training assignment engine (which assigns compliance training based on employee attributes) makes caption coverage critical: if a required training module reaches an employee with a hearing disability and has no compliant caption track, the accommodation failure is immediate and documented in the system.

Import mechanism: In Rippling Admin, navigate to the LMS module, click Content, and upload the caption file alongside the video. Caption upload is part of the standard content creation workflow. Validate delivery by checking the module in a learner view.

Thought Industries (destination)

Thought Industries (the platform behind Intellum, Eurekos, and LearnWorlds for enterprise customer education) accepts caption files uploaded per content item. The multi-Region architecture (used by enterprise customers with multiple academy brands) means caption upload applies to a specific Region's content catalogue — a video shared across Regions may need separate caption upload per Region depending on the Thought Industries deployment configuration.

Import mechanism: In Thought Industries Admin, navigate to Content Items, select the video, and access the Captions panel to upload the file. For multi-Region deployments, confirm with the Thought Industries account team whether captions attached to a content item in one Region automatically propagate to other Regions that use the same content item, or whether separate uploads are required per Region.

The caption freeze window

The caption freeze window is the period during which caption workflow breaks down because migration activity has disrupted normal production operations. It is the most consistently overlooked caption compliance risk in LMS migrations — not because it is complex to manage, but because it is never on anyone's checklist.

The freeze window creates a specific failure mode: training content continues to be published during the migration cutover period, but caption production is disrupted. The captioning vendor integration is in transition (the source LMS integration is being wound down, the destination LMS integration is not yet live), the content intake process has changed, and the team is focused on migration validation rather than new production. Content published during this period arrives in the destination LMS without captions — sometimes immediately, sometimes delayed until after the migration completes.

Typical freeze window duration

For a straightforward LMS-to-LMS migration (single platform, no video hosting change, under 500 content objects): 5–10 business days. For a complex migration (new video hosting platform, multi-region deployment, over 1,000 content objects): 3–6 weeks. During this window, any training content with a mandatory compliance obligation — ADA Title II public-entity training, Section 508 federal agency training, mandatory employee onboarding — is an accessibility compliance risk the moment it is published without captions.

Three management options

Option A: Publish freeze. Declare a freeze on all new training content publication for the duration of the migration cutover. No new videos enter either LMS during the freeze. This is the cleanest option from a compliance perspective — the caption freeze window doesn't exist if no new content is published during the migration. The cost is operational: L&D teams that publish frequently (weekly releases for sales training, regulatory training calendars) cannot absorb a 2–6 week publication freeze without significant business impact.

Option B: Destination-first routing. From the moment the destination LMS is provisioned, all new content is published exclusively to the destination LMS. The source LMS becomes read-only. The captioning vendor integration is set up in the destination LMS from day one of migration, so new content in the destination LMS has a functioning caption production workflow. This requires the destination LMS to be at least partially operational before migration is complete — learners may need to access two systems for a period (the source LMS for existing content, the destination LMS for new content). The compliance risk is managed: new content in the destination LMS has compliant captions; existing content is migrated from the source LMS on the normal migration timeline.

Option C: Freeze window log with remediation SLA. Accept the caption freeze window and manage it with a log and a remediation commitment. Any content published during the freeze window is logged immediately, with a maximum 48-hour remediation SLA for Tier 1 priority content (mandatory compliance training, safety training) and a maximum 10-business-day SLA for lower-priority content. The log is shared with the compliance officer. The freeze window content is treated as a known remediation queue, not a compliance gap — the documentation of the known gap plus the committed remediation timeline is what distinguishes "managed compliance risk" from "wilful non-compliance" in an OCR investigation.

Option A is the cleanest, Option B is the most operationally sustainable, and Option C is the most common. Whatever option is chosen, the decision should be documented before migration starts and communicated to all content authors who publish to the LMS during the migration period.

Content published during the freeze window: identification and remediation

After the migration completes, run a post-migration coverage audit (Day 1 of the validation protocol below) and filter for content with a creation date that falls within the freeze window. This is the freeze window remediation queue. Apply the normal caption production workflow to each item, prioritising by compliance tier. For the full tier classification framework, see the LMS caption audit methodology. For the production workflow that should be operating at the destination LMS by the time these items reach the remediation queue, see the compliance program build post.

Post-migration validation protocol

Post-migration caption validation should complete within 48 hours of migration cutover. The validation protocol is a compressed version of the pre-migration audit — the same five data types, checked against the pre-migration baseline to confirm what survived and what needs remediation.

Step 1: Coverage delta check

Compare the coverage inventory from the pre-migration audit against the post-migration coverage report from the destination LMS. Every asset that had a caption file in the source LMS should have a caption file in the destination LMS. Run the destination LMS's content export or API report to generate a post-migration coverage list. Any asset in the source coverage inventory that is not in the post-migration coverage list is a migration failure — it should have a caption file and doesn't.

For the assets that are missing from the post-migration coverage report: check the migration log to confirm the content object was migrated successfully. If the content object migrated but the caption file is missing, the caption file was not included in the migration payload — retrieve it from the pre-migration export folder and upload manually to the destination LMS. If the content object was not migrated at all (migration failure), escalate to the migration team before attempting caption remediation.

Step 2: Format validation in situ

For a random 10% sample of migrated caption tracks, play the video in the destination LMS player (as a learner, not as an admin) and confirm: (a) the caption track is visible and can be enabled, (b) the caption text appears at the correct timing relative to the audio, (c) the caption display does not cut off text or show encoding artifacts. Any caption track that fails this in-player check needs to be re-validated and re-uploaded.

Step 3: Track metadata verification

For the same 10% sample, check the track metadata in the destination LMS admin UI: language code, label, track type, and default on/off setting. Compare against the pre-migration metadata export. Any metadata that was lost in migration (missing language code, wrong label, default off when it should be on) needs to be corrected in the destination LMS admin UI per asset.

Step 4: Glossary connection test

Submit a 60-second sample of the most vocabulary-dense content in the catalogue to the destination LMS's caption production workflow. Use the same sample clip that was used in the Day 4 glossary validation during the pre-migration audit. Compare the output: if the domain-specific terms that were correctly transcribed by the glossary-tuned model in the pre-migration test are now incorrectly transcribed (LOTO → "lotto," kubectl → "cube cuddle," tirzepatide → "tier zip a tide"), the glossary connection is broken. Contact the captioning vendor to verify the customer identifier configuration in the destination LMS integration before any new caption production jobs are submitted. The caption feedback loop post has a worked example of what glossary accuracy looks like in a functional vs. broken integration.

Step 5: Compliance documentation continuity check

Verify that the offline compliance archive (the accuracy history export from Day 5 of the pre-migration audit) is accessible in the shared drive location defined before migration. Spot-check five entries in the archive against the post-migration destination LMS content IDs — the archive entry's source asset ID may need to be cross-referenced to the destination asset ID using the migration ID mapping table. If the cross-reference mapping is missing, create it now by comparing source LMS titles to destination LMS titles (this is a manual process if the migration tool did not produce an ID mapping table). The compliance archive must remain accessible regardless of the migration's outcome — it is the documentation trail for pre-migration content and must survive both LMS platforms.

Eight failure modes

1. Assuming video transfer equals caption transfer

The most frequent LMS migration caption failure. The migration tool successfully copies the video file (or the content object metadata that references the video on an external host), the migration log shows success, and the L&D team considers captions handled. The video plays in the destination LMS with no caption track. No error is thrown at any point in the migration process. The failure is discovered at first learner complaint, at the next accessibility audit, or — in the worst case — at an OCR complaint. This failure is completely preventable with the pre-migration coverage inventory and the source-specific export checklists above.

2. Missing the track metadata export

Caption files migrate but track metadata does not. The destination LMS receives the VTT files but has no language code, no label, no track type, and no default-on setting. The caption track appears in the player menu without a label (or with a placeholder like "Track 1") and is defaulted to off. Learners who need captions must navigate an unlabelled player menu to find and enable an unnamed track — which is not accessible delivery. This failure is prevented by exporting track metadata alongside caption files in the source LMS and re-applying it as part of the destination LMS import checklist.

3. Auto-generation clobber

The destination LMS (most commonly Cornerstone OnDemand or Panopto, which auto-generate captions for any video imported without an existing caption track) triggers auto-captioning on the migrated content before the validated caption files are uploaded. The auto-generated track appears in the caption menu alongside or instead of the validated track. The post-migration coverage report shows caption presence for the asset — technically true — but the active track is the auto-generated version with an unknown accuracy level. This failure is prevented by uploading validated caption files immediately after content object import, or by temporarily disabling the destination LMS's auto-generation feature at the tenant level during the migration window.

4. Glossary detachment

New caption production in the destination LMS runs against the default ASR model instead of the per-customer vocabulary model. The captions that are generated look like normal captions — they have timestamps, text, and reasonable general-vocabulary accuracy (95–97% WER on clean audio with no domain-specific terms). The failure surfaces on the first piece of domain-specific content captioned post-migration: OSHA citation codes are garbled, product names are substituted, drug names are broken into phonemic approximations. This failure is prevented by the Day 4 glossary connection test in the pre-migration audit and the Step 4 glossary test in the post-migration validation. It is also documented — the customer glossary architecture post covers the full architecture of how glossary connections are established and what can break them.

5. Compliance documentation loss

The source LMS and its captioning vendor integration are decommissioned without exporting accuracy records and QC logs. Post-migration, the compliance officer asks for the accuracy documentation for a pre-migration video that is the subject of an accessibility complaint. The captioning vendor's dashboard shows the destination LMS's integration history — the source LMS history has been archived or deleted. The organisation cannot produce a compliance record for content that was demonstrably WCAG-compliant before the migration. This failure is prevented by the Day 5 accuracy history export in the pre-migration audit. It is a process failure, not a technical one — the data existed and was not exported before the decommissioning deadline.

6. Format validation skipped

Caption files are exported from the source LMS in one format and uploaded to the destination LMS without format conversion or validation. The destination LMS's player rejects the file (Workday Learning's WebVTT validator is the most common trigger), which manifests as no captions on a video whose migration record shows a successfully uploaded caption file. Alternatively, the file is accepted by the destination LMS but fails to play correctly due to timestamp format anomalies — captions appear at wrong times, overlap, or disappear without warning. This failure is prevented by the Day 2 format validation step in the pre-migration audit and by reviewing the per-destination-LMS import checklist for format requirements before uploading.

7. Caption freeze window not managed

The migration team does not designate a freeze window management plan. Content authors continue publishing new training content to the source LMS during cutover, which either stays in the source LMS (and has to be migrated separately post-cutover) or is published to the destination LMS without going through the caption production workflow (which hasn't been set up in the destination LMS yet). The result: a cohort of content in the destination LMS with no caption files, published during the migration window, with no remediation log and no visibility to the compliance team until a learner report surfaces the problem. This failure is prevented by the three-option freeze window management plan documented above — choose one and document the choice before migration starts.

8. YouTube embed caption oversight

Training content that uses YouTube embeds is migrated to the destination LMS with the YouTube embed URL intact. In the source LMS, a verified VTT file was uploaded alongside the YouTube embed, overriding the YouTube auto-captions. The destination LMS's import recreates the YouTube embed but does not import the override VTT file — the destination LMS player now serves YouTube auto-captions instead of the verified file. The coverage report shows captions present (YouTube auto-captions are serving), and the accuracy check is not run because captions appear to be present. This failure is prevented by explicitly flagging all YouTube-embedded content in the pre-migration coverage inventory and including the override VTT file upload as a required step in the destination LMS import checklist for YouTube-embedded content.