The switching cost nobody puts in the spreadsheet
Moving the data is the part everyone plans for. It is almost never the part that hurts, and the three costs that do are invisible until you are committed.
Ask anyone who has moved a team off one tool and onto another what the hard part was. Almost nobody says the export.
Four costs, one of them visible
When a switch gets planned, the thing that gets estimated is the migration: how many items, does an importer exist, how long will it take, who does it. That estimate is usually roughly correct, which is part of the problem. It is correct, it is the only number anyone produced, and it turns out to describe the smallest of the costs involved.
Moving the data
Export, import, fix what did not survive the shape change. Bounded, estimable, and genuinely the easy part on any tool built in the last decade.
Losing your fluency
Every shortcut, every habit, every place you knew without looking. This is months, not days, and during it you are slower at work you were previously good at.
Rebuilding the joins
Whatever connected the old tool to everything else: automations, links in documents, saved searches, the one script somebody wrote. These are discovered by breaking them.
Spending other people's attention
If anyone else touches it, the switch costs their learning time too, and it costs you the standing you spend asking for it. That budget is smaller than people think.
The three invisible costs share a property that makes them hard to argue with in advance: they are all paid after the decision, by a version of you who is already committed and therefore motivated to describe them as teething problems.
The month you are worse at your own job
The most underrated cost of switching is the period in which you are visibly less competent at something you were previously good at. Not because the new tool is worse, but because expertise in a tool is largely invisible until it is gone.
You knew where things were. You knew which view to open. You had a set of small, unrecorded routines that made the work go without thinking about it. All of that was real capability, it took months to accumulate, and it does not transfer. The new tool may be better in every respect that could appear on a comparison table and still leave you slower for a month, because you are a beginner again at a thing you had stopped noticing you were skilled at.
This is a genuine cost and it should appear in the decision, but it is not an argument against ever switching. It is an argument for switching rarely, deliberately, and one thing at a time, so that the month of reduced competence is spent once rather than continuously. The failure pattern is not one switch. It is a switch every quarter, which means never accumulating fluency in anything.
Why the old tool keeps running
Here is the outcome that quietly consumes the most time, and it almost never appears in anybody's plan, because nobody plans it. It just happens.
The migration completes. The new tool is in place. And the old one does not get turned off, because there is one thing it still does better, or one archive nobody wants to move, or one colleague who has not switched. So both run. And running two systems does not cost the average of the two; it costs more than either, because now every item needs a decision about where it lives and every search needs to happen twice.
The dual running trap
- Two systems cost more than either one alone, because the overhead is the choosing, not the using.
- The state is stable: neither system is bad enough to force a resolution, so it can persist for years.
- The fix is a decommission date agreed before the migration, not after.
- If you cannot name a date the old tool goes read-only, you are not switching. You are adding.
Our judgement: the single most useful discipline around switching is to treat the shutdown of the old thing as the deliverable, rather than the launch of the new one. A migration that ends with both systems live has not succeeded. It has doubled the surface area and called it progress.
Sunk cost points both ways
The usual warning about switching costs is that people stay too long with a tool because they have invested in it, which is a sunk cost error and worth resisting. That is true and you have heard it.
The less commonly stated version is that the same error operates in the other direction once a switch is underway. Having spent two weekends on a migration, having told colleagues this would be better, having made it a small matter of judgement, you are now the person with the strongest possible incentive to conclude that it worked. The evidence you will gather from that position is not neutral.
The practical defence is to write down, before you start, what would count as the switch having failed. Something specific enough to be checkable: a task that must be faster, a step that must disappear, a date by which the old tool is off. Written in advance, that is a test. Written afterwards, it is a description of whatever happened.
Three conditions that justify it
None of this is an argument for never moving. Tools genuinely do become wrong, and staying too long has its own compounding cost. But the case for a switch is stronger when it rests on a structural problem rather than a preference, and in our view a switch is straightforwardly justified when at least one of these is true.
-
The current tool blocks something you actually need to do
Not does it awkwardly: cannot do it. A missing capability is a real reason and it survives the enthusiasm wearing off. “Clunky” usually does not, because clunky is often just unfamiliarity you have forgotten having overcome.
-
The cost is rising and will keep rising
A price change, a licence model that punishes growth, a maintenance burden that grows with your data. If the trend line is against you, moving early is cheaper than moving later, and this is the one case where speed helps.
-
The tool is at risk
Acquired, unmaintained, losing its platform, or built on something being withdrawn. Moving on your own schedule is enormously cheaper than moving on somebody else's, and this is the only condition where we would move before the pain arrives.
Everything else, including “the new one is nicer”, is a preference. It is allowed to be a preference. It should just be priced as one, against the four costs at the top of this page, rather than presented as a necessity.
The cheaper move, most of the time
Before a switch, there is nearly always a smaller intervention available, and it is worth exhausting the smaller ones first because they are reversible.
- Change how you use the current tool. A surprising share of tool frustration is configuration that was set once, at the beginning, by someone who did not yet know how they would work. Spending an hour on settings is cheaper than spending a month on a migration.
- Add one narrow tool beside it rather than replacing it. If the problem is a single missing capability, a small tool that does that one thing is usually cheaper than moving everything to a system that includes it, provided you are honest that this counts as a new seam.
- Remove a step rather than a tool. Quite often the tool is fine and the process around it has accumulated a step nobody needs. That step is free to delete and it does not cost anyone their fluency.
The general shape of the advice: switching is a large, mostly invisible expense that gets justified by a small, visible one. It is sometimes right. It is right less often than it feels, and the way to tell the difference is to price the parts of it that do not appear in the plan.
On what this is based on
This piece is editorial reasoning about a pattern, not a study. Workflow Vitals has not surveyed teams, measured migration times, or collected data on abandonment rates, and no figures are given above because we do not have any that would survive scrutiny. Where you see a claim about how something typically goes, read it as our judgement, offered so you can disagree with it.