When your AI tool changes hands

The software you run your business on is owned by companies, and companies get sold, merged, folded into a larger product or pointed at a customer much bigger than you. The terms you agreed to already say so. Cursor’s say the company “may assign these Terms and all rights granted under these Terms, including with respect to your Content, at any time without notice or consent” [1]. Anthropic’s consumer terms put it more plainly still: the agreement “may not be transferred or assigned by you without our prior written consent, but may be assigned by us without restriction” [2]. OpenAI names the case directly, reserving the right to assign its rights or obligations to “any affiliate, subsidiary, or successor in interest of any business associated with our Services” [3].

So the question is not whether your tools might change hands. It is what you would do on the morning it happens, and how much of that work you can do now, while everything still functions and nothing is urgent. This guide is for one person or a small team paying by card. If you have a procurement function, a negotiated contract and change-of-control clauses you argued over, you have levers that are outside the scope here, and you should use them.

Your account travels with the company, not with you

An acquisition does not need your agreement. Read those three assignment clauses again and notice what is missing from all of them: any step where you are asked. The contract moves, your data moves with it, and the first you hear is usually a blog post [1] [2] [3].

The same terms that allow the sale usually allow the product to change on the same footing. Cursor’s terms state that Anysphere “may modify or discontinue all or any portion of the Service at any time (including by limiting or discontinuing certain features of the Service), temporarily or permanently, without notice to you” [1]. That clause is unremarkable. Most consumer and self-serve terms read like it, because they are written for a company that expects to change shape. It is worth internalising anyway, because it tells you exactly how much protection the contract gives a small customer. Roughly none. Your protection is operational, not legal: it is the export you already have and the alternative you have already tried.

None of this makes an acquisition bad news. A better-funded owner can pay for reliability, security review and support that a startup could not. The point is narrower. Every reason you chose the tool that involved the company behind it, its priorities, its willingness to answer email, its interest in customers your size, has just been handed to someone else to decide.

The notice you get is measured in weeks

People imagine a long, well-signposted wind-down. The published commitments are shorter than that, and they are not about ownership at all.

OpenAI promises “at least 30 days advance notice of changes to these Terms that materially adversely impact you either via email or an in-product notification” [3]. Anthropic tells consumers that where a fee change increases what they pay, “we will inform you at least 30 days in advance of the change” [2]. Those are the two commitments a small customer actually has, and both assume you read the email that arrives at the billing address. Neither vendor promises to warn you before the company changes owners, because that is not something terms of service normally cover.

Notice also arrives in places you may not be watching. OpenAI’s commitment is to tell you “either via email or an in-product notification” [3], which means the warning can be a banner inside a tool you happen not to open that week, sent to whichever address is on the card. If the billing address is a shared inbox nobody reads, or an alias that forwards to a filter, you have quietly opted out of the only warning you were promised. Fixing that takes two minutes and is the highest-value thing in this guide.

On the technical side the windows are published and slightly longer. OpenAI’s deprecation policy gives generally available models “at least 6 months” and specialised variants “at least 3 months”, and warns that preview models “may be retired with much shorter notice, such as 2 weeks” [4]. Anthropic says it gives “at least 60 days’ notice before model retirement for publicly released models” [5]. Plan your response around 30 days and you will rarely be caught out. Plan around a year and you will be.

Products move under you without any acquisition

The uncomfortable part of this topic is that acquisitions are only one cause of a change you did not choose, and not the most common one. The most common one is the ordinary schedule of retirement that the model vendors publish themselves [4] [5].

Look at the dates rather than the policy. Anthropic’s model status table lists claude-opus-4-1-20250805 as retired, with a retirement date of August 5, 2026, and marks claude-haiku-4-5-20251001 as still active while already publishing a tentative retirement “not sooner than October 15, 2026” [5]. A model you are using today can carry a printed earliest expiry date while nothing at all is wrong with it. On OpenAI’s side, the deprecations log records that “on August 26, 2026, we notified developers using whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-transcribe-diarize of their deprecation and removal from the API on February 26, 2027” [4]. If a workflow of yours calls one of those transcription models, it has a removal date already printed, and no company had to be sold for that to happen.

This is the reframe worth keeping. An acquisition, a model retirement, a pricing change and a feature being quietly dropped are the same event wearing different clothes: a component you depend on stops behaving the way it did, on a date somebody else chose. Treat them with one procedure instead of four moods. Write down, for each workflow that matters, which model or feature it actually calls and what the vendor has published about that component’s lifespan [4] [5].

Export is slower and narrower than the button suggests

Everybody’s plan is “I will export my data if something happens.” Almost nobody has timed it.

ChatGPT’s export is not instant. OpenAI’s help page states that “exports can take up to 7 days to arrive”, and that once it does arrive, “the download link expires 24 hours after you receive it” [6]. Put those two sentences together and the failure mode writes itself: you request the export the week you are away, the mail lands on the Tuesday, and by the time you look it is dead. Notion has a similar shape with a different limit. The download link there “will expire after 7 days”, and exporting the whole workspace to PDF is gated by plan: “if you’re on a Business or Enterprise Plan, you can also export your entire workspace to PDF” [7].

There is a second, larger gap. An export is not a migration. A zip of markdown files is your content, not your setup, and the things that make a tool valuable, the connected accounts, the automations, the small configurations you tuned over a year, are usually the parts that do not come out in the archive. So run the export now, while nothing is wrong, and then open it. Look at what came out and what did not. The list of things missing from the zip is your real dependency list, and it is more useful than the zip.

One rehearsal beats a plan

The cheapest insurance is not a document. It is having done the thing once. Pick the single task that matters most in the tool you would least like to lose, and do that one task somewhere else for a day. Draft the client email in the other assistant. Rebuild the one automation in a second platform. You are not switching, you are measuring, and what you are measuring is how many hours a forced move would cost and which pieces you had forgotten existed.

Do this while the tool is healthy, because the usual acquisition announcement gives you nothing to react to. Cognition’s post announcing that it had “signed a definitive agreement to acquire Windsurf, the agentic IDE” is written mostly for other audiences. It sets out what was bought, including “$82M of ARR and a fast-growing business” and “350+ enterprise customers”, and how the acquired staff would be paid [8]. The part addressed to people who use the product is one line of reassurance: “in the immediate term, the Windsurf team will continue to operate as they have been” [8]. That is the normal case, and it is not much to act on. Nothing breaks that week, or that quarter.

There is one thing worth doing in the weeks after an announcement, and it is not switching. It is watching for the paperwork. The deal is the headline; the change that touches you is the updated terms, the new privacy policy, or the reshuffled plans that follow months later. Diary a check for the quarter after the deal is expected to close, and when the new terms land, read the two clauses that matter to a small customer: what the company may do with your content, and what happens to the plan you are on. Those are the same two questions you would ask of any new vendor, which is what this one has now become.

Price the dependence before you rank the tools

Small teams tend to rank tools by how much they like them. Rank them instead by what leaving would cost, because that number is what an ownership change actually threatens. Two or three tools will carry most of your work, and those are the only ones that need this attention. A tool you would replace in an afternoon needs none.

Run that for each of your critical tools and a rule falls out. Anything whose forced replacement would cost more than a week of your time gets three things: an export on a repeating schedule, one named alternative you have tried, and your work held in a format that is not exclusive to the vendor. Everything else gets nothing, which is the point. The goal is a short list you maintain, not a permanent state of vigilance about software.

What still goes wrong

The drill protects your data and your options. It does not protect your budget. If the tool that carries your week doubles in price, you get your 30 days of notice [2] [3], and then you either pay or absorb the switching cost you calculated above. Portability gives you a choice between two bad options rather than one, which is worth having and is not the same as safety.

The harder failure is that some dependencies are not portable at all. Your files come out of a coding tool easily; the specific behaviour of the model underneath it does not, and neither do the habits you built around it. When a vendor retires a model on a published date [4] [5], the replacement is a different thing that needs its prompts, its checks and its tolerances re-established. No export helps there, and there is rarely a like-for-like alternative to move to. The honest answer is to keep the number of workflows that depend on one exact model small, and to accept re-tuning as a recurring cost of building on other people’s software.

Finally, rehearsals go stale. The alternative you tested a year ago has changed, your setup has grown, and the export that worked then may now miss the half of your system you added since. That is why the last checklist item is a repeat date rather than a filed document. The thing that keeps you free is not knowing the escape route. It is having walked it recently enough to trust the map.