On March 24, OpenAI announced it was shutting down Sora. The consumer app and website closed on April 26. The developer API was scheduled to follow on September 24, which was last month. Per the secondary coverage we’ve read (we haven’t found OpenAI’s own sunset page, so check it before you rely on our dates), that’s about six months from announcement to a dead endpoint, for a product that launched only fifteen months earlier.
If you built a feature on that API, you’ve already had your fire drill. If you didn’t, this is a cheap chance to learn from someone else’s.
We’re not picking on OpenAI. Vendors retire products. Clockwise, the AI calendar tool, closed on March 27 after Salesforce acquired the team, and reports say user data was deleted rather than handed over. Shopify’s Stocky stopped working on August 31. Kajabi Creator Studio goes on November 9. The pattern is boring and constant. What changed is how many products now sit on top of a single model endpoint that the vendor can switch off.
A model API is a lease, not a purchase
When you call a hosted model, you rent three things at once: the weights, the serving infrastructure, and the vendor’s willingness to keep offering both. You only control your own code. The other three can change on a quarter’s notice.
Most teams plan for the first two failing. Outages and price hikes are on the risk register. Fewer plan for the third: the vendor decides the product isn’t worth running. That’s a business decision, not a technical one, and no SLA covers it.
The Sora case is the clean version of this. Your integration code can be perfect and it still stops working on a date you didn’t choose.
Swapping the endpoint is the easy part
The advice floating around after the announcement was to move to Google’s Veo, Kling, or Runway. Fine. But the same coverage kept warning that a different video model isn’t a drop-in replacement, and that’s the part we’d stress.
A model swap breaks more than the URL. It breaks:
- Prompt templates that were tuned against one model’s quirks.
- Quality checks that assumed a certain output style.
- Moderation rules calibrated to what that model tends to produce.
- Downstream steps, like editing or captioning, that expected a particular format.
- Your customers’ expectations, because the output now looks different.
The endpoint change is an afternoon. The rest is weeks, and it’s weeks you only have if you can measure what “good” means. That’s the real dividing line between teams that migrate calmly and teams that scramble. Does your team have a set of real inputs, with outputs you’ve judged acceptable, that you can run against a new model on Monday morning? If not, you’re not ready to switch, and you’ll find out at the worst time.
What we’d build in from day one
None of this is exotic. It’s mostly discipline, and it costs little at the start and a lot to retrofit.
One seam, not forty call sites. Put every model call behind a single interface your own code defines. Your app asks for “summarize this document” or “generate a clip,” and one module translates that into a vendor call. When the vendor goes away, you rewrite one module. We’ve seen codebases where the vendor’s SDK types leaked into the UI layer. Don’t do that.
Keep your prompts and evals in your repo. Version them like code. Keep a fixed set of test inputs and the outputs you accepted. This is your migration kit. It’s also the only honest way to compare two models, because vibes don’t survive a stakeholder meeting.
Store what you generated. If a vendor deletes your account data after an export window, anything you didn’t copy is gone. Save the outputs, the inputs, and the parameters that produced them. Treat the vendor’s storage as a cache.
Decide which features are allowed to die. Some AI features are the product. Others are a nice extra. If the extra vanishes for two weeks while you migrate, that’s survivable. If the product is the model, you have a different problem, which brings us to the uncomfortable part.
Where we’d push back
If your entire value is a thin wrapper around someone else’s model, no amount of clean architecture fixes your position. The vendor can ship your feature, reprice you, or retire the model. We’d say that plainly to a founder before they spend a year on it. A wrapper can be a fine way to test demand. It’s a poor place to stop.
The opposite error is also common: assuming you must self-host everything. For most products you shouldn’t. Hosted models are good, and running your own is real work. The goal is to make the vendor replaceable, not to remove them. A smaller open-weight model running on infrastructure you control is a reasonable fallback for the narrow tasks that matter most, even if the hosted model stays your first choice.
We do this kind of planning as part of our custom software development work. The question we ask early is the one the Sora API just answered for a lot of teams: what happens to this product on the day the vendor says no? If the answer is “we rewrite one module and rerun our test set,” you’re in good shape. If the answer is a long silence, that’s worth fixing while it’s cheap.
A useful exercise this week: list every external API your product calls, and next to each one write what you’d do if it shut down in 180 days. That’s roughly what Sora’s users got. If you’d like a second pair of eyes on that list, get in touch.