When the AI tool you depend on gets bought

You did not choose most of your stack. You chose one or two things on purpose and inherited the rest: the notes tool a client was already using, the automation platform a contractor set up in an afternoon, the assistant that happened to be good the month you needed one. Then it works, so you stop thinking about it, and eighteen months later that tool holds your templates, your prompts, your client history and the four automations that send your invoices.

Then the company gets bought, or restructures its plans, or moves the feature you rely on up a tier. Nothing breaks that day. Nothing usually breaks for a year. What changes is who decides the terms, and you find out how much of your business lives inside someone else’s product on the worst possible schedule. This guide is a way to find out on your own schedule instead: rank tools by what you would lose, run the exports while nothing is wrong, and be honest about the dependencies no export can fix. It is written for a one-person business or a small team spending its own money. If you have a procurement function, a vendor risk register and a security questionnaire, you already have a heavier version of this and should use that one.

An acquisition changes the terms, not the software

On the day a deal is announced, your account works exactly as it did the day before. Nothing about the software changes when the ownership does, and no buyer paying a serious price starts by breaking the thing they bought. The mistake is reading that calm as safety. What an acquisition transfers is the right to set prices, define tiers, write the retention and moderation policy, decide whether the free plan continues to exist, and decide which of the new owner’s other products becomes the default path through the platform you use.

Public promises made at signing are worth recording, precisely because they are checkable later. When Nvidia announced on 3 September 2026 that it would acquire Hugging Face for $12,930,300,000, Jensen Huang said that “Hugging Face will remain an open platform for the entire AI ecosystem” and that “NVIDIA compute will not be required to build on or deploy through Hugging Face” [1]. Those are specific commitments with a date attached, which makes them the useful kind. Save the page, note the date, and treat any future change as something to measure against it rather than something you half-remember.

The particular deal matters less than the pattern. Infrastructure that gets built as neutral plumbing becomes valuable, and valuable things get bought. The same week, somewhere, a smaller tool you use is being wound down, repriced, or quietly moved behind a higher plan. Acquisition is just the version of that story that makes the news.

Rank your tools by what you would lose, not by what you pay

Your bill is a poor guide to your exposure. The assistant subscription you pay for every month is usually the cheapest thing to replace; the free automation account may be the most expensive.

Sort your tools into three groups. The first holds conversations. Chat assistants sit here. If one disappeared tomorrow you would lose chat history and some habits, and you would be productive on a competitor within an hour, as long as the prompts you actually reuse live in a file on your own disk rather than scrolled somewhere in a thread. The second group holds assets: your documents, your client notes, your knowledge base, your site content. Notion sits here for a lot of people. Losing this group costs you an export and a rebuild, measured in days, and the rebuild is worse than you expect because structure does not survive as well as text. The third group holds logic and credentials: the automation platforms, and anything that has an authorised connection into your inbox, your store, your bank feed or your calendar. Losing this group means rebuilding work you cannot see, and it is the group most likely to break something else on its way out.

Now do the only part of this exercise that matters. Beside each tool write one number: the days it would take you to be running again without it. Not the cost, not a risk rating out of five. Days. Most people find the number is under a day for two-thirds of their stack and alarmingly undefined for two or three tools, and those two or three are the entire subject of the rest of this guide.

Run the export once, while nothing is wrong

Every serious vendor has an export. Almost nobody has run theirs. That matters because an export is not a button that hands you a file; it is a queued job with a delivery method and an expiry, and the first time you meet those mechanics should not be the week you are trying to leave.

In ChatGPT, the export lives under Settings, then Data controls, then Export data. It arrives as a ZIP containing your chat history and other account data, OpenAI notifies you by email or SMS when it is ready, exports can take up to 7 days to arrive, and the download link expires 24 hours after you receive it [3]. In Claude, it is Settings, then Privacy, then Export data; the export covers conversation data and your account’s user data, arrives as an emailed download link that expires 24 hours after delivery, and is available on Free, Pro and Max plans from the web app or desktop app but not from mobile [4]. Notion’s “Export all workspace content” gives you pages as HTML or Markdown with databases as CSV, plus the files you uploaded and an index.html sitemap to navigate them; a very large export may be delivered as an emailed download link instead of starting automatically, that link expires after 7 days, and the export itself can take up to 30 hours to process depending on the size of the workspace [5].

Read those three sentences again as a schedule rather than as trivia. A tool that takes up to 7 days to produce a file and then gives you 24 hours to collect it is a tool you cannot leave in a hurry. Plan restrictions compound this: on Notion, the “Include subpages” option and full-workspace export to PDF are limited to Business and Enterprise plans, so a Free or Pro workspace exports to HTML or Markdown and CSV instead [5]. That is a fine outcome if you know about it in advance and a bad surprise if you discover it at hour 29 of a 30-hour job.

One more step, and it is the step people skip. Open the file. An export you have never unzipped is not a backup, it is a feeling. Find the specific thing you would need first, a client’s project notes or the prompt you use every Monday, and confirm it is in there and readable without the vendor’s software.

Automation logic is the part that does not port

Automation platforms are where the “days to be running again” number goes from hours to weeks, because what they hold is not text.

Some of them do export. In n8n, workflows are stored as JSON and you can download the current workflow as a JSON file from the editor, or move them with the CLI or the API; note that the exported file includes credential names and IDs, and the documentation tells you to remove or anonymise that information before sharing the file [6]. In Make, the equivalent is a blueprint, exported from the three-dot menu in the scenario builder as a JSON file containing the modules, their settings and the mapped values; blueprints do not include connections, so after importing one you re-authorise every account by hand, and an imported blueprint has to be under 2 MB [7].

Both are genuinely useful, and neither is portability in the sense you want. A Make blueprint imports into Make. An n8n workflow imports into n8n. The export protects you against losing an account or breaking your own scenario, not against the platform changing its pricing, because no competitor reads the other’s file. Automation logic is rebuilt by hand every time it moves, which is exactly why the tools in this group deserve a different kind of insurance.

That insurance is boring and it works. For every automation you actually depend on, keep a plain-text page that says what triggers it, what it does in order, which accounts it touches and what happens if it fails silently. Keep it outside the automation tool. Anyone competent can rebuild from that page in an afternoon on any platform, and you can read it when the platform’s UI is the thing you have lost access to. Then confirm you personally hold the logins and API keys for every service those automations connect to, because the most common way an automation platform hurts you on exit is not the logic; it is discovering that the connection to your payment processor was authorised under a contractor’s account.

In the EU, leaving is a legal right with dates attached

If your business is in the EU, some of this stopped being a matter of vendor goodwill. The Data Act became applicable on 12 September 2025 and requires providers of data processing services to let customers switch to another provider quickly and smoothly without losing data or the functionality of their applications [2]. In practice that means providers of platform and software services have to make open interfaces available, exports have to be in a commonly used and machine-readable format, infrastructure providers have to offer functional equivalence, and obstacles to using more than one provider have to come down [2]. Switching charges, including charges for data egress, are removed entirely from 12 January 2027 [2].

Two things follow for a small operator. First, “we do not support exporting that” changes from a fact you accept to a claim you can push back on, in writing, with a regulation number. Second, you often benefit even outside the EU, because vendors tend to build one export path and one switching process rather than two.

Be clear about the limit, though. The right covers your data. It does not hand you the vendor’s product, and it will not turn one platform’s automation logic into another platform’s automation logic. It shortens the days number for the second group of tools, the ones holding your assets. It does very little for the third.

Some dependencies cannot be exported at all

Take the case the news made famous. Model weights are files, and files are portable by construction: models on the Hugging Face Model Hub live in Xet-backed Git repositories you can clone locally once you have installed git-xet and git-lfs, or pull with the hf download command from the client library [8]. Anyone who mirrors the specific weights they depend on into their own storage is insulated from almost every plausible bad outcome at the hosting layer, from a price change to a takedown to an outage.

And that mirror does not save the thing most people actually use the site for. The reason it became the default was never the file storage. It was that a new model appears there within hours of release, that the discussion under a model card tells you a checkpoint is broken before you waste a week on it, and that everyone publishes there first. You can copy a file. You cannot copy the fact that other people are there.

Apply that split to every tool you depend on. Ask which half of its value is your data and which half is other people. Where the value is your data, an export solves the problem and the checklist below is the whole answer. Where the value is a marketplace, a community, an integration directory or the place your clients already expect to find you, exporting solves nothing, and the only real mitigation is different: keep the relationships themselves outside the platform. Client contact details, your mailing list and your own site are the version of those assets that you own, and they are the ones worth being slightly paranoid about.

What still goes wrong

Export mechanics change. Every figure above is cited to a vendor’s own page and verified on the date in this guide’s header, and the plan restrictions in particular are the sort of thing that moves quietly. Check the source before you build a plan around a number, including the numbers here.

Portability discipline also has a real cost, and the failure mode is doing too much of it. You can spend a week a quarter exporting from tools that will comfortably outlive your business, which is a way of feeling careful rather than being careful. Proportion it to the days number: run this properly for the two or three tools whose loss would stop you invoicing, and let the rest go unexamined. If a tool holds nothing you could not rebuild in an hour, it does not need a procedure.

The deepest problem here is one no export addresses. You can hold every file, document every automation and still lose something when a tool changes, because part of what you built was tuned to a specific product’s behaviour: the prompts that worked on that model, the shortcuts your team learned, the way that particular editor let you think. Data migrates. Fluency does not. That is not a reason to avoid depth, and a business that refuses to commit to anything never gets good at anything. It is a reason to know which of your tools you are deliberately deep in, so that when one of them changes hands you are making a decision rather than discovering a dependency. Choosing well in the first place helps, and the procedure for that is in how to choose AI tools for a small business.