Key Takeaways
- Brightcove only retains your original uploaded file if the ingest profile's "Store master files" option was enabled before upload. There is no way to turn this on retroactively for existing videos.
- Kaltura and Vimeo Enterprise both support original-file retrieval, but neither is fully self-serve at scale. Kaltura requires downloads enabled per entry. Vimeo Enterprise's bulk export runs through a manual support request.
- Brightcove's CMS API allows up to 10 requests per second and 20 concurrent calls per account, the practical ceiling on scripted bulk export or re-ingest speed.
- Kaltura recommends capping CSV bulk uploads at 500 lines and batching API-driven bulk actions in groups of 500 with a pause between batches.
- Never cancel the old contract, or the Brightcove, Kaltura, or Vimeo Enterprise account, before the new platform has run in production for a full billing cycle.
Brightcove, Kaltura, and Vimeo Enterprise each make you get your video files out a different way, and none of them make it obvious upfront.
Brightcove only hands over your original upload if a setting was enabled before you ever recorded a video. Kaltura needs the download permission switched on per entry, not per account. Vimeo Enterprise routes bulk original-file requests through a support ticket instead of a dashboard button.
None of that shows up until you are already mid-migration and discover the files you thought you owned outright are actually locked behind a setting nobody checked.
This playbook walks through the actual sequence: what to audit first, what each source platform will and will not let you export, how to re-upload without losing the mapping between old and new IDs, how to swap embeds without a production outage, and a realistic timeline based on library size.
It also covers when migrating is the wrong call entirely, because that section gets skipped in most guides and it is the one that saves the most wasted effort.
When You Should Migrate (and When You Shouldn't)
A video hosting platform migration is worth the disruption when the underlying economics or capabilities have genuinely broken down, not simply when a renewal invoice arrives and feels expensive.
Migrate When:
- Cost has decoupled from value. You are paying per seat for content that serves external viewers, not internal teams.
- You need API access your current platform does not offer, and that access blocks a product or engineering roadmap.
- Playback performance is measurably poor in markets that matter to your business.
- A compliance or data residency requirement cannot be met on the current platform, full stop.
- The platform is being deprecated, or its own roadmap has visibly stalled for multiple quarters.
Don't Migrate When:
- You are mid-contract with no exit clause, and the projected savings do not cover the early-termination penalty.
- Your library is deeply wired into an LMS, and the integration is the actual product your users depend on, not just the video hosting underneath it.
- You are within a quarter of a major launch. A migration and a launch competing for the same engineering attention is how both go wrong.
- The real problem is a workflow or staffing issue. A new vendor will not fix a content team that has no publishing process.
- Nobody owns the project. A migration with no named owner is not a project. It is a future incident with a delayed start date.
Before You Touch a Single File
This article assumes you have already audited your library and mapped your embeds. If you have not, Gumlet's general video migration playbook covers that groundwork: counting and categorizing your library, auditing every embed location, and building the discovery buffer that keeps a migration from running past its estimate.
What that article does not cover in depth is the part that changes depending on where you are migrating from. Brightcove, Kaltura, and Vimeo Enterprise each gate access to your original files differently, rate-limit bulk export differently, and require a different sequence of steps before a single video leaves the platform.
That is what this article covers, platform-by-platform, with Gumlet as the destination and its URL-based ingest API as the constant that simplifies the receiving side regardless of which of the three you're leaving.
A February 2026 AWS case study on a SaaS platform hosting sales and marketing video for enterprise customers found that just 0.6% of a 10-million-video library, about 60,000 files, accounted for the large majority of retrieval activity once the platform's access patterns were fully mapped, with a separate 10% slice of larger, more-watched files driving 99% of monthly requests.
The uneven access pattern is common enough that Brightcove, Kaltura, and Vimeo Enterprise libraries tend to show the same shape.
What "Exporting Your Videos" Actually Means on Each Platform
Exporting from a video platform is not one action. It is at minimum two separate questions: can you retrieve the original file you uploaded, and can you retrieve it in bulk without manual, one-by-one requests.
Brightcove, Kaltura, and Vimeo Enterprise answer both questions differently, and the answer determines how much of this phase is a scripted job versus a waiting game.
Gumlet is the destination platform this guide assumes you're moving toward, and it's worth naming what it does differently before the platform-by-platform breakdown: unlike Brightcove and Kaltura, Gumlet's ingest API accepts a source URL directly, so migrating videos does not require a local download-and-reupload cycle for each file, whether the source is Brightcove's Social Syndication API feed, a Kaltura entry with downloads enabled, or a Vimeo Enterprise export link.
That single difference is why the export mechanics below matter: once you have a URL Gumlet can reach, the transcode-and-ingest step is largely the same regardless of which of the three platforms you're leaving.
Phase 1: Audit Before You Move Anything
Before a single file moves, pull a full inventory: total asset count, total hours of content, storage footprint, and views per asset over the last 12 months.
This inventory is the deliverable that determines everything that follows, and skipping it is the single most expensive shortcut a migration team can take.
The finding worth leading with: in most enterprise video libraries, a large share of assets receive close to zero views.
The AWS case study mentioned earlier also found that roughly 0.1% of stored video files accounted for nearly half of all retrieval activity in cold storage, meaning the overwhelming majority of the library was barely being touched at all.
That kind of skew is normal, not a sign anything went wrong. It just means most of what sits in a video library was recorded once, used for a specific moment, and then forgotten while still costing storage, encoding, and QA time on every migration that comes along.
Classify every asset into one of three buckets: migrate, archive cold, or delete. Get sign-off on the delete list from content owners in writing, not a verbal nod in a meeting. Then map where each surviving asset is actually embedded. That embed map, not the video files, is the real Phase 1 deliverable, because Phase 4 cannot start without it.
Migrating your entire library without this step is the expensive way to avoid making a decision.
Phase 2: Get Your Data Out
This is the phase that determines whether the rest of the migration is smooth or painful, and it looks different depending on which platform you are leaving.
The first question to answer, before anything else, is whether you can retrieve your original uploaded files or only the platform's compressed, transcoded renditions. Re-encoding a transcode compounds quality loss. If originals are not retrievable, decide whether that is acceptable before you commit to a migration date.
If You're on Brightcove:
Whether you can get your original file back depends on a setting you likely never touched. Brightcove stores an original "video master" separately from playback renditions, but only if the ingest profile used at upload time had the "Store master files" option enabled.
That option is opt-in per ingest profile, not automatic for every account. If a custom ingest profile did not enable it, or if masters were deliberately deleted afterward to cut storage costs, the original file is gone, and no export request will recover it.
Studio itself does not offer a way to download masters directly. The documented route is the Social Syndication API's MRSS feed, configured to include masters in the feed template. For bulk metadata and rendition export, the Media module's export feature is the simpler starting point, though Brightcove's own guidance recommends exporting fewer than 15,000 videos at a time and splitting anything larger into multiple search-filtered batches.
For scripted, API-driven export or re-ingest, Brightcove's CMS API caps access at 10 requests per second per account, with a separate ceiling of 20 concurrent calls. That combination, not raw request volume, is the practical limit on how fast a bulk export or re-ingest job can run.
On the receiving end, Gumlet's upload API accepts a source URL and handles the fetch and transcode asynchronously, so the client never pushes file bytes through the request path at all. For a Brightcove library where export is already the bottleneck, that keeps the re-ingest side from becoming a second one. For a Brightcove library where export is already the bottleneck, that removes a second bottleneck from the re-ingest side.
If You're on Kaltura:
The path is more predictable than Brightcove's, but it is not automatic. Downloads are disabled by default on every Kaltura entry.
To retrieve a source file, download needs to be enabled per entry, under that entry's Downloads tab, with "Source File" checked, before the file becomes downloadable at all. There is no conditional archiving setting working against you the way there is with Brightcove, but there is a per-entry switch that has to be flipped before export, and at scale that switch needs to be set for every video you plan to migrate.
For bulk ingestion or export automation, Kaltura's CSV and XML bulk tools accept files hosted on your own FTP server or any publicly accessible source. Kaltura recommends capping each CSV file at 500 lines, and for bulk actions above 5,000 entries, submitting in batches of 500 with a pause between batches.
That per-entry download setting is also the detail worth flagging to whoever owns the migration checklist: Gumlet's Dynamic Metadata field can store the Kaltura entry ID alongside each imported video, so even if downloads were enabled unevenly across the library, the mapping table stays intact and any entry that needs a second export pass is easy to identify by ID rather than by re-auditing the whole library.
If you are automating through the API rather than the Rich Media CMS interface directly, Kaltura recommends batching uploads in groups of 500 entries, which is a throughput recommendation rather than a platform-enforced limit.
If You're on Vimeo Enterprise:
Vimeo generally allows original source file downloads, which is the cleanest of the three migration paths since it sidesteps re-encoding an already-compressed file.
At scale, Vimeo's support team can generate a CSV of signed download links to your original upload files specifically, rather than the platform's re-encoded versions, though this is a manual request process rather than something self-serve from the dashboard, so factor a one-to-three-day turnaround into your timeline.
For programmatic bulk downloading once you have that CSV, the Vimeo API handles pagination through standard REST patterns. Vimeo enforces API rate limits by app tier, with response headers indicating your current limit and remaining requests.
Confirm the specific number for your account tier directly with Vimeo before scripting a large export. In practice, a large-library export is a conversation with Vimeo about your specific limits rather than a fixed number you can plan around from documentation alone.
Once that CSV of signed download links exists, Gumlet's upload API can consume it directly: point the API at each signed URL and Gumlet fetches, transcodes, and ingests the file without a local download step in between. For a Vimeo Enterprise library where the export itself already runs through a manual request process, skipping a second manual step on the ingest side is where most of the time savings in this migration actually come from.
Across all three platforms, two things hold regardless of vendor:
- Your analytics history almost never migrates, and it needs to be exported before you cancel anything, or it is gone permanently.
- Contract landmines deserve a read before you start, not after: notice periods, auto-renewal dates, egress or export fees, and post-termination data deletion windows. Check the contract before starting the migration, not after you've already begun moving files.
If originals are not retrievable and you are working with transcodes, the destination platform's ingest handling starts to matter more than it otherwise would. Re-encoding an already-compressed rendition compounds the quality loss a second time.
Gumlet, an all-in-one video hosting platform, ingests source files and re-encodes using adaptive bitrate profiles designed to preserve as much of the incoming quality as the source allows, which matters specifically in the transcode-of-a-transcode scenario this phase is built around.
Export your analytics history first. It is the one thing you cannot recreate later.
Phase 3: Re-Upload, Re-Encode, Verify
Once your data is out, the upload strategy matters as much as the export did, and what you exported from Brightcove, Kaltura, or Vimeo Enterprise determines what that upload looks like.
A Brightcove export carries CMS API metadata fields that do not map one-to-one onto another platform's schema.
A Kaltura export arrives with the category and entitlement structure the KMC used.
A Vimeo Enterprise export is usually the flattest of the three, closer to files with basic titles than to a structured library.
An API-driven bulk ingest that preserves the old platform's asset ID in a custom field on the new platform is what makes Phase 4's embed swap a scripted job instead of a manual guessing exercise across thousands of pages.
That mapping only works if the destination platform supports arbitrary custom metadata fields on an asset and bulk ingest from a source URL rather than an upload-from-disk step for every file.
Gumlet supports both: Dynamic Metadata stores the old video ID as a key-value pair, and the upload API accepts a source URL directly.
Mux offers the same shape of capability through its passthrough field and Create Asset from URL endpoint. Neither capability is exclusive to one vendor, but a destination platform lacking either one turns this phase into weeks of manual reconciliation regardless of which of the three source platforms you're leaving.
Rebuild the encoding ladder rather than assuming the new platform's defaults match what viewers were getting before, and rebuild access controls, including signed URLs, DRM, domain restrictions, and SSO groups, to at least the level Brightcove, Kaltura, or Vimeo Enterprise was enforcing. Keep the old-ID-to-new-ID mapping table current throughout: every step in Phase 4 depends on it.
Phase 4: Swap the Embeds Without Breaking Production
This is the riskiest phase in the sequence, because it is invisible until it fails. Uploading files to a new platform is the visible part of a migration.
Updating every embed that references Brightcove, Kaltura, or Vimeo Enterprise is where migrations quietly fall apart, and the embed formats you're replacing differ by platform: Brightcove and Kaltura both generate iframe or script-tag embeds tied to a platform-specific video ID, while Vimeo Enterprise embeds sometimes carry additional privacy-domain parameters that need to be reproduced on the new player, not just the video ID itself.
Start by finding every embed location, not just the obvious ones: a CMS database search, a full site crawl, help center content, LMS courses, email templates, PDFs and decks, and any partner sites you do not directly control.
A library of a few hundred videos frequently has two to three times that many embed instances, added over years by different people using different tools.
| Approach | Effort | Risk | Best For |
|---|---|---|---|
| Direct find-and-replace in the CMS | Low to moderate | Moderate; a bulk error touches every page at once | Standard CMS platforms with a searchable embed pattern |
| Central wrapper or shortcode swap | Low, if one already exists | Low | Teams that built embeds through a single reusable component |
| Redirect the old embed URL | Low, where the source platform supports it | Low to moderate, depends on redirect fidelity | Setups where the embed resolves through a URL you control |
| Manual update for the long tail | High | Low per-instance, high in aggregate time | Orphaned pages, old emails, partner sites |
If your embeds route through a single wrapper component, this phase is an afternoon. If they are pasted individually into thousands of CMS entries, it is the whole project, regardless of which of the three platforms you started on.
Run the old and new platforms in parallel rather than cutting over on a single date, and do not decommission Brightcove, Kaltura, or Vimeo Enterprise until the new embeds have been verified in production for a full cycle.
Preserve VideoObject schema markup, update your video sitemap, and keep page URLs unchanged wherever possible, since a page ranking partly on video content should not lose that signal in the swap.
Phase 5: Verify, Then Decommission
Before touching billing on Brightcove, Kaltura, or Vimeo Enterprise, run a full QA matrix: desktop and mobile browsers, iOS and Android apps, smart TV if that's part of your delivery footprint, caption rendering, DRM playback, analytics events actually firing, and access controls actually denying access when they should.
Watch startup time, rebuffer ratio, and playback error rate for a full cycle before cancelling anything.
Once verification is complete, work through the decommission checklist:
- Confirm the final export is complete
- Screenshot or export any remaining analytics dashboards
- Revoke old API keys
- Cancel per the contract's actual notice period
- Confirm the old platform has processed your data deletion request rather than assuming it happened automatically
Step 4 is where the three platforms diverge most. Vimeo Enterprise and Kaltura contracts typically specify a notice window that has to be triggered in writing before the renewal date, not simply cancelled after. Brightcove's Video Cloud contracts commonly include a post-termination data retention window worth confirming in writing before you assume your masters, if any were stored, stay accessible after cancellation.
Cancel the old contract only after the new one has survived a full billing cycle in production.
How Export Time Differs by Platform
The audit, re-upload, and embed-swap phases take roughly the same amount of time regardless of which platform you are leaving. The export phase does not. It is the one part of a migration where your source platform, not your library size, sets the pace.
Kaltura's export is the most self-serve of the three: enable downloads on the entries you need, or automate through the CSV or XML bulk tools, and you are not waiting on anyone.
Vimeo Enterprise sits in the middle: dashboard-enabled downloads work per video, but a bulk export of originals across a large library requires a support request with a turnaround measured in business days, not minutes.
Brightcove is the least predictable of the three, because whether you are waiting at all depends on a setting configured before you ever uploaded a file. If master storage was enabled, export is a scripted API pull. If it was not, there is no export to wait for: the original is gone, and the phase becomes a decision about transcode quality instead of a data transfer problem.
Budget accordingly: confirm which of these three situations applies to you before you set a migration date, not after.
How Long It Actually Takes
Migration duration scales with library size, but it also depends heavily on how centralized your embeds are and whether original files are retrievable without a manual support request.
The ranges below assume a single owner managing the project with developer support available for API-driven work, and they assume the Phase 1 audit has already happened rather than running in parallel with the migration itself.
| Library Size | Audit | Export | Re-Upload | Embed Swap | Verification | Total Elapsed |
|---|---|---|---|---|---|---|
| Under 500 assets | 1 to 2 days | 0.5 to 1 day | 4 to 8 hours | 2 to 4 days | 1 to 2 days | 1 to 2 weeks |
| 500 to 5,000 assets | 2 to 3 days | 1 to 2 days | 2 to 3 days | 3 to 5 days | 3 to 5 days | 3 to 5 weeks |
| 5,000+ assets | 3 to 5 days | 2 to 4 days | 3 to 5 days | 1 to 2 weeks | 1 to 2 weeks | 6 to 10 weeks |
These figures are estimates based on general migration patterns across the industry, not audited data from a single set of engagements, and they assume embeds are reasonably centralized rather than scattered across thousands of individually pasted instances.
A library where embeds live behind one wrapper component will land at the fast end of each range. A library where embeds are hand-pasted across CMS entries, emails, and partner sites accumulated over several years should budget for the slow end, and possibly beyond it.
The single variable that most consistently extends a migration past its original estimate is not upload speed or embed volume. It is discovering, mid-migration, video content that was not in the original audit: a forgotten microsite, an old landing page still pulling organic traffic, or an email sequence a former employee set up years ago.
Build a discovery buffer into the schedule rather than treating the audit as a one-time, fully complete step.
Where These Three Migrations Specifically Go Wrong
Assuming Brightcove stored your masters because most accounts do: Master storage is opt-in per ingest profile. A custom profile that never specified master storage, or a standard profile where masters were later deleted to cut storage costs, means the original is not retrievable no matter how the request is phrased to support.
Treating Kaltura's per-entry download setting as an account-level one: Downloads are disabled by default and enabled per video, not globally. A bulk export attempt against entries where nobody enabled downloads returns nothing to export, not an error explaining why.
Waiting until the migration is already scheduled to file a Vimeo bulk-export request: Vimeo Enterprise's bulk original-file export runs through a manual support request rather than a self-serve dashboard action. Filing it after a cutover date is already set turns a routine request into the thing that delays the date.
Frequently Asked Questions
1. How long does a video platform migration take?
For a library under 500 assets with reasonably centralized embeds, plan for one to two weeks end to end. A library in the 500 to 5,000 range typically runs three to five weeks, and anything above 5,000 assets, especially with embeds scattered across many systems, can extend to six to ten weeks. The single biggest variable is how centralized your embeds are, not the raw video count.
2. Can I export my original video files from Brightcove, Kaltura, or Vimeo Enterprise?
It depends on the platform and, in Brightcove's case, on a setting configured at upload time.
Kaltura and Vimeo generally support original file retrieval, though Vimeo's bulk-download path for originals requires a manual request to support rather than a self-serve dashboard option.
Brightcove only retains an original "master" file if the ingest profile was configured to archive it, so check this specific setting before assuming your originals are recoverable.
3. What happens to my existing embed codes?
They stop resolving the moment the old platform's video ID no longer exists or the account is cancelled. Every embed needs to be found through a CMS search, help center audit, LMS review, and manual check of emails and partner sites, then updated to point at the new platform's video ID.
This is why the embed audit in Phase 1 and the mapping table from Phase 3 matter as much as the file transfer itself.
4. Will migrating hurt my SEO?
Not if handled correctly, but it is a real risk if ignored. Preserve VideoObject schema markup, keep page URLs unchanged wherever the migration allows it, update your video sitemap, and set up 301 redirects for any indexed video-specific URLs that do change.
A page ranking partly on video content can lose that signal if the migration strips the structured data without replacing it.
5. Can I keep my analytics history?
Only the parts you export before cancelling the old platform, and even then, not all of it. Historical event logs and heatmap visualizations are typically tied to the old platform's internal architecture and do not transfer at all.
What usually is exportable as a CSV, on most professional platforms, includes total view counts, average watch time, and traffic source breakdowns. Export everything available before you touch billing on the old account.
6. Can I recover my original files if Brightcove never stored the master?
No. If the ingest profile used at upload did not have "Store master files" enabled, and the master was not separately archived elsewhere, the original file cannot be recovered from Brightcove regardless of plan tier or support escalation. Your only source becomes the highest-quality rendition Brightcove did retain, typically an already-compressed file.
7. Do I need to enable downloads on every Kaltura entry before migrating?
Yes, individually, unless you are exporting through the CSV or XML bulk tools rather than downloading files directly. Kaltura disables the download option by default on every entry. For a library of any size, plan to either enable downloads entry by entry before export or route the export through Kaltura's bulk ingestion tools instead, which do not depend on that setting.
8. Do captions and subtitles export with the videos?
Not automatically, and not in one format. Caption files are separate assets on all three platforms, retrieved through their own API calls or download paths rather than bundled with the video file, and a migration plan that only moves video files arrives with a silent accessibility regression. Inventory caption assets in Phase 1 alongside the videos, export them in Phase 2, and verify rendering in the Phase 5 QA matrix, where the draft already lists caption rendering as a check.
The Sequence, Not a Single Event
A video platform migration that goes cleanly is not the result of a bigger budget or more engineering headcount.
It is the result of treating it as a sequence rather than an event: audit before you export, export before you re-upload, re-upload before you swap embeds, and swap embeds before you decommission anything on the old side.
Skipping a step to save time is exactly where migrations accumulate the kind of problems that take weeks to unwind afterward. The sequence exists because each phase depends on the one before it actually being done, not approximately done.
For teams migrating to Gumlet specifically, the practical support during this process covers bulk import through the upload API, the custom metadata fields needed for old-ID-to-new-ID mapping, and direct migration support from the team for the embed-swap phase.
If you are mid-planning and want to talk through your specific source platform and library size before committing to a timeline, schedule a demo or start with a free trial to test the upload and ingest workflow against your actual library before you touch anything in production.
