Subscriptions and billing state
Renewal dates, trial periods, coupon state and payment tokens rarely export cleanly. A mismatch here does not degrade the service — it charges the wrong person the wrong amount.
Move off a rented platform without a rewrite
Most migrations fail on the same two things: the catalogue and the subscribers. Move those wrongly and you lose either playback history or people's money. The order of operations matters more than the destination.
The destination is the easy half
Standing up a new platform is a known quantity — it is Terraform, and it can be rehearsed as many times as you like before anyone depends on it. What cannot be rehearsed casually is moving a live audience across, with their subscriptions intact, without a window where somebody has paid and cannot watch.
So the engagement is planned backwards from that constraint. The new estate runs in parallel and serves real traffic long before it serves all of it. Entitlements are reconciled, not re-created. And every step has a way back that has actually been tested, rather than a paragraph in a document saying it should work.
Where migrations actually go wrong
Catalogue and playback state
Metadata usually survives. Continue-watching positions, watchlists and viewing history frequently do not, and their loss is the thing viewers notice first.
URLs, apps and cached links
Installed apps keep pointing at old endpoints for as long as people delay updates, and search engines keep old URLs far longer than that.
The contract you are leaving
Notice periods, minimum commits and data-export clauses decide the timeline more often than any technical constraint does.
The three that actually bite
The risks above are the ones a plan document lists. These three decide whether the week goes quietly, and every one of them is an operational detail rather than an architectural one.
The DNS cutover
Time to live is your rollback speed, and it only starts helping after the old value has expired everywhere. Lowering it on the morning of the cutover changes nothing for anyone still holding the previous answer.
Cache warming
A cold edge on cutover day turns every request into a miss. The origin sees full audience load instead of catalogue churn, and the first viewers of the new platform get the worst experience of the entire migration.
Database syncing
Two platforms cannot both be authoritative for a subscription. One side owns the writes and the other reconciles against it, and the direction only flips once, at a moment chosen in advance.
The order that works
Seven steps, in the order they are executed. Everything before step five is reversible by doing nothing; everything from step five is reversible by a rehearsed action.
Control plane initialisation
One Terraform root with both providers, remote state, secrets in the vault, and the DNS zone brought under management with its TTL already lowered. Nothing viewer-facing exists yet.
Edge node provisioning
Nodes stood up at the exchange, TLS terminated, the token public key distributed, origin routes and health checks in place. Each node is verified in isolation before any of them is in a resolver's answer.
Origin seeding
The library copied onto owned storage and checksummed against the source. Asset identifiers are preserved rather than reissued, which is what keeps deep links and app bookmarks alive through the move.
Cache warming
The head of the catalogue pulled through the new edge — manifests and opening segments first — until the hit ratio is at steady state. This happens while the old platform still serves every viewer.
Weighted delivery cutover
Traffic moved by DNS weight in stages, with the old platform still authoritative for state. This is where most of the cost saving arrives and it is reversible by returning the weight.
State reconciliation
Subscriptions, entitlements and positions synchronised and compared until the two ledgers agree, discrepancy by discrepancy. The old platform is still the one that writes.
Authority cutover
Writes move to the new platform at an agreed moment. The old estate stays reachable and warm until the numbers have been boring for long enough to stop looking at them.
The things people ask first
How long does a migration take?
The technical work is usually measured in weeks. The timeline is normally set by the contract you are leaving and by how long you want the parallel period to run before you trust the new numbers.
Will viewers notice?
The intent is that the only thing they notice is that it did not break. Delivery moves first and is reversible in DNS; state moves after it has been reconciled twice.
What if our current vendor will not export cleanly?
That is common and it is planned for. Where an export is incomplete, state is rebuilt from the sources of truth that remain — payment provider records, application logs and the catalogue itself.
Show us what you are on
The current vendor, the contract end date, catalogue size and subscriber count. That is enough to say whether the migration is a quarter or a weekend.