How to switch captioning vendors: porting your glossary, managing the backlog, and the accuracy reset problem

When to consider switching captioning vendors

Vendor transitions in captioning are high-cost events. The accuracy reset alone can represent six to twelve months of productivity loss as the new vendor's model relearns your vocabulary. That cost should be weighed against a concrete, quantified gap between what your current vendor delivers and what a replacement delivers. Switching on the basis of a single frustrating experience, a competitor's pitch at a trade show, or a colleague's recommendation without benchmarking the accuracy difference is how L&D teams end up in a worse position twelve months after the switch than they were in before it.

The legitimate triggers for a vendor switch fall into four categories: accuracy stagnation, contract-renewal restructure, vendor-side change, and capability gap. Accuracy stagnation occurs when the vendor's product has not improved to the level required for WCAG 2.1 AA compliance on your training content despite a structured correction and glossary-building effort over 12 months. If you have implemented the feedback loop with consistent correction submissions and your measured accuracy is still below the 99% threshold on domain-specific content, the current vendor's system may have a vocabulary ceiling for your content type that it cannot cross.

Contract-renewal restructure is the second trigger. At contract renewal, vendors sometimes restructure pricing — increasing per-minute rates, removing grandfathered volume tiers, or introducing a minimum-commitment floor that does not match your actual consumption volume. If the renewal terms change the unit economics of the relationship materially, the switch cost may be smaller than the cost of the new contract terms over the next two years. The pricing breakdown post provides a comparison of per-minute versus flat-monthly pricing models; the crossover point where the flat-monthly model outperforms per-minute at your consumption volume is the financial benchmark for renewal negotiations.

Vendor-side change is the third trigger. Captioning vendors are acquired, pivoted, or sunset at a meaningful rate. If your vendor's product roadmap has shifted away from training-content use cases, if the vendor has been acquired by a competitor with a different pricing model, or if the vendor's human-review team has been replaced with a lower-cost ASR pipeline that no longer hits your accuracy standard, the vendor's side of the contract has effectively changed even if the legal terms have not. Document the capability degradation against a specific measurement — the QA spot-check protocol gives you the measurement framework — before concluding that the degradation is permanent rather than a recoverable service incident.

Capability gap is the fourth trigger. Your content programme may have grown into needs that the current vendor cannot address: multilingual output where the vendor supports only English, HIPAA BAA requirements that the vendor cannot meet, LMS integrations the vendor does not support natively, or glossary-based accuracy on vocabulary categories (medical drug names, engineering SDK terms, legal citations) that the vendor's ASR model cannot be tuned to handle. Capability gaps should be confirmed by a structured pilot with a replacement vendor — not by the replacement vendor's sales deck — before they justify the switch cost.

The contract renewal window as the natural switch point

The lowest-cost time to switch captioning vendors is within the 60–90 day window before the auto-renewal date. If your current contract has an auto-renewal clause — and most do — the notice period to avoid auto-renewal is typically 30 to 60 days before the renewal date. The window opens 90 days before renewal: enough time to run a pilot on the replacement vendor, complete glossary export, negotiate termination mechanics, and plan the parallel-run period before the current contract lapses. Switching inside this window avoids early-termination fees, which in most captioning contracts are structured as the balance of the committed contract value for the remaining term. An early termination from a 24-month contract at month 14 could mean ten months of committed spend that becomes the exit cost. The contract checklist item on termination-for-cause rights is relevant here: a vendor that has consistently missed accuracy thresholds or SLA commitments gives you a legitimate cause-based termination right that avoids early-termination fees. Document the SLA breaches and accuracy failures in writing before giving notice if you intend to use a for-cause termination.

What you own and what the vendor owns

The most consequential question in a vendor transition is not which replacement vendor to choose — it is what you actually own in the current relationship versus what the vendor owns and retains on exit. Getting this wrong means arriving at the replacement vendor without the assets that drove your current accuracy level, and paying to rebuild them from scratch.

The glossary: your IP, if the contract says so

The per-customer glossary — the term list that biases the ASR model toward your specific vocabulary — is your IP if your contract explicitly establishes that. Many captioning vendor contracts are silent on glossary ownership, which creates a legal grey area. Silence on IP ownership in a vendor contract typically defaults to whatever the contract's governing law provides, which for SaaS contracts often means the vendor retains what it creates, including custom configurations. If your contract does not contain explicit language stating that the glossary you contributed is your property and is exportable on demand in a documented format, you may not own the right to take it with you. Review the glossary ownership section of the contract checklist before assuming portability. If you are mid-contract and the ownership clause is silent or unfavourable, this is a negotiation to have now — before you give notice — rather than during the exit conversation when your leverage is lowest.

The glossary architecture post covers how a well-structured per-customer glossary is built: the term sourcing from existing documentation, the pronunciation and variant handling, the domain-specific vocabulary categories, and the maintenance cadence that keeps the glossary current as your product vocabulary evolves. That architecture document is what you should export from your current vendor and import into the replacement vendor's system. The export format matters: a vendor-specific proprietary format that cannot be imported into the replacement vendor's system without manual transformation is a switching barrier. A CSV or JSON export of term–phonetic-pronunciation–variant triples is portable to any system. Request the export in a documented open format, not in a vendor-proprietary format, before giving notice.

The trained model: not your IP

The accuracy improvement you have experienced over 12–24 months of correction submissions is partly the result of your glossary and partly the result of the vendor's ASR model being fine-tuned on correction signal from your submissions. The fine-tuned model is the vendor's IP, not yours, in every standard captioning vendor contract. When you switch vendors, the model improvement does not move with you — only the glossary does. This is the accuracy reset problem: the replacement vendor starts with their base model, not with the customised model that reflects your content's vocabulary patterns. The compounding accuracy documented in the feedback loop post was produced by both glossary biasing and model adaptation. You keep the glossary; you lose the model adaptation.

This is a calibration point, not a reason not to switch. If the replacement vendor's base model plus your ported glossary outperforms the current vendor's fine-tuned model — which a structured pilot will determine — then the accuracy reset is acceptable. The pilot design in the parallel-run section below is designed to answer this question with data rather than assumption.

Audio files: retention and deletion

Your training video audio files are processed by the vendor's transcription system. Under most captioning vendor contracts, the vendor retains processed audio for 30–90 days post-delivery for quality-assurance purposes. The contract should specify an explicit retention window and a deletion obligation on termination. Under HIPAA, if any of your training content contains PHI, the BAA you have signed with your current vendor governs what the vendor does with the audio on termination — specifically, whether they are required to return or destroy the PHI-containing audio and within what timeframe. If you have a HIPAA BAA with your current vendor, confirm the audio-destruction or return obligation before giving notice and document the vendor's compliance. This is covered in more detail in the contract checklist post's BAA provisions section; the transition point is to ensure the termination process includes a data-return or deletion confirmation for any PHI-bearing content.

Caption files: yours

The delivered caption files — the SRT, VTT, or TTML files the vendor has produced for your content — are deliverables you have paid for. They are unambiguously your property. If you have not already downloaded and archived the complete set of delivered caption files, do so before giving notice. Vendors' systems may not retain the delivery history indefinitely, and the risk during a contested termination is that the vendor's self-service download interface becomes unavailable while the commercial dispute is unresolved. Maintain a local or shared-storage archive of all delivered caption files indexed by video ID. This archive is also the starting point for the backlog-transfer decision described below.

Correction history: often stranded

The correction history — the record of which words were corrected, how, and how many times — is what drives model fine-tuning. In most captioning vendor platforms, the correction history is stored in the vendor's proprietary system and is not exported as part of the standard data return. It is not your IP in any formal sense (the vendor's model uses it, not you directly), but it has practical value: if you could reconstruct it as a set of correction patterns, you could pre-seed the replacement vendor's model with a correction signal that partially offsets the accuracy reset. Ask your vendor whether the correction history is exportable as a structured data set before giving notice. Some vendors will provide a correction export as part of a transition assistance SLA; most will not unless it is negotiated explicitly.

The accuracy reset problem in practice

The accuracy reset problem is the single biggest risk in a vendor transition, and it is the risk most often underestimated by L&D teams who have never switched captioning vendors before. Understanding it concretely before the switch helps you size the risk correctly and plan around it.

What resets and what does not

When you move to a replacement vendor with your exported glossary in hand, the replacement vendor applies your glossary terms to their base ASR model. The initial accuracy on your content will be the replacement vendor's base model accuracy plus the lift from your glossary — which, depending on the quality of your glossary and the vocabulary density of your content, may land anywhere from 91% to 97% on domain-specific video in the first batch. The pre-switch accuracy you had achieved — say, 98.5% on engineering onboarding content after 18 months of correction feedback — will not be replicated immediately. The gap between 98.5% (prior vendor, mature model) and 93% (new vendor, clean start with your glossary) represents the accuracy investment you built through the correction cycle, translated into concrete terms: more corrections per video required, more L&D editor time, more compliance risk during the gap period before the new model reaches the prior vendor's maturity level.

The accuracy post explains why this matters for WCAG compliance: the difference between 93% and 99% accuracy on a 10-minute training video is approximately 20 errors per video (at 200 words per minute, 10 minutes = 2,000 words; 7% error rate = 140 errors vs 1% error rate = 20 errors). Each of those additional 120 errors requires a human correction decision. At the correction labour cost model of 4 minutes per correction decision (review + context + edit), 120 additional errors per video adds 8 labour-hours per video to the compliance budget. For an L&D team processing 30 new videos per month, the accuracy reset from 98.5% to 93% translates to approximately 240 additional staff-hours of correction labour per month during the transition window before the new vendor's model matures. That number should be built into the transition business case.

How long the reset lasts

The duration of the accuracy reset depends on the replacement vendor's model architecture and their correction ingestion pipeline. Vendors using a pure glossary-bias approach (no model fine-tuning from corrections) will maintain a stable accuracy level from day one, determined entirely by the glossary quality and the base model. Vendors using correction-fed fine-tuning will start at a lower accuracy than the current vendor's mature model and improve toward that level as correction signal accumulates — typically over a 3–6 month window, depending on submission volume and correction-cycle cadence. Ask the replacement vendor specifically: how does correction signal feed into model improvement, how long does the model improvement cycle take from correction submission to accuracy change, and what is the expected accuracy trajectory on a corpus of the size and vocabulary type you are bringing? These are quantified questions that the vendor's customer success team should be able to answer with reference customer data. If they cannot, that is a signal about the maturity of their fine-tuning pipeline.

Mitigating the reset with glossary depth

The accuracy reset is shallower when the ported glossary is comprehensive. A glossary that covers only the highest-frequency proper nouns (the top 50 product names and team names, say) will produce a shallow improvement from the base model. A glossary built to the architecture in the glossary architecture post — covering product names, release names, team names, SDK symbols, competitor names, clinical terms, and pronunciation variants for each — will produce a deeper improvement because it targets the vocabulary that causes the most errors in the base model. Before the switch, invest in expanding and cleaning your glossary export to the full architecture depth. A well-structured glossary transferred at day one is the fastest mitigation for the accuracy reset.

Porting your glossary before switching

Glossary export and preparation is the highest-leverage pre-switch action. It should be completed before you give notice to the current vendor — not during the exit conversation, where the vendor has an incentive to complicate or delay the export, and not after you have cancelled the contract and lost access to the self-service export tool.

Step 1: Export the current glossary in full

Log into your current vendor's platform and export the glossary in every format available. Most platforms offer CSV export; some offer JSON. Download both if available. The export should include every term, pronunciation hint, and variant tag that has been added over the contract term. If the platform's self-service export tool omits terms added by the vendor's support team on your behalf (sometimes the case when custom-term additions were handled through a support ticket rather than the self-service UI), open a support ticket requesting a complete glossary export. Document the export date and term count so you have a record of what you received.

Step 2: Clean and structure the export

The exported glossary from most captioning vendor platforms is formatted for that platform's import tool, not for a generic downstream import. Before importing into the replacement vendor's system, clean and restructure the export to the architecture in the glossary architecture post. The key fields to preserve or reconstruct are: the canonical term spelling (exactly as it should appear in the output), the phonetic pronunciation or pronunciation note (how the speaker says it, not how it is spelled — especially important for acronyms pronounced as words, drug names with non-obvious stress patterns, and product names that diverge from their spelling), the variant spellings (alternate capitalisation, hyphenation, or abbreviations for the same term), and the domain tag (which vocabulary category the term belongs to, for maintenance prioritisation). A raw CSV export of terms without pronunciation notes is a partial glossary; the pronunciation layer is what drives the accuracy lift on terms the base model has not seen before.

Step 3: Expand the glossary before porting

The switch is an opportunity to rebuild the glossary to a higher standard than the one you are leaving with. Most L&D teams' captioning glossaries at the 12–24 month mark are a growth artefact: terms were added reactively as errors surfaced rather than proactively by domain review. The result is a glossary with good coverage of the vocabulary in your most-watched training videos (where errors were caught and corrected) and poor coverage of vocabulary in less-watched content or recently produced content. Before porting, audit the glossary against the current vocabulary documented in your product knowledge base, Confluence, Notion, or whatever source-of-truth your glossary sourcing process drew from. Add the terms that have been added to those sources since the last glossary refresh and have not yet surfaced as caption errors. A proactively expanded glossary ported to the new vendor on day one reduces the accuracy reset window relative to porting only the reactive-growth glossary.

Step 4: Test the import with the replacement vendor before cutting over

Before giving notice to the current vendor, test your exported glossary import with the replacement vendor on a sample submission. Upload a batch of 5–10 training videos that represent your vocabulary diversity — high-proper-noun-density engineering onboarding content, medical terminology content, a general L&D module, a sales enablement clip — and measure the accuracy against the DCMP Captioning Key protocol used in your QA spot-check process. The result tells you two things: whether the glossary import worked correctly (the terms are being applied in the output) and what the day-one accuracy baseline is on your content with the new vendor. This is the baseline for the parallel-run comparison described below.

Managing the back-catalogue backlog during the transition

The back-catalogue question — what to do with the existing library of captioned training videos when you switch vendors — is the most expensive decision in a vendor transition and the one most often made by default rather than by design. The default is to keep all existing captions delivered by the current vendor and use the new vendor only for new submissions going forward. This is often the right decision, but it should be a deliberate choice based on a structured assessment, not an assumption.

Assessing the existing backlog quality

Before deciding whether to re-caption any portion of the existing library with the new vendor, assess the accuracy of the existing captions against the WCAG compliance threshold. The LMS caption audit methodology provides the spot-check protocol: sample 10% of the library across content types and vintage (recently produced, 12-month-old, legacy pre-captioning-programme content), apply the DCMP spot-check to each sample, and classify the library into three tiers: compliant (99%+ on the spot-check), borderline (95–99%, likely compliant but within the error margin), and non-compliant (below 95%, requires remediation). The non-compliant tier is the re-captioning candidate. The compliant and borderline tiers can be kept as delivered.

This assessment often surfaces a more nuanced picture than the two-tier "old vendor's work vs. new vendor's work" frame: the non-compliant content may be concentrated in the legacy pre-programme content that was captioned in bulk at the start of the relationship, before the glossary was built and the accuracy tuning was complete. The content captioned in the last 6–12 months of the current-vendor relationship — the mature-glossary period — may be perfectly compliant and not worth re-captioning. This assessment is worth doing before the switch, not after, so you can scope the re-captioning budget into the transition business case.

The re-captioning decision matrix

Re-captioning decisions should be made on three criteria: compliance status (non-compliant content requires remediation regardless of vendor); viewership and training-criticality (high-viewership compliance training warrants faster remediation than low-viewership archived content); and vocabulary currency (content produced before the current glossary was built may have systematic proper-noun errors that would improve dramatically with the new vendor's model plus the current glossary, even before correction tuning). Non-compliant content in the high-viewership, compliance-critical tier should be scheduled for re-captioning in the first 90 days with the new vendor. Non-compliant content in the low-viewership, archived tier can be queued for opportunistic re-captioning as bandwidth allows. Compliant content should not be re-captioned — the labour and cost are not justified by the accuracy improvement.

One counterintuitive case: content that was captioned pre-glossary by the current vendor and is technically compliant (98%+) on general vocabulary but still has systematic errors on your specific proper nouns. This content is compliant per WCAG but may not be usable as a training tool because the proper-noun errors undermine comprehension on exactly the terms learners need to retain. Whether to re-caption this content is a training-effectiveness decision, not a compliance decision. The answer depends on the importance of the proper-noun accuracy to the learning outcome in those specific videos, which the content authors are better positioned to judge than the compliance team.

Freeze window and the LMS migration analogy

The vendor transition has a natural freeze window — a period during which new submissions should not be split between vendors — that is structurally similar to the freeze window in an LMS migration. As described in the LMS migration caption checklist, splitting submissions across two systems during a migration creates caption files with inconsistent metadata, format variants, and glossary versions that are difficult to reconcile after the cutover. The same applies to a vendor transition: ideally, new submissions go to only one vendor at a time. The parallel-run period described below is an exception to this rule, and it requires careful management to avoid the metadata inconsistency problem.

The freeze window recommendation for a vendor transition is: stop submitting new content to the current vendor on the last day of the parallel-run period, route all new submissions to the new vendor from that point forward, and complete the backlog-transfer re-captioning within 90 days of cutover. This produces a clean timestamp boundary: all content submitted before the cutover date exists in both systems' delivery history; all content submitted after the cutover date is the new vendor's responsibility. The LMS delivery configuration should be updated at the cutover date to point to the new vendor's delivery pipeline, not at the start of the parallel-run period.

The parallel-run period and go/no-go criteria

The parallel-run period is a structured interval — typically four to eight weeks — during which both the current vendor and the replacement vendor process the same sample of new submissions, and the outputs are benchmarked against each other and against the WCAG accuracy threshold. The parallel run is the evidence base for the go/no-go decision: move to the replacement vendor on schedule if the benchmarks are met, extend the parallel run or reconsider the switch if they are not.

Designing the parallel-run sample

The parallel-run sample should represent the full range of your content vocabulary, not the easiest subset. The temptation is to run the parallel on your most polished, broadcast-quality training content — the content that performs best on any vendor's system — because the comparison will look favourable. The content that matters for the go/no-go decision is your hardest content: the engineering deep-dive videos with dense SDK terminology, the clinical training content with drug names and dosing vocabulary, the compliance update videos with regulatory citations, the onboarding content with the newest product names that have not yet been through a correction cycle. Submit a batch of 15–25 videos across these vocabulary types to both vendors in the same week. The parallel run answers the question: what does the replacement vendor produce on my hardest content, today, with my ported glossary but without the correction history?

Do not submit the same content twice to the current vendor for billing reasons — submit new content that was being produced anyway, and send it to both vendors. Many captioning contracts allow "evaluation copies" or "test submissions" for this purpose; check the contract terms before routing live production submissions to a competitor.

Setting the go/no-go threshold before the pilot starts

The most common error in parallel-run design is not setting the go/no-go threshold before the pilot starts. If you decide the threshold after you see the results, you are setting it based on the result you want rather than the result you need. Set the threshold before the pilot: what measured accuracy level, on what measurement protocol, on what percentage of the parallel-run batch, constitutes a go? A reasonable threshold is: 97% DCMP word-level accuracy on 80% of submissions in the parallel batch, with no content in the batch falling below 93% on a single-video spot-check. This threshold is deliberately set slightly below the 99% WCAG target to account for the accuracy reset dynamic — the new vendor's model will improve with correction signal, and 97% on day one with a trajectory toward 99% at month three is a go, whereas 94% on day one with no trajectory is a no-go. Documenting the threshold before the pilot starts gives the go/no-go decision objective criteria rather than a subjective judgment call that the vendor can lobby against.

Benchmarking both vendors against the same protocol

Apply the same DCMP Captioning Key spot-check protocol to both vendors' output on the parallel batch. The QA methodology post describes the protocol: select a random passage of at least 90 seconds from each video, count substitution, insertion, and deletion errors at the word level including punctuation and speaker ID, and calculate the per-video accuracy. Do not use the vendors' self-reported accuracy metrics — the measurement methodology differs between vendors and is almost never directly comparable. Apply the same third-party protocol to both sets of outputs and compare the results on a per-video, per-vocabulary-category basis. The per-vocabulary-category comparison is particularly useful: if the replacement vendor underperforms on clinical vocabulary but outperforms on engineering vocabulary relative to the current vendor, that tells you something specific about where to prioritise glossary expansion for the new vendor.

What to do if the parallel run fails the threshold

If the replacement vendor fails the go/no-go threshold in the initial parallel-run period, you have three options: extend the parallel run with an expanded glossary (if the failures are concentrated in vocabulary categories that were not fully represented in the ported glossary), renegotiate the replacement vendor selection (run a shortened RFP to evaluate a different replacement vendor), or delay the switch and focus on extracting more from the current relationship (negotiate accuracy improvements into the contract renewal rather than switching). The extension option is appropriate when the glossary gap is the clear explanation for the failures; the re-evaluation option is appropriate when the failures are distributed across vocabulary categories in a way that indicates a model ceiling rather than a glossary gap; the delay option is appropriate when the current vendor's accuracy is adequate and the switching trigger was primarily pricing, in which case the renewal negotiation may achieve the needed cost reduction without the accuracy reset risk. Do not force a switch on the original timeline if the parallel run shows the replacement vendor will produce a material accuracy regression on production content.

LMS delivery during the transition

The LMS delivery layer — how caption files get from the captioning vendor's system into the LMS where learners encounter them — requires its own transition plan separate from the accuracy benchmarking. Each LMS has a specific caption delivery architecture, and the integration configuration for the current vendor cannot simply be pointed at the replacement vendor without verification. Getting this wrong produces a period during which new content is added to the LMS without accessible captions, which is a WCAG compliance regression even if the caption files themselves are accurate.

Documenting the current delivery configuration

Before the transition begins, document exactly how the current vendor delivers caption files into each LMS in your stack. The documentation should cover: the delivery mechanism (native LMS integration, webhook, API push, manual upload, or SFTP batch), the output format(s) used (SRT, VTT, TTML, or platform-specific format), the file-naming convention for LMS matching (how the LMS associates a caption file with a video asset), the delivery trigger (manual submission, scheduled batch, or event-driven), and any custom configuration applied to the current integration (custom field mappings, encoding specifications, subtitle-track language tags). This documentation is the specification the replacement vendor's integration team needs to replicate the delivery pipeline. Without it, the replacement vendor is configuring from scratch, which takes longer and introduces more opportunities for misconfiguration.

Per-LMS transition considerations

Each LMS in common use by L&D teams has specific characteristics that affect the transition process.

Kaltura: Kaltura's caption management sits in MediaSpace or KMC and uses the CLCAT or CaptionAsset API. The integration between a captioning vendor and Kaltura typically uses the CaptionAsset upload API with a machine ID or service account. The replacement vendor needs the same service account credentials and the CaptionAsset endpoint format to configure the integration. Verify that the caption-asset language tag (en-US, en-GB) is consistent between vendors to avoid the LMS creating duplicate language tracks in the caption selector.

Docebo: Docebo's caption delivery uses the Learning Objects API with SRT or VTT file attachment. Most third-party captioning vendors integrate via Docebo's native "auto-captioning" connector or via the REST API's learning-object asset endpoint. During the transition, the Docebo connector for the current vendor should remain active until the new vendor's connector is tested end-to-end on at least 5 production submissions. Do not disable the current vendor's connector until the new vendor's connector has delivered at least one successful caption to a live course.

Cornerstone OnDemand: Cornerstone caption delivery is via the VILT or SCORM content object with an embedded VTT track, or via the Vimeo/Kaltura integration if the video is hosted externally. The transition risk in Cornerstone is that caption tracks are attached at the content-object level, not at the video asset level — changing the captioning vendor requires updating the caption attachment in each content object, not just updating the delivery integration. For large Cornerstone libraries, this is a manual process that must be scoped into the transition timeline.

TalentLMS: TalentLMS supports SRT upload per course unit. Most teams delivering via TalentLMS use a manual or semi-automated upload workflow rather than a native integration. The transition is low-risk from a configuration standpoint — the new vendor delivers SRT files in the same format, and the upload workflow is unchanged. The risk is the manual-upload bottleneck: if the team relies on a single administrator to upload caption files per unit, the transition period may create a backlog of uncaptioned units if the administrator's capacity is constrained during the switchover.

Panopto: Panopto has a native caption management interface that accepts ASR transcript import or manual SRT upload. Some captioning vendors integrate via Panopto's REST API for automatic delivery. The Panopto integration uses OAuth 2.0 authentication with a service account; the replacement vendor needs the same Panopto API client ID and secret. During the transition, verify that the replacement vendor's delivery pipeline handles Panopto's concurrent-processing limit (Panopto throttles caption upload requests to prevent server load from large batch imports).

Workday Learning: Workday Learning caption delivery is handled through the Workday Content Import Framework or via the LTI integration for external video hosting. The transition risk in Workday is the administrative complexity: caption attachments are associated with Learning Activity configurations, not with individual media assets, and the Workday administrator must update the Learning Activity configuration to point to the new caption source. Coordinate with the Workday administrator at least two weeks before the cutover date to scope this work into their sprint or maintenance window.

Testing the delivery pipeline before cutover

Before the cutover date, test the replacement vendor's delivery pipeline end-to-end in each LMS in your stack. The test should verify: the caption file reaches the LMS (delivery confirmation from the vendor and the LMS), the caption track appears on the video for a learner account (not just an administrator account, which may see draft content), the language tag and track label are correct, the timing is synchronised correctly, and the caption track is set as the default track rather than requiring manual activation by the learner. Each of these has been the source of a delivery failure in a vendor transition where the integration was assumed to work because the file transfer succeeded without verifying the learner-facing result.

Contract termination mechanics

The contract termination process — giving notice, receiving data returns, confirming deletion, and closing the commercial relationship — runs in parallel with the technical transition. Getting the termination mechanics wrong can produce a situation where the commercial relationship with the current vendor ends before the technical transition to the replacement vendor is complete, leaving you without a captioning vendor for production submissions during the gap.

Termination notice timing

The termination notice should be given to the current vendor after: the glossary has been exported and cleaned, the replacement vendor pilot has completed and passed the go/no-go threshold, the replacement vendor's LMS integrations have been tested end-to-end, and the backlog-transfer re-captioning scope has been agreed. Giving notice before these conditions are met creates pressure to complete the transition on the current vendor's exit timeline rather than on the timeline that produces a clean technical handover. If the current contract's auto-renewal date creates pressure to give notice before the pilot is complete, negotiate a month-to-month extension on the current contract rather than accelerating the transition to meet the renewal deadline.

The notice period is typically 30–60 days from the contract terms. During this period, the vendor's commercial relationship remains active — you can continue to submit content during the parallel-run period, the data-return process begins, and the termination SLA obligations take effect. Some vendors attempt to restrict new submissions after notice is given; this is not a standard contract right and should be explicitly addressed in the contract — the buyer should have the right to continue submitting new content on the current terms through the end of the notice period.

Data return and deletion

The contract review checklist's data-return clause is the operational reference for this phase: within the data-return window (typically 30 days from the contract end date), the vendor should deliver all customer data — caption files, glossary export, audio files if retained, and correction history if exportable — in a documented format, and provide written confirmation of deletion of any PHI-bearing audio within the window required by the BAA. The data-return request should be submitted in writing on the day notice is given, not at the end of the notice period. This creates a paper trail and starts the vendor's clock on the data-return SLA.

After the data return is confirmed, request a certificate of deletion for any PHI-bearing audio. The certificate of deletion is a vendor-signed document stating that all audio files containing PHI have been destroyed and that no copies exist in backup or archive systems. This document is the closure artefact for the HIPAA BAA obligation. File it in your vendor management records alongside the original BAA and the termination notice. Without this document, the HIPAA BAA obligation remains open even after the commercial relationship ends.

Transition assistance SLA

If you negotiated a transition assistance SLA in the original contract — as recommended in the contract checklist post — activate it during the notice period. Transition assistance typically covers: glossary export in a format importable by the replacement vendor, documentation of the current integration configuration for each LMS in your stack, and a 30-day technical support window during which the current vendor's integration team answers questions from the replacement vendor's integration team about the prior configuration. This SLA is most valuable for teams with complex Kaltura, Workday, or Panopto integrations that took significant time to configure originally. Without a transition assistance SLA, the current vendor has no contractual obligation to help the replacement vendor replicate the integration — the technical documentation you compiled in the pre-transition phase is the backup if the SLA was not negotiated.

Eight failure modes in captioning vendor transitions

The following failure modes are the specific patterns that turn a well-planned vendor transition into a compliance regression, a labour spike, or a commercial dispute. Each has been observed in practice by L&D teams navigating captioning vendor changes.

Failure mode 1: Giving notice before exporting the glossary

Once notice is given, the vendor has reduced commercial incentive to assist with data export. Some vendors' self-service export tools are deprioritised for maintenance after a notice is given; others require a support ticket for complete exports, and support response times for departing customers are not always the same as for retained customers. The glossary export must be completed and validated — not just initiated — before giving notice. Validation means opening the export file, confirming the term count against the platform's display count, and checking that pronunciation notes and variant tags are included.

Failure mode 2: Running the parallel-run pilot on vendor-selected content

Replacement vendors will suggest running the pilot on content they provide (demo content, public-domain content, or content from reference customers in a similar vertical). The pilot result on vendor-selected content is meaningless for predicting performance on your content. Run the pilot on your own production submissions: your vocabulary, your audio quality, your speaker profiles, your content types. The pilot is only useful to the extent that it predicts performance on the actual content you will submit post-cutover.

Failure mode 3: Not setting the go/no-go threshold before the pilot

Without a pre-set threshold, the go/no-go decision becomes a judgment call made under the pressure of a transition timeline and a replacement vendor who is motivated to have the contract start. The threshold should be documented in writing, agreed by the L&D director and the compliance lead, and communicated to the replacement vendor before the pilot begins. A vendor who knows the threshold and understands that failure to meet it will delay or prevent the transition has an incentive to invest in glossary onboarding and integration work during the pilot period.

Failure mode 4: Cutting LMS integrations before end-to-end delivery is tested

The most common cause of a gap in caption coverage during a vendor transition is disabling the current vendor's LMS integration before the replacement vendor's integration has been tested with a real learner account on a real course. The integration testing checklist should cover every LMS in your stack, and the current vendor's integration should remain active in read-only or monitoring status until the replacement vendor's delivery has been verified on a production course.

Failure mode 5: Failing to negotiate transition assistance before terminating

Transition assistance is much easier to negotiate during the contract term than during the exit conversation. The vendor has commercial leverage during the exit that they do not have during the term: they control the data return, the export format, and the integration documentation. Negotiate a transition assistance SLA as part of the contract renewal or as an amendment before the notice period begins. If transition assistance was not negotiated, the technical documentation compiled during the pre-transition phase is the fallback, but it is a partial substitute.

Failure mode 6: Losing the correction history

If the correction history exists only in the vendor's proprietary system and cannot be exported, it is lost when the commercial relationship ends. This failure mode is avoidable only prospectively: during the contract term, maintain a parallel record of corrections in a format that is not vendor-dependent. A shared spreadsheet or a Notion database that captures the term, the original wrong output, and the correct form is a simple and sufficient correction-history artefact that is yours to keep regardless of vendor. The feedback loop post describes the correction-signal types that most drive model improvement; the terms in the substitution-error and proper-noun-error categories are the ones most worth maintaining in a vendor-independent record.

Failure mode 7: Re-captioning the full back catalogue before the pilot validates quality

A full back-catalogue re-captioning contract with the replacement vendor before the pilot result is known is a premature commitment. If the pilot fails the go/no-go threshold and the switch is delayed or cancelled, the re-captioning contract becomes a liability. Scope the re-captioning to the non-compliant tier identified in the backlog quality assessment, and execute that scope only after the pilot passes and the go/no-go decision is made. Full back-catalogue re-captioning can be phased in over the first 6–12 months of the new vendor relationship once the accuracy compounding is established.

Failure mode 8: Accepting a data-return timeline that extends past the LMS migration freeze window

If your vendor transition overlaps with an LMS migration — which is a common scenario, since both tend to be triggered by the same contract renewal cycle — the data-return timeline from the current captioning vendor must be completed before the LMS migration freeze window begins. As described in the LMS migration checklist, the caption freeze window is the period during which no new caption submissions should be processed to avoid metadata inconsistency during the platform cutover. If the captioning vendor data return extends into the freeze window, the caption files from the data return cannot be imported into the new LMS during the freeze, and the data return must be stored and queued for post-migration import. Plan the timeline so the captioning vendor data return completes at least two weeks before the LMS migration freeze window begins.

Stay-vs-switch decision checklist

The following checklist is structured as a set of conditions. Work through it before initiating a vendor transition. If fewer than three of the four "switch" conditions are met, the risk of the transition may outweigh the benefit.

Accuracy conditions

• Current vendor has not improved to 97%+ on your hardest vocabulary category despite 12+ months of correction feedback and a full-architecture glossary. If yes, this is a go condition for exploring alternatives. If no (the vendor is still improving, or you have not yet built the full-architecture glossary), the accuracy gap may be addressable within the current relationship before committing to a switch.
• Replacement vendor pilot has achieved ≥97% DCMP accuracy on your hardest-vocabulary sample, with your ported glossary, without correction signal. This is the go condition from the parallel-run result. If the pilot result is below 97%, the accuracy reset risk is higher than the gain from the switch, and the switch should be delayed until the replacement vendor can demonstrate this threshold on your content.

Commercial conditions

• The replacement vendor's total cost at your current consumption volume is at least 20% lower than the renewal terms from the current vendor. A 10% cost difference does not justify an accuracy reset, the labour cost of the transition, and the 3–6 month accuracy recovery period. A 20%+ difference in unit economics materially changes the build-vs-stay calculation. The pricing breakdown post provides the per-minute and flat-monthly comparison framework.
• The current vendor's contract allows termination for cause based on documented accuracy failures or SLA breaches, eliminating early-termination fees. If a for-cause termination right exists and the vendor has provided documented grounds for it, the financial switching cost is reduced to the transition labour cost, not the remaining contract value. This changes the cost-benefit calculation significantly.

Capability conditions

• The current vendor cannot deliver a capability that is now required: HIPAA BAA, a required LMS integration, multilingual output, or accuracy on a vocabulary category that has become compliance-critical. Capability gaps are the clearest switch condition because they cannot be addressed within the current relationship. If the replacement vendor has the capability and the current vendor cannot roadmap it within the contract term, the switch is justified on capability alone if the accuracy and commercial conditions are also met.

Operational readiness conditions

• The glossary has been exported, cleaned, and expanded to full-architecture depth before notice is given. If this condition is not met, the switch should not proceed until it is.
• The replacement vendor's LMS integrations have been tested end-to-end on all LMS platforms in the current stack before the cutover date. If this condition is not met, set the cutover date to a minimum of two weeks after the last LMS integration test completes.
• The backlog quality assessment has been completed and the re-captioning scope has been defined and budgeted. If this condition is not met, the full cost of the transition is not yet known. Do not commit to a cutover date without knowing the re-captioning scope.

A captioning vendor that makes the transition in — not out — the easiest part

The transition playbook above describes the risks and the mitigations for switching captioning vendors. The risks are real: the accuracy reset, the backlog gap, the LMS delivery disruption. But the mitigations are manageable — glossary portability, a structured parallel run, and a clean contract termination reduce the switching cost to a bounded, quantifiable transition window rather than an open-ended accuracy regression.

GlossCap is built to be on the right side of these dynamics. Your glossary is stored in a documented CSV and JSON format, exportable from your account dashboard at any time, including on exit. The glossary ownership clause in the standard Team and Org plan agreement is explicit: the per-customer glossary is buyer property, returned in full within five business days of a written export request, with no vendor-proprietary format lock. The accuracy improvement history — the correction signal that compounds the model toward 99% — is tracked per-customer and contributed back to the glossary expansion tooling, so the improvement is reinforced in the glossary rather than held only in a model weight. The LMS integrations for Kaltura, Docebo, TalentLMS, Cornerstone, and Panopto are documented in the product knowledge base, so the integration configuration is transparent and replicable.

If you are running the parallel-run phase of a vendor transition and want a benchmark submission to evaluate GlossCap against your current vendor on your own content with your exported glossary, Team plan submissions include a 14-day evaluation period specifically for this use case: no glossary onboarding fee, no minimum commitment, and the full DCMP-accurate output against which to run your parallel-run benchmarking protocol.

Start the parallel-run evaluation