When a tool in your automation stack shuts down, gets bought and quietly wound down, or guts the plan you are on, the fix is rarely urgent if you saw it coming and often expensive if you did not. Before that happens, run a short audit: check whether the tool lets you export your data and configuration, confirm you have a realistic fallback, and note how deep your other automations depend on its API. When the sunset email actually arrives, export first, move your single most critical workflow next, and treat everything else as a scheduled migration instead of a crisis you have to solve overnight.
This applies to anything your automations depend on: a workflow platform like Make, Zapier, or n8n, a record-keeping tool a scenario reads from, a smaller SaaS app wired in through a webhook, or an AI model provider. It assumes you already have at least one working automation and a rough sense of which tools it touches. It is not a list of safer tools to switch to instead, and it is not a case against any one vendor. Almost every tool worth building on carries some version of this risk; the point is knowing which of yours does and having a plan before you need one.
How Often Do Automation and AI Tools Actually Shut Down in 2026?
More often than the headlines suggest, and less often than the running totals make it look. As of late August 2026, the AI tools registry ToolDirectory.AI tracked 285 AI and automation tools that had shut down outright or been acquired since it started counting: 135 gone entirely, 66 acquired and then wound down, and 84 acquired but still running under their own name. That figure is an aggregator’s running count, not an industry-wide census, and the registry itself flags the caveat worth repeating here: most of a given month’s increase is older shutdowns getting verified and added, not a sudden spike in tools dying that month.
The automation layer specifically is not immune. Relay.app, a workflow automation tool, stopped shipping in July 2026 and was confirmed into that registry the following month. August also brought a reminder that acquisition, not shutdown, is the more common risk: Airtable was bought by Bending Spoons, an acquirer known for reworking pricing and free tiers on the products it buys, and a payments company agreed to buy the AI routing service OpenRouter for a reported figure north of seven billion dollars. Neither product has shut down. Both are now owned by a company with different incentives than the one you originally signed up with, and that is the risk this checklist is actually built for: not a single dramatic outage, but a slow change in who controls the tool and what they decide to do with it.
None of this means you should avoid useful tools or treat every startup with suspicion. It means the same habit that protects a hard drive, a regular backup, applies just as well to the tools sitting between your data and your workflows. Ten minutes per tool, run occasionally, covers most of the risk below.
The Warning Signs a Tool You Depend On Is at Risk
None of these signs is proof on its own. Two or three of them together, on a tool you already depend on, is when the checklist below is worth ten minutes of your time.
- Support response times stretch out, or the vendor stops answering anything but urgent tickets.
- The changelog or public roadmap goes quiet for months after being active.
- Pricing changes arrive with little notice, or a previously generous free tier shrinks.
- Founders or the head of product leave and say little about why.
- The company gets acquired, even when the announcement says nothing will change for existing customers.
- A competitor starts running a public “migrate from [tool]” campaign, which usually means they are seeing churn worth chasing.
The Shutdown-Risk Checklist for Your Stack
Run this against each tool your automations would actually miss if it disappeared tomorrow, not your entire app list.
| Risk factor | What to check | Why it matters |
|---|---|---|
| Data export path | Does the tool offer a real export (CSV, JSON, or an API) for both your records and your configuration, not just raw data? | Without a working export, you are rebuilding from memory instead of files when you have to leave. |
| Self-host or alternative option | Is there a self-hosted version, an open-source equivalent, or at least one credible competitor you could move to inside a week? | A tool with no realistic substitute turns a shutdown into a scramble instead of a swap. |
| API or webhook dependency depth | How many other steps in your stack call this tool’s API directly, instead of routing through one connector you control? | A tool wired into three other automations costs far more to replace than one wired into a single step. |
| Contract or pricing lock-in | Are you on an annual contract, a grandfathered legacy price, or a free tier that could disappear without notice? | Lock-in changes your timeline for leaving from “whenever you want” to “whenever the term ends.” |
| Vendor communication pattern | Has the vendor gone quiet on release notes, support replies, or its public roadmap? | A vendor that stops talking to users is often further along in a wind-down than any announcement will admit. |
Score a tool as higher risk when it fails two or more of these, not just one. A tool with no export but an active changelog and responsive support is annoying to leave, not urgent to replace. A tool with no export, no alternative, and a quiet changelog is the one to move up your list.
How to Build a Lightweight Exit Plan for a Tool You Rely On
An exit plan here is not a migration project. It is five short lines per tool, written once and revisited only when something actually changes, so you are not researching your options for the first time under deadline pressure. Each entry covers the same five fields: the export path, a realistic fallback, how deep the dependency runs, what to watch for, and when to check again.
Here is what that looks like in practice. Say a client-onboarding automation built in Make watches for a new record in Airtable, formats the details, and sends a welcome sequence through a smaller email tool. Airtable was acquired by Bending Spoons in August 2026, an Italian company with a track record of reworking pricing and free tiers on the products it buys. That is not a shutdown signal on its own; Airtable is still running under its own name. It is exactly the kind of ownership change worth writing down.
The exit-plan entry for Airtable, in this example, might read:
- Export path: Airtable’s own CSV and API export covers your records; base structure and automations still need to be rebuilt by hand elsewhere.
- Fallback: a lighter spreadsheet-database tool can hold the same records if you move; test one before you need it, not after.
- Dependency depth: this automation’s trigger and two later steps read from Airtable’s API directly, so a pricing or access change breaks the whole chain, not just one step.
- Watch for: an official pricing-page change, a shrinking free tier, or a base feature getting removed rather than added.
- Review by: three months out, since the new owner has not published pricing plans yet.
That is the entire habit: five lines, revisited when something actually changes, not a full migration you run today just because the ownership did.
What to Do the Day You Get the Shutdown or Sunset Email
- Read the actual date. A sunset email gives a real deadline, not a suggestion; put it on a calendar, not just in your inbox.
- Export everything the tool holds first, through whatever path exists (native export, its API, or a migration path the vendor points you to), before anything changes.
- Move your single most business-critical automation first. Leave lower-stakes ones for later in the window.
- Read the fine print on what happens to your data after the cutoff date. Some vendors delete it immediately; others leave it accessible read-only for a while.
- Update anything else in your stack that still points at the old tool’s webhook URL or API key. An automation that looks like it is “still working” after the shutdown date is sometimes failing silently, not succeeding.
- Log what happened in the same place as your exit plan, so the next tool you adopt gets judged with this experience in mind.
Use This When (and Skip It When)
Use this checklist on a regular pass through your stack, before you add a new smaller tool to something that matters, or the moment you notice one of the warning signs above on a tool you already depend on.
Skip it for tools where the switching cost is already close to zero, or where self-hosting removes the vendor risk entirely. If you are weighing that trade-off for your workflow platform specifically, this comparison of n8n cloud vs self-hosted walks through what running your own instance actually costs in time against paying a vendor to carry that risk for you.
If you are still choosing which automation platform to build on in the first place, this decision framework for choosing your first automation tool covers the same lock-in question from the other direction, before you have anything riding on the answer.
Most tools in your stack will not shut down this year. The ones that do rarely give more warning than a single email with a deadline attached. The checklist above takes ten minutes per tool and turns that email from an emergency into a task you already have a plan for.