What switching tools actually costs: the time, the data, the quarter

By Marcus Webb · Framework, October 23, 2026 · Not a review

"We should switch" is almost always true on paper and often wrong in practice. The reason is that switching has a price that never appears in a comparison table: the hours, the lost history, and the quarter in which nobody is quite sure where anything lives. Here is that price, itemised, so you can compare it against the savings you think you are capturing.

The four costs

• Evaluation. Two to six hours per candidate, honestly done — trialling, importing a sample, checking the export. Three candidates is a day.
• Migration. One to three days for a small team's project tool; longer for a CRM with history. Most of it is not technical, it is deciding what each field meant.
• The parallel run. Two weeks where both systems are live and someone maintains both. This is the step teams skip, and it is the one that prevents month-two surprises.
• The productivity dip. Two to six weeks of slower work while muscle memory rebuilds. Nobody bills for this and everybody pays it.

Turning it into money

For a five-person team: evaluation 8 hours, migration 24 hours, parallel run 10 hours of extra admin, dip equivalent to maybe 30 hours of reduced output. Total 72 hours. At $75/hour that is $5,400 — roughly two years of a $225/month software bill.

This is the arithmetic that decides most switches, and it produces a clear rule: a switch is worth it when the annual saving exceeds about 40% of the migration cost, or when the current tool is failing at something that costs revenue. The second condition is the more common and the more important one.

The switch is worth it when…

• Something is broken, not merely inconvenient. The tool cannot do a thing your business depends on, and there is no workaround. That is a real reason.
• The savings are structural, not promotional. Moving from per-seat to flat pricing at twenty users changes your cost curve permanently. Moving to capture a first-year discount does not.
• Adoption has already failed. If the team stopped opening the tool two months ago, you are paying for nothing. The migration cost is real and the status quo is also a cost.
• You are being taxed on growth. A percentage fee on revenue, or a hard seat cap at the size you are about to become, both get worse with success. Those justify the move before the pain arrives.

The switch is not worth it when…

• The only complaint is the interface. Interfaces are learned in three weeks; migrations are forgotten in three months but cost six.
• You are chasing a feature you have not used in the current tool either. This is the most common bad reason. If you never built the automation in the old product, you will not build it in the new one.
• It is mid-quarter. Migrations and revenue events should not share a month. The cost of the dip doubles when a deadline is in it.
• You have switched twice already. Three tools in two years is a process problem wearing a software costume. The fourth will not fix it.

If you do switch, do it in this order

1. Export first, open the file, count the losses. If activity history and notes are missing, you are deciding to lose them — make that explicit.
2. Import twenty records, not all of them. Check dates for timezone shift, check owners, check stage mapping, then export those twenty back out to confirm the exit works.
3. Run both systems for two weeks. Old tool read-only, new tool as the place new work is recorded.
4. Announce the cutover date in advance and make it absolute. Two live systems indefinitely is the most expensive outcome available.
5. Keep the old account for 30 days after cutover. Read-only, unpaid if possible. It is the only backup that will be accurate.

The cheapest switch is the one you did not make

Frequently the honest answer is a configuration change, not a migration. Three statuses instead of twelve, two views instead of six, one automation instead of nine. Those changes cost an afternoon and address the same complaint that "the tool is too complicated" describes. Before you price a migration, spend two hours deleting things in the current tool — the result is often the tool you were about to buy.

What this guide is, and is not

This is a framework using illustrative hour estimates and a stated hourly value, not a log of a specific migration we performed. Our hands-on testing cycle is in progress and will eventually include an instrumented migration with real hours recorded, which will replace the estimates above per our How We Test process. Where prices are referenced, they were verified on vendor pages on October 23, 2026.