Will your tracker still exist next year? Switching-cost anxiety, and the one-command exit

You are not really deciding whether a tracker is good today. You are betting on whether it will still be the tracker you want a year from now, after the funding round, the acquisition, the pivot to an AI platform, or the quiet shutdown email. That bet is the real cost of adopting a tool, and almost nobody puts a number on it before they commit.

That hesitation has a name in the strategy books: switching costs. The reason you dread moving trackers is the pile of work it takes to leave one and land in another, plus the risk that the data does not come cleanly with you. Vendors know this. Building a moat out of your switching cost is a documented business strategy, which is a polite way of saying the harder it is to leave, the less they have to earn your staying.

So the honest question to ask any tracker, ours included, is not "what can it do." It is "how expensive is it to walk away, and who controls that number." If the answer is "us, and we would rather you didn't," you are looking at a cage with good lighting.

#Switching cost is the fear you are actually feeling

When you stall on picking a tracker, three separate anxieties are wearing one coat.

• Will it still exist? New tools launch daily and a lot of them sunset before they mature. One count logged roughly 95 tool shutdowns and 101 acquisitions across an 18-month window. Adopting something that disappears in four months is a switching cost you pay twice: once to leave, once to relearn whatever comes next.
• Will it still be the tool I chose? Acquisition and the pivot-to-AI-platform reflex mean the tracker you liked can become a different product on a Tuesday, with a copilot you did not ask for and a meter you did not sign up for. The features are the same; the deal is not.
• Can I even get my data out? This is the one that actually traps people. If your issues, comments, and history only live inside one vendor's database behind an export button that "is on the roadmap," you do not own your work. You are renting access to it.

The first two are bets about the future you can never fully win. The third one is different: it is mechanical, it is testable today, and it is the one that decides how much the first two can hurt you. If leaving is one command, a vendor sunsetting or changing its deal is an inconvenience. If leaving is a support-ticket-and-a-CSV-you-have-to-request project, it is a hostage situation.

#Price the exit before you price the entrance

The way to defuse switching-cost anxiety is not a vendor's promise to stick around. It is to make the exit so cheap that the promise stops mattering. Before you adopt any tracker, run the leave test:

1. Is a full export a feature or a favor? Can you pull everything (issues, projects, labels, comments, history) yourself, on demand, without emailing anyone? Or is it a gated, slow, "contact us" path?
2. What format comes out? JSON and CSV are portable and boring in the good way. A proprietary blob you can only re-import into the same product is not an exit; it is a receipt.
3. Who decides when you can leave? If the export lives behind a plan tier, a contract clause, or a human on their side, they own your exit, not you.

A tracker that passes all three has priced your switching cost to near zero on purpose. That is not a small feature buried in settings. It is the whole trust argument. Calm, durable software you cannot leave is just a nicer cage, and the export is the lock you get to hold the key to.

#Verifiable today: the exit is one command

Here is Radial's answer to the leave test, and it is a command, not a paragraph. Your entire workspace comes out in one call, JSON or CSV, whenever you want it, with no ticket and no plan gate:

# Full workspace export, human-readable JSON, straight to a file
radial export --format json -o radial-backup.json

# Or CSV, for a spreadsheet or a different tool's importer
radial export --format csv -o radial-backup.csv

That is the real CLI (npm i -g radial.build). Issues, projects, labels, comments, and history come out in a portable format your scripts, your backups, and someone else's importer can read. Run it on a cron if you like; the export is always available, not a quarterly favor. The same data is reachable over the REST API at api.radial.build/v1/export with a scoped, revocable key, so your agent or your CI can snapshot the workspace too.

Coming the other way is symmetrical, because we would rather earn your staying than trap your leaving: radial import --from linear and radial import --from jira bring your issues, projects, labels, comments, and history in, and you can --dry-run first to see exactly what would land. Low switching cost is a two-way street. We made it cheap to arrive and cheap to go, and we are betting you stay because the tool is worth staying for.

#The other half of the promise is written down

An export answers "can I get my data out." It does not answer "will the deal change out from under me." So the exit command comes with a stance we put in writing, the Plain Software Pledge: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free. And the price it protects is one flat number, $50 per user per year, billed annually, locked, agents ride free.

That is the second lever on switching-cost anxiety. The export means the vendor sunsetting or getting acquired cannot strand your data. The pledge and the locked price mean the vendor changing its own deal costs them, not you. Between the two, the "will it still be the tool I chose next year" bet stops being a bet you can lose quietly.

Note what this is not: it is not anti-AI. Bring your own agent, your model, your keys, and drive the tracker through the CLI, the MCP server at mcp.radial.build, or the REST API. The intelligence is yours. The tracker just stays a fast, portable system of record you can leave in one command. The enemy of a durable tool is the uninvited copilot and the meter, not AI.

#FAQ

#What is switching cost in software?

It is the total real and perceived cost of moving from one tool to another: the time to migrate data, the effort to relearn workflows, the risk that something does not come across cleanly, and any contractual friction. In trackers, the biggest hidden piece is data portability. If you cannot cleanly export your issues, comments, and history, the switching cost is effectively infinite, which is exactly how lock-in works.

#How do I avoid getting locked into a project management tool?

Run the leave test before you commit, not after. Confirm you can export everything yourself, on demand, in a portable format (JSON or CSV), without asking a human or upgrading a plan. If the full export is gated, slow, or "on the roadmap," treat that as the vendor telling you they intend to make leaving expensive. Adopt tools where the exit is a feature you control, not a favor they grant.

#What happens to my data if my issue tracker shuts down or gets acquired?

That depends entirely on whether you can export it before you need to. If the tracker offers a self-serve, on-demand full export, a shutdown or acquisition is an inconvenience: you pull a backup and move. If export is gated or manual, you are dependent on the vendor's goodwill and timeline during exactly the moment they are least motivated to help. The fix is to snapshot your workspace regularly while everything is calm, so a bad email never catches you flat.

#Does Radial let me export all my data?

Yes, in one command, JSON or CSV, always available, no ticket and no plan gate: radial export --format json -o backup.json (or --format csv). It includes issues, projects, labels, comments, and history, and the same data is reachable over the REST API at api.radial.build/v1/export. Import back in from Linear or Jira with radial import --from linear|jira. Low switching cost, both directions, on purpose.

#Isn't making it easy to leave bad for the vendor?

It is bad for a vendor whose retention strategy is trapping you. It is good for one whose strategy is being worth staying for. Making the exit cheap is a forcing function: it means we have to keep earning your subscription every year instead of collecting it because leaving is too painful. We would rather compete on the tool than on the moat built from your switching cost.

#Pick the tracker you could leave and choose to stay

The tool worth adopting is the one you could walk away from tomorrow and don't want to. Test the exit first: pull a full export yourself, in a format you can read, without asking permission. If that command exists, the "will it still exist next year" anxiety shrinks to something you can actually live with, because the worst case is a one-command migration, not a lost year of work.

Read what we will and won't do in the manifesto, see the one flat number on pricing, or dig into the CLI and export on the developer docs. And if you want the fuller case for a tracker that gets out of the way and stays that way, here is why boring on purpose is the bet.