Every founder who switches a SaaS tool says the same thing afterwards: "that took way longer than I planned." Most planned a weekend. Most spent a fortnight. We measured 17 named migrations across the stack solo founders actually run. Here is what the data says about where the time goes.
Why this dataset exists
Three years ago I switched from Notion to Tana and back. The total round trip cost me 41 hours of founder time and a weekend of lost focus. The blog posts told me the switch would take "an afternoon." The truth was that the page hierarchy, the linked databases, and the Zapier flows all needed individual rebuilds, and the rollback when I changed my mind required reconstructing what Notion looked like before I started.
That gap, between the marketing version of a migration and the actual one, is the gap this Switch Index is trying to close. Fewertools tracks 17 named switches, scored against five dimensions, with the named failure modes that show up reliably. Solo and bootstrapped founders should walk into a tool switch with realistic expectations of where their time will go.
The headline numbers
- Average switch consumes 14 hours of founder time, not counting the parallel-run period.
- Median data loss is 7%, mostly in places founders did not check before exporting (custom fields, comment history, attachment metadata).
- 88% of automations rebuild from scratch. This is the largest variable in total switch cost.
- Parallel-run period averages 19 days. Most founders underestimate this by an order of magnitude.
- Rollback within 60 days happens in 23% of switches. Almost one in four founders ends up back on the original tool.
How we score Migration Risk
Every switch guide on fewertools now carries a Migration Risk Score from 1 to 5. The number is derived from five components, each weighted equally:
- Data export quality. Does the source tool let you export everything? CSV, JSON, ZIP archive? Does the destination tool import that format without losing structure?
- Automation rebuild cost. Do your existing automations, integrations, and workflows port over, or do they need to be reconstructed?
- Team retraining. How long until you and any teammates are productive in the new tool? Hours, days, or weeks?
- Rollback ease. If you change your mind in 30 days, can you go back without losing the work you did during the migration?
- Parallel-run cost. How long must you run both tools simultaneously before you can fully cut over?
A score of 1 means "lateral move, data ports cleanly, half a day at most." A score of 5 means "automation rebuilds, real data loss risk, multi-week project." Scores 2 to 4 fall on a continuous spectrum between.
The 17 switches, ranked
| Switch | Risk | Time | Headline failure mode |
|---|---|---|---|
| Firebase → Supabase | 5/5 | ~2 weeks | Auth, schema, and functions all rebuild |
| WordPress → Framer | 5/5 | ~3 weeks | Plugins do not transfer; SEO redirects critical |
| HubSpot → Attio | 4/5 | ~1 week | Workflows rebuild from scratch |
| Notion → ClickUp | 4/5 | ~1 week | Database relations break; page hierarchy reshuffles |
| Webflow → Framer | 4/5 | ~2 weeks | Custom interactions rebuild; SEO redirect work |
| Zapier → Make | 4/5 | ~1 week | Every Zap rebuilds; error handling redesign |
| Dropbox → Google Drive | 3/5 | ~3 days | File-sync conflicts on large folders |
| GA → Plausible | 3/5 | ~1 day | Historical GA data does not migrate |
| Heroku → Railway | 3/5 | ~3 days | Buildpacks need Dockerfile equivalents |
| Jira → Linear | 3/5 | ~2 days | Workflows and permissions rebuild |
| Mailchimp → Beehiiv | 3/5 | ~3 days | Domain reputation transfer ~2 weeks |
| Mailchimp → ConvertKit | 3/5 | ~3 days | Sequences rebuild; tags map roughly |
| Slack → Discord | 3/5 | ~2 days | Channel history exports limited |
| Asana → Linear | 3/5 | ~2 days | Workflow rebuilds; custom fields lost |
| Trello → Notion | 2/5 | ~6 hours | Butler automations rebuild |
| Substack → Beehiiv | 2/5 | ~4 hours | Paid subscriptions re-auth |
| ChatGPT → Claude | 1/5 | ~45 min | Bring your prompts; almost nothing else |
The five failure modes
Across the 17 migrations, five named failure modes showed up reliably. Most planning blog posts ignore them. Most migrations underestimate them.
1. The automation graveyard
This is the largest cost in 88% of switches. Even when both tools have an automation layer (Notion buttons, Linear cycles, Beehiiv flows, Make scenarios), the underlying primitives are different enough that automations cannot be exported and imported. Every flow rebuilds. The founder who built 14 Zapier zaps over two years and assumes Make will just inherit them is the founder who loses a weekend rebuilding them one at a time.
The mitigation, when possible, is to document every automation in a single Notion page before starting the switch. Trigger, condition, action, frequency. That document is what you rebuild from. Doing it cold from inside the new tool is twice as slow.
2. The orphaned attachment
Most data exports cover the structured fields. Almost none cover the long tail: comments, attachments, custom fields, third-party integrations the data depends on. Notion exports do not include block-level comments. Slack exports do not include reactions or thread context. Mailchimp exports do not include unsubscribe history.
Median data loss across the 17 migrations was 7%, almost all of it in this long tail. Solution: before exporting, do a five-tool spot check. Find five high-value items in the source tool (a busy project, a long thread, a customer with extensive history) and verify those specific items survive the round trip. If they do not, you now know what is missing.
3. The redirect tax
This is the website-migration killer. Any switch that involves changing URLs (Webflow → Framer, WordPress → Framer, Squarespace → anywhere) requires 301 redirects from old URLs to new URLs to preserve SEO traffic. A site with 100 pages needs 100 redirects, configured correctly, before launch. Miss any and that page's traffic drops to zero.
For founders who skip this step, the cost shows up as a 30-60% drop in organic traffic that takes 6-12 weeks to recover. The reason it takes so long is that Google has to re-crawl, re-index, and re-rank every affected page. WordPress → Framer is the worst-case version because plugin URLs (e.g., /?p=123) need explicit translation; the destination has no idea what they meant.
4. The grandfathered-price evaporation
This is the bundling-trap variant for migrations. The founder cancels their Notion Plus subscription to switch to ClickUp. Three months later, they realise ClickUp is not working out and want to go back. They re-subscribe to Notion at the current rate, which is higher than what they had been paying because their old grandfathered price evaporated the moment they cancelled.
This is now a routine cost component for switches that involve canceling rather than dual-running for the parallel period. The mitigation: run both tools in parallel for the 30 days you are evaluating, and only cancel the source after you are certain. The double-cost of parallel running for 30 days is almost always smaller than the cost of re-subscribing at a higher rate later.
5. The under-counted retraining
The founder migrating personal usage from Notion to Tana is fast: an evening of fiddling and they are productive. The founder migrating a 5-person team is slow: each teammate has their own cognitive model of how the old tool works, and the new tool defies most of those models. Two hours per teammate of guided onboarding is the floor. Most founders budget zero.
For switches that affect anyone other than the founder, multiply the founder-only estimate by 3x and round up to the next half-day. For switches that affect external collaborators (clients, contractors), multiply by 5x. The reason: external users get no training; they figure it out, complain in the meantime, and some quietly drift away from your project altogether.
What the data says about specific switches
Firebase to Supabase is the highest-risk switch we measured
Firebase to Supabase scored a clean 5/5. Three independent systems need to be re-engineered: auth (the user identity model differs), schema (Firestore documents do not map cleanly to Postgres relations), and serverless functions (Cloud Functions and Edge Functions have different deployment, environment, and observability stories). Most teams who attempt this in a weekend report two weeks. Several report bailing partway and going back.
The case for doing it anyway is real: Supabase pricing is more predictable at scale, the SQL primitive is more powerful than Firestore queries, and Postgres has 30 years of tooling around it. The case for not doing it is operational fatigue. Founders who switch then immediately notice all the small things Firebase did automatically that Supabase requires explicit configuration for. Six months in, most are glad they switched. The cost during weeks two through six is real.
ChatGPT to Claude is the lowest-risk switch we measured
This is the migration where the marketing version and the actual version converge. Forty-five minutes, bring your prompts, no data loss. The only friction is muscle memory: Claude's response style is different enough from ChatGPT's that prompts written for one perform slightly differently on the other.
The interesting consequence of how low-risk this is: there is no real lock-in between the two products. Vendor pricing power on the consumer subscription tier is fragile, which is exactly why vendors are turning to bundling instead of headline price increases.
The newsletter migrations have hidden domain-reputation cost
Mailchimp to Beehiiv and Mailchimp to ConvertKit both scored 3/5 mostly because of a non-obvious cost: sending domain reputation does not transfer. The new ESP starts cold from the receiving mail server's perspective. For a sender with an established Mailchimp reputation, the first 1,000 emails through the new ESP land in a higher percentage of spam folders. Recovery takes 14 to 21 days of consistent sending and engagement.
Mitigation: warm up the new domain by sending small batches (250-500 subscribers) for the first two weeks before sending to your full list. Most founders skip this step and notice the open rate drop after they already sent to everyone.
The cheapest switch to make is the one you plan twice and execute once. The most expensive is the one you execute twice and plan never. Almost everyone we surveyed who rolled back within 60 days said the same thing: they started the migration on a Friday evening with no rollback plan and no list of "things that must still work on Monday."
The Switching Cost Index, 2026 version
We compute a single Switching Cost Index per tool, blending the scores above with prevalence (how many founders use the tool) and replacement availability (how many viable alternatives exist). The 2026 reading:
- High switching cost, lock-you-in tools (Index > 70): Firebase, HubSpot, Webflow, WordPress, Zapier. These are the tools where the rational move is to plan your exit before you sign up.
- Medium switching cost (Index 40-70): Notion, ClickUp, Mailchimp, Heroku, Asana, Jira. Switchable, but expect a real project.
- Low switching cost (Index < 40): Substack, Trello, ChatGPT, Linear, Plausible, most modern dev infra. Buy without anxiety.
The strategic takeaway is not "avoid the high-switching-cost tools." For many use cases they remain the best technical choice today. The takeaway is document your exit plan the day you commit. The cost of writing down "if I leave HubSpot, I export contacts to CSV, rebuild workflows in Attio, redirect inbound from these specific endpoints" is one hour. The cost of figuring it out under pressure when HubSpot raises prices by 30% is two weeks.
What changed since 2025
- Switching costs went up overall. Modern tools embed more proprietary data structures (custom fields, embedded automations, AI-derived metadata) that do not export cleanly. The 2024 average switch cost 9 hours; the 2026 average is 14.
- AI-coding tool switching cost is dropping fast. Cursor to Claude Code to Aider to Goose: the prompts are portable, the IDE plugins are not yet but heading there. This is the one category where switching is getting easier.
- Domain reputation transfer became a named cost in newsletter migrations. Beehiiv has explicit warm-up tooling now; ConvertKit's onboarding includes a 7-day warm-up window. Mailchimp does not have an exit-warm-up flow because there is no reason for them to build one.
Methodology
Every migration in this index was executed against a small but real test project (5 to 50 records, 2 to 10 automations, 1 to 5 collaborators). I personally walked through each migration. The scores reflect real friction, not vendor marketing material. Where vendor marketing claims a switch is easier than our score implies, the discrepancy is itself noted in the corresponding switch guide.
What this dataset deliberately does not measure: enterprise migrations with hundreds of users, regulated-industry migrations with compliance overhead, custom-integration migrations with bespoke ETL. Those switches cost 10-100x more than the founder-scale switches measured here. If that's you, the right answer is a specialist consultancy, not this index.
Use this dataset
Three concrete moves you can make today with this index:
- Audit your current stack. For every tool you spend more than £50/month on, look up its Migration Risk Score. If it's 4 or 5, write down your exit plan today, while you are calm. Free stack audit here.
- Before signing up for a new tool, check its switching cost out. Vendor pricing power scales with switching cost. The signup decision is also the lock-in decision; treat it that way.
- When you actually need to migrate, get the playbook. Each switch guide on this site is a step-by-step plan with the named gotchas, rollback steps, and time estimates. The Migration Plan is the £59 packaged version when you want all 17 in one place plus the canonical worksheets.
Get the full Migration Plan
17 switch guides, 5 failure-mode playbooks, the canonical rollback worksheet, and a 30-day rollback decision tree. £59 one-time, instant download.
Get the Migration Plan · £59 →What this index is for
Switching cost is not glamorous. Nobody tweets about how their Firebase to Supabase migration went smoothly. The interesting stories are always the ones that broke. But the unmeasured cost of switching is, for many founders, the largest invisible line in their software budget. £500 in subscription fees gets noticed every month. The 40 hours of switching they did three times last year does not.
If this index changes anything for you, I'd like to know what. Email me at clinton@fewertools.com with the switch you're about to make. I'll send you the worksheet for free if it's on the list and I'll add it to next year's index if it isn't.