Vendor lock-in is not in the contract: cancelling Jira took me 2.5 months

The board had been empty for weeks before the invoices stopped.

We had already moved off Jira. Every story was in the new tool, nobody was opening the old tabs, and so I did the obvious next thing and went to cancel. That took over two and a half months and around twenty emails.

I want to be fair about what it was and was not. There was no retention specialist trying to talk me round, nobody was rude, and I do not think anyone was scheming. It was just unclear and a bit buggy. A cancellation that looked like it had gone through and had not. A product billed separately from the product I thought I was cancelling. A reply that carefully answered a question I had not asked. Then another few weeks of that.

Somewhere around email twelve it occurred to me that I had planned the migration in real detail and had spent exactly zero minutes planning the exit. I knew which status would map to which column. I had no idea how the account would close. That asymmetry is the actual shape of vendor lock-in in a project management tool, and almost nobody checks for it while they are choosing.

The contract is not where lock-in lives

I ran on Jira for twelve years, across every team I worked on. Nothing contractual kept me there. It was month to month, no minimum, cancel any time in principle.

What kept me was that I could not picture the leaving. The board had my process in it, statuses I had argued for in meetings I still remember. It had twelve years of tickets I would never read again and did not want to be the one to destroy. Every time the thought of switching came up it arrived pre-attached to a vague, heavy week I did not have.

That is what I mean when I say lock-in is a feeling rather than a line item. You do not get locked in by signing something. You get locked in by accumulating enough unmoved weight that moving stops feeling like a thing a person could just do on a Thursday. And a vendor does not have to be cynical to benefit from it. Any tool your team touches every day for a year will collect that weight on its own, mine included.

So the useful question is not whether you can get your data out. Technically almost everyone lets you. The question is what the exit costs in the currency you will actually be paying in, which is not dollars. It is afternoons.

What I look at now, before I commit

The first thing I check is whether cancelling is something I can do myself, in the product, at eleven at night. If the only path runs through a support inbox, the cost of leaving is not a price, it is a negotiation, and you have no way to estimate it in advance.

The second is the export. Not the marketing copy about the export, the file. Download it during the trial, open it, and look at which of your columns survived. This is the step I skipped and it is the cheapest one on the list.

The third is where the plan thresholds sit relative to how your team is shaped, because a threshold is a price rise attached to an org change you have not had yet. We moved to Linear after that Jira exit and I am still glad we did. It is faster, it is genuinely more developer-friendly, and it cost us less, partly because we had been quietly paying for Jira add-ons at six dollars per user per month that nobody could clearly justify. But Linear's plans are bounded by team count: as I write this, linear.app/pricing puts five teams on Basic at $10 per user per month billed yearly, and unlimited teams on Business at $16. That is not a trick, it is a published boundary and Linear is upfront about it. It does mean that splitting into a sixth team, which is an org decision, becomes a billing decision, which is a different kind of decision. Worth knowing before you are standing in it.

The fourth is who you are paying for. The thing that annoyed me most across all of it was paying full seats for people who only ever wanted to look at the board. That is not lock-in exactly, but it is the same family: a cost that grows with something other than the value you are getting, until leaving starts to look like the cheaper option.

Building the exit first

When I sat down to build Scrumpy, I had that email thread in mind, and I decided the exit was a feature rather than an afterthought.

Cancelling is a button in billing settings. One confirmation dialog, which tells you the date your access runs to, and that is the whole flow. You keep editor access until the end of the period you already paid for, and if you change your mind before then you resume in one click. It does not route to me. I never see it happen unless I go looking, and that is deliberate, because the moment a human has to approve your departure, your departure has a queue.

If you want to go further than cancelling, Delete organization sits in the danger zone of organization settings. You type the organization name and everything goes: teams, stories including the soft-deleted ones, comments, uploaded files, the activity log, and the billing records. Nothing is quietly retained in case you come back. That was an uncomfortable thing to write, since a deleted account is a customer I have definitely lost, and it is still the right behaviour.

The other half is that leaving should not be the only supported direction. Import takes a CSV from Jira or Linear, maps each source status onto one of your columns, and shows you a preview of exactly what will be created before it creates anything. If you are on the Jira side of that, the column-level detail of a Jira CSV export is worth twenty minutes of your attention. And the people who only watch the board are free and unlimited, on one flat per-editor price with every feature in it, so the bill only tracks the people actually moving cards. I have written before about why view-only seats should never be billable.

The part I am least happy about

Here is where I have to concede something, because a post about honest exits that oversells its own exit would be worthless.

Scrumpy's export is an Excel .xlsx file. One sheet per team, one row per story, eight columns: reference, title, epic, sprint, status, story points, assignee, and whether the story was deleted. That is a good snapshot. You can hand it to a stakeholder, keep it as an archive, pivot it for reporting.

It is not a migration format, and I should say so plainly. Story descriptions are not in it. Neither are comments or attached files. If you left Scrumpy tomorrow with that spreadsheet, you would carry your board's skeleton and leave its conversations behind. A tool that imports CSV but exports a spreadsheet has an asymmetry in it, and the asymmetry runs in the direction that happens to suit me. I know exactly how that looks.

There is a smaller confession attached. For a while Scrumpy's own homepage, support page and even the privacy policy all said the export was JSON. It was never JSON. I had written that early, believed it, and repeated it in three places, including the one place where a wrong claim about your data is actually a legal statement. Nobody reported it. I found it myself while checking something unrelated, and fixing it took about four minutes, which is roughly four minutes more than I had spent verifying it in the first place. Wrong claims about the exit are exactly the ones nobody catches, because almost nobody tests the exit until they need it, and by then they are not in the mood to file a bug.

What an easy exit costs me

Two organizations were subscribed as I write this. That is small, and it is the whole reason I can answer every bug report and every feature request myself, whether you are a hundred-seat company or one developer with a side project.

An easy exit is expensive at that size. It means no month is safe. There is no annual contract carrying a customer past the point where they stopped enjoying the product, no support queue absorbing the friction of leaving, no dark pattern doing the retention work that the board is supposed to do. Every month, the board has to be worth it again, or someone clicks the button and that is that.

I would rather compete on that.

That Jira thread eventually ended with a short confirmation and no explanation of what had taken so long. I kept it. Not out of spite, I genuinely liked plenty about the tool and it did twelve years of honest work for me. I kept it because it is the closest thing I have to a spec.

If you are picking a tool right now with one bad exit already behind you, do the thing I did not do. Before you commit, try leaving. Start a trial, put a real sprint in it, then export the file, open it, and cancel the whole thing yourself. Do that on every tool on your shortlist. Whichever one you come back to, you will at least know what it costs to change your mind.