On 20 November 2026, Vimeo On Demand shuts down. Sellers have been told, in Vimeo’s own words, that “content and subscriber data will not be automatically migrated, any transition is a fresh start”, and that full buyer lists won’t be released. Viewers lose access to titles they paid for. Every OTT platform migration exposes the same problem in a milder form: your content library is portable, and your customer relationships sit in someone else’s database. Here’s what breaks during an OTT platform migration, how to plan the process, and how to sequence a move that keeps your users.

What actually moves in an OTT platform migration

An OTT service is not one system. It’s seven, so an OTT migration is really seven migrations, running at different speeds and different levels of risk, often across different vendors. Most migration plans spend their effort on the top two rows, because that’s the part every OTT platform provider documents well. The bottom four decide whether your subscribers notice. Ask which layers your migration team could rebuild from your own systems and databases if the export failed, and which exist only inside your current platform’s database. The second list is your real project scope.

What moves in an OTT platform migration
Layer What moves Migration risk
Content library Video assets, masters, renditions, artwork LowMostly time and storage cost
Metadata Titles, series structure, rights windows, categories MediumSchema mapping work
Users and accounts Credentials, profiles, preferences MediumPasswords rarely transfer
Subscriptions and entitlements Who can watch what, until when HighThe entitlement database is where projects fail
Payments Payment provider tokens, billing dates, plan tiers HighPartly outside your control
Applications Web, mobile and connected TV apps MediumCertification adds calendar time
Analytics and watch history Viewing events, engagement, personalisation inputs IgnoredOften written off entirely

The part of your OTT platform you can’t export

Content and metadata move cleanly between OTT services. The customer relationship is where projects go wrong.

Read the export documentation across the major hosted platforms and the gaps are consistent enough to plan around.

Start with the best of them. The strongest documented customer export in the market gives you a customer id, email, product name, subscription status and expiration date, and leaves out payment method details, billing dates and subscription plan tier. Those three fields decide whether your first billing cycle on the new OTT platform double-charges your users or quietly drops their renewals.

Catalogue export carries its own limits. One enterprise platform states in its own documentation that video masters cannot be downloaded from the admin interface at all, leaving a syndication API as the only route out, and caps metadata export at 15,000 videos per file, or 1,000 when rendition URLs are included. The same documentation warns that asset URLs are not fixed, because media storage gets reconfigured periodically, so hard-coded references to video content in your apps, feeds or websites will break eventually.

The asymmetry is clearest in the help centres. Inbound migration guides run to detailed step-by-step articles covering member accounts, active subscriptions, billing data and next billing dates “to avoid double-charging”, while the same vendors publish nothing at all about leaving. API access frequently sits behind a higher pricing tier, so most customers on entry and mid plans hold no programmatic route into their own database.

Watch history is the cold start nobody budgets for

One platform states plainly that watch history doesn’t migrate, most don’t mention it either way, and few migration plans create a line item for it. Continue watching, recommendations and personalisation restart from zero on day one, so a technically clean cutover can still feel like a downgrade to the people using your OTT service, and it shows up in week-one engagement rather than in your migration report. If personalisation carries your retention story, viewing data needs its own workstream and owner.

Judge an OTT platform provider on two axes, not one

Lock-in isn’t a single score. Split it into portability, meaning can you get your data out, and viability, meaning will this vendor still invest in this product in three years. Most streaming services score their shortlist on features and price, and both of those axes are invisible in that process.

The most exportable platform in the group publishes a documented export API action, open-source bulk migration scripts and per-entry source video downloads with no stated volume ceiling. It also discloses the clearest churn evidence in the market, because it’s listed and reports to the SEC. Its media and telecom segment fell 7% across FY2025, then 17% in Q1 2026 and 10% in Q2 2026, with net dollar retention down to 95% from 107%, which its own filings attribute to “elevated gross churn throughout 2025”.

At the opposite corner sits a platform that took a $150m minority investment in February 2025 and publishes nothing at all about getting your data out.

Vendor risk has also become correlated. Bending Spoons closed its $233m acquisition of Brightcove on 4 February 2025 and its $1.38bn acquisition of Vimeo in Q4 2025, then listed on Nasdaq on 1 July 2026. Choosing two suppliers from that shortlist is no longer diversification. The 2026 roadmap published since covers AI captions, contextual advertising and an interface redesign, with no detail on the OTT products underneath, while another long-standing video platform rebranded in December 2025 and now ships advertising products rather than OTT ones.

Judging a platform on portability and viability
High portability Low portability
Strong viability Best case, still audit the contract Well funded, no documented exit path
Weakening viability Open export, declining media segment Highest risk, exit before you need to

What changes on 12 January 2027

There’s a regulatory clock on this, and almost nobody in the industry is writing about it. The EU Data Act has applied since 12 September 2025 and covers software as a service, which includes most OTT platforms and managed OTT services sold on subscription. Providers must “make open interfaces available and, at a minimum, export data in a commonly used and machine-readable format”, and must “remove obstacles that their customers may face when they want to switch to another provider”.

The date that matters commercially is 12 January 2027, from which providers “won’t be able to charge their customers for the operations that are necessary to facilitate switching or for data egress”. Any contract you sign or renew during 2026 should already specify export scope, format and timescales. Pricing changes at renewal are the moment to ask, because that’s when you have something the vendor wants.

One clarification, since vendor marketing muddles it. Article 20 of the GDPR gives an individual the right to receive their personal data “in a structured, commonly used and machine-readable format” and to transmit it “without hindrance”. That’s your subscriber’s right, not yours as the platform operator, which is exactly why Vimeo can withhold a full buyer list and stay compliant. Your route to bulk export is contractual, and after January 2027 it is regulatory.

Rip-and-replace is over, and the numbers say so

The largest recent migrations by streaming services were all sequenced, and the timelines are public. RTL Deutschland moved 7.3 million RTL+ users off a platform it had built in-house onto Bedrock, finishing in April 2026 after roughly 21 months, in what Bedrock’s chief executive Jonas Engwall called “the largest migration of a streaming platform of this kind in Europe”. TVNZ replaced what Quickplay called a fragmented ecosystem of six or more vendors across UI, content management, video processing, advertising and analytics, and completed the project in 12 months. The detail worth copying: it handed user management and billing to Evergent, a specialist, rather than folding those features into the video platform.

Elisa Eesti refused the full-stack move altogether. Its entertainment solutions director Joosep Põllumäe explained why: “We chose a modular platform layer over a full stack so we can modernise what sits behind Elisa Elamus while keeping our apps, our devices and our infrastructure in our own hands.”

Sequence the migration around the entitlement cutover

The order that works puts the riskiest database last. Replicate your content library and metadata into the new environment first, read-only and syncing. Repoint the apps at the new APIs behind a feature flag, then create test accounts so your migration team can validate real playback on real devices. Migrate entitlements last, and run them in parallel.

That dual-run window is the part teams underestimate. For weeks rather than days, both platforms hold the same subscription state in separate databases, one authoritative for billing and the other shadowing it. You reconcile daily on three things: who has access, when they’re next charged, and how much. Take an OTT service with 500,000 monthly subscriptions as an example. A 0.1% discrepancy sounds tolerable until you write it out as 500 people either charged twice or watching for free, and both groups create support tickets in the same week.

The point of no return isn’t the DNS change or the app deployment. It’s the first billing cycle charged by the new platform, because a rollback after that means refunding real money and explaining it publicly. Set your acceptance criteria for that moment, and agree the migration path off legacy infrastructure before you move customer records. If the new OTT platform also means new cloud services, our guide to launching cloud-based OTT services covers the ground before this one begins.

Partial migration beats a single cutover

Elisa’s layer-by-layer approach has a name: partial migration, where the old platform and the new one operate side by side while responsibility moves one system at a time. It costs more in integration work and removes the single point of catastrophic failure, which is usually the right trade. A workable order for an existing OTT platform:

  1. Video content and storage first. Video assets are the least risky layer to migrate and the easiest to verify, and moving them early gives you a measure of transfer efficiency at scale.
  2. Run metadata both ways for a while. Editorial teams keep working in the current platform while the new one ingests, so nobody changes process and tooling in the same week.
  3. Point one app at the new stack. Web first, because you control the release. Connected TV apps carry certification lead times and need their own test cycle in a separate environment.
  4. Keep the payment gateway until the end. Payment provider tokens are frequently non-portable, and re-collecting card details from users is the fastest way to turn a technical project into a churn event.
  5. Cut entitlements over last, with the dual-run and reconciliation above.

The price of this is complexity: two systems and two environments to operate, monitor and maintain while the migration process runs, and the duplication is only worth maintaining while it’s buying you a rollback path. Two databases holding overlapping state will disagree, so decide which is authoritative per field, write it down, and monitor the difference. In other cases the constraint is contractual: minimum terms, per-app fees or bundled pricing can make running two platforms briefly more expensive than a hard cutover. Temporary duplication buys safety at the cost of short-term efficiency, and a transition of this size is easier to defend when that trade sits in the business case rather than in a surprise invoice.

Test the migration before you trust it

Functional testing asks whether the new OTT platform works. Migration testing asks whether it works with your data, including records that have been accumulating quirks since 2018, and whether it can take over without disruption to paying users. Five layers belong in the test plan.

Data validation. Compare counts, then compare content. Matching row counts between the source database and the target database prove nothing about correctness; sampled field-level comparison does. Every commercially relevant field should be validated against the source, and nothing reaches production until the reconciliation report is reliable data rather than an estimate. Create a validation report per layer, including integration testing against your payment provider, and treat it as a release gate.

Entitlement replay. Replay a day of real authorisation requests from the current platform against the new one and compare the answers. Any request where the two platforms disagree is a user who either loses access or gets something free. This is the highest-value test in an OTT migration and it’s regularly skipped.

Device and app coverage. Playback, DRM licence acquisition and resume behaviour need testing on the device mix your audience actually uses. Connected TV platforms fail in ways browsers don’t, and troubleshooting a Tizen or webOS issue after launch costs far more than catching it in a test cycle. For example, a resume position stored in a different unit passes integration tests cleanly and still sends users back to the wrong place in an episode. Our guide to DRM for OTT platforms covers why licence portability deserves attention before cutover.

Load and live rehearsal. Migrate outside your peak season, and if you carry live streaming rights, never cut over inside a live window. A concurrency spike on an unproven stack turns a manageable incident into public disruption. Rehearse the cutover end to end at least once, including the rollback, and confirm your support desk has a complete runbook before the transition starts.

Redirect and deep-link testing. If your OTT service has public title pages or a marketing site, those URLs carry rankings, and changing the structure without a redirect map hands Google a site full of 404s at the moment you’re trying to grow traffic. Export the URL list before the OTT migration, map old to new, create the 301 redirects at launch, and test the map by crawling the old URLs afterwards. Deep links need the same treatment, since a post pointing at a movie page from two years ago should still open the right title in the app. Check too that the new platform lets you keep your own domain on a secure certificate you control, because some hosted services quietly move you onto theirs. Treat the redirect map as part of the migration process rather than a marketing task afterwards, and watch organic traffic for a month after launch.

Then monitor the seams rather than the components: entitlement decisions, billing events, playback failures and support ticket volume. Those four signals show disruption before the dashboards for individual systems do. Create those alerts before cutover and keep them for a full billing cycle after the OTT service has moved, because the integration between billing and entitlements is where late failures surface. Someone has to maintain them afterwards, so hand them over deliberately.

The exit-readiness audit to run before you sign

Rich Zabel of Diversified put the procurement shift bluntly to NewscastStudio: “APIs are no longer a feature to evaluate, they are a procurement requirement”, because best-of-breed architectures only work when components can be “orchestrated, monitored, and replaced without rebuilding”. Geoff Stedman of SDVI added the corollary that custom integrations are “a technical debt trap”. The audit that decides how your next OTT platform migration goes happens years earlier, at signature, whether you’re signing for a new OTT service, a hosted solution or migration services from an integrator. For example, a vendor whose bulk export needs a support ticket is a vendor whose export you have never tested. Feature comparisons dominate vendor selection, and export capabilities decide what the next migration costs.

Eight questions, and you want them answered in the contract rather than on a sales call:

  1. Can we export subscriber and entitlement records in bulk from the database, in a machine-readable format, without opening a support ticket?
  2. Does that export include plan tier, next billing date and payment provider status?
  3. Can we export watch history, and at what granularity?
  4. Are our DRM licences and keys portable, or reissued by you?
  5. Are asset URLs stable, or subject to change at your discretion?
  6. What are the volume limits on export, per request and per day?
  7. Is API access included in our pricing tier, or does it require an upgrade?
  8. What notice do you give before deprecating an API endpoint?

That last one isn’t hypothetical. One streaming vendor’s published API deprecation policy states that parameters and endpoints “can be sunset without deprecation warning first”, while its pricing page says “You always sign for a one year contract”. Neither is disqualifying on its own. Both change how you integrate with the service, and how quickly you could leave it. Where a vendor publishes no export path, record that accurately: it doesn’t prove the capability is absent, and it does prove nothing is guaranteed to you.

What a migration won’t fix

A new platform will not repair a retention problem that comes from your catalogue. Omdia counted 2.24 billion online video subscriptions at the end of 2025, up 17.6% in a year, and expects growth to fall to 5.6% in 2026 as core markets approach saturation. Antenna put weighted average churn across premium SVOD at 4.6%, and subscriber growth down to 7% in 2025 from 12% the year before. No replatforming project reverses that for an individual OTT service.

Nor will it restore the viewing history you couldn’t export, or remove the fatigue that comes with a second architectural change in five years. NewscastStudio described the pattern accurately: each new promise of “more flexibility, better resource utilization” becomes “less persuasive each time”, and the realistic outcome is several generations of infrastructure running alongside each other. Operational efficiency does improve, and the efficiency gains arrive in year two rather than year one, once the duplicated systems are switched off.

For streaming services on a legacy stack, portability is a contract question now, not a technical one. The platforms with the best export tooling are not always the ones with the healthiest media business, the two largest names on most shortlists share an owner, and the free-switching obligation lands in January 2027, which makes 2026 the year to renegotiate rather than the year to wait. Teams that audit the exit only when they need it pay for the same data twice.

If you’re weighing a move off a legacy stack, we can run the exit-readiness audit with you and sequence the entitlement cutover before it becomes a billing incident. Talk to our experts in media and entertainment engineering.

FAQ

Public projects suggest one to two years at scale. RTL Deutschland moved 7.3 million subscribers onto Bedrock in roughly 21 months, completing in April 2026, and TVNZ consolidated six or more vendors into a single platform in 12 months. Smaller content libraries move faster, though the entitlement and billing cutover in an OTT migration takes similar calendar time regardless of catalogue size.

Yes, if you run both platforms in parallel before switching billing. You need plan tier, next billing date and payment status for every active subscription, then daily reconciliation of access, timing and amount during the dual-run window. Risk is highest where your current OTT platform’s export omits billing fields, so confirm what your OTT service can extract from the vendor’s database first.

Usually not. Most platforms offer no documented path for it, and at least one states directly that it doesn’t migrate. Expect continue watching, recommendations and personalisation to restart from zero unless you export viewing data separately, often through analytics feeds or event streams rather than the platform’s own migration tooling.

In an OTT platform migration, partial migration moves one layer at a time while the old platform and the new one operate together. Choose it when a single cutover would put subscriptions, payments and apps at risk on the same night. It costs more in integration work and temporary duplication, and it gives you a rollback path at every step.

The core three are SCTE-35, which marks ad breaks in the video stream; ESAM, which manages those ad placements dynamically and keeps signalling correct; and POIS, which holds the placement intelligence. For live blackout and regional rights, SCTE-224 handles policy. Together they let broadcasters manage ad insertion at the signal rather than downstream.

arrow_circle_right Table of contents

Damian Maicher

Business Researcher

Related articles