To help customers switch from a competitor to your SaaS, make the move itself cheap: find out what people are leaving, catch them when they are already looking, give them an import that previews before it commits, publish an honest "switching from X" guide, and do the first migrations yourself. For most indie SaaS products the real competitor is not the other tool. It is the cost of moving: data, history, team habits, integrations and the fear of a bad week. Below: the switching costs from the buyer's side, a switch-source sheet, the import to build first, the migration guide, a 20-minute migration call, the overlap period, what to measure and a 14-day plan.
Why do people like your product and still not switch?
When someone says "this looks great, we'll switch later", they usually mean it. Later never comes, because from their side switching is a list of chores and risks your product page never mentions:
Getting the data out. They are not sure the old tool exports everything, or in what format.
Getting the data in. Columns that do not match, a file that half imports.
Losing history. Old notes, closed jobs, comments. Nobody looks at them until the week they need them.
Setting everything up again. Users, permissions, templates, saved views.
Retraining people. Everyone knows where the buttons are in the old tool.
Integrations. The old tool talks to their calendar or accounting, and the new one must too.
Contract timing. They just paid for a year, or the renewal is three months away.
The risk of a bad week. If the move goes wrong, it is their name on it.
You will not remove all of it, but every item you shrink brings "later" a bit closer.
Switching fear | What you can do about it |
|---|---|
"I don't know if my data will come over" | A plain list of what moves and what does not, plus a preview before anything is saved |
"The import will make a mess" | Column mapping, a dry run, a row-by-row error report, and a one-click undo |
"We'll lose our history" | Keep original dates and IDs where you can; if you cannot, say so and suggest keeping an archive export |
"Setting it all up again takes days" | Offer to do the first import yourself, or bring over settings that map cleanly |
"My team won't learn a new tool" | A short first-week checklist and one call to walk the main job together |
"We just renewed" | Stay in touch and ask when the renewal date is; do not push |
"What if it breaks the week we switch?" | Let them run both tools side by side for a while before turning the old one off |
A running example (made up)
To keep this concrete, here is an invented product. Everything about it is made up. Jobwren is a scheduling and job-tracking tool for small cleaning companies with three to fifteen staff. Its founder, Ines, runs it alone. Most of her trial signups already use something: a big field-service suite built for much larger teams, a shared spreadsheet, or a paper diary plus a group chat. Trials look healthy and people reply kindly, then many go quiet before importing anything. Ines has a moving problem more than a product problem.
How do you find out what customers are switching from?
You do not lower switching costs in general. You lower them from one specific place to yours, so first find out where people come from:
Ask at signup. One optional question: "What were you using before?" Offer the usual answers plus "a spreadsheet", "paper or nothing" and a free-text box.
Ask on every call. What do they use today, what do they like about it, and what would have to be true for them to move?
Tag support tickets. "Can I bring my clients over?" and "does it import from X?" are switching signals. Tag them with the source tool.
Put the answers in one sheet. Ines's version, with made-up values, looks like this:
Switching from (made up) | Signups in 30 days | Started an import | Finished an import | What they say stops them | Next fix |
|---|---|---|---|---|---|
Shared spreadsheet | 22 | 9 | 4 | "My columns are a mess", date formats | Column mapping with preview |
Big field-service suite | 11 | 3 | 1 | Job history, recurring jobs, staff logins | Read its documented export file |
Paper diary + group chat | 8 | 0 | 0 | "No time to type it all in" | Offer to enter the first week of jobs for them |
Another small scheduling app | 3 | 1 | 1 | Nothing yet, too few to tell | Watch, do not build anything |
The sheet tells you which importer to build first (the source with the most stuck switchers, not the most interesting one) and which switchers do not need software at all. Nobody leaving a paper diary needs an API integration. They need help with the first afternoon.
When are customers most likely to switch?
Most people do not shop for a new tool on a normal Tuesday. They look when something changes:
A price change or plan removal at the tool they use now. A real example: in August 2022 Heroku announced that starting November 28, 2022 it planned to stop offering free product plans, in a post called Heroku's Next Chapter. Anyone on a free plan had to choose between paying and moving.
A tool being shut down or acquired. Users suddenly have a deadline.
A renewal date coming up. The easiest moment to switch is just before the next bill, not just after it.
A team outgrowing a free tier or a spreadsheet. The fifth staff member, or the second location.
A bad outage or a bad week. People remember the day the old tool let them down.
Notice these moments honestly. Ask customers when their renewal is and note it in your sheet. Read the competitor's public changelog and pricing page once a month, as any buyer could. Watch community threads where people in your niche ask "what are you using now that X changed?" and answer the actual question, including when your product is not the right fit.
And be clear about what you will not do: no dunking on the competitor, even when their users are angry; no fake reviews or fake "I switched and loved it" comments; no scraping their customer lists or messaging their users from a list you were never given. A switcher is about to trust you with their data. Do not start with a trick.
What should your import path support first?
The import is where most switches quietly die. Make the boring version trustworthy before you make it clever.
Start with CSV, done properly
Almost every tool and spreadsheet can produce a CSV file, so a good CSV import covers the most people for the least work. Good means:
A column-mapping step. Show their columns next to your fields with your best guess filled in. Let them skip a column or keep it as a note instead of silently dropping it.
A preview before commit. Show the first rows as they will look in your product, with counts: how many rows will be created, how many skipped, how many have problems.
Forgiving parsing. CSV is less standard than it looks. RFC 4180, the common reference for the CSV format, is informational rather than a formal standard, and it notes considerable differences between implementations. It describes fields that contain commas, line breaks or double quotes being wrapped in double quotes, and the header line as optional. Test with files exported from real spreadsheets, not only the neat one you made.
Dates, IDs and history. Keep original created dates where your data model allows it, and store the old tool's ID next to each record so a second import can update instead of duplicate.
Then a dry run, an error report and an undo
Run the whole file as a dry run first, with a row-level report saying which row failed, which field, and what to change. If you want help with the wording, the MakerHunt post on writing error messages that keep users moving covers it. After a real import, keep a "delete this import" button for a few days. Knowing they can undo it often gets people to click import at all.
The competitor's export format, and APIs later
If the tool most of your switchers leave has a public, documented export format, reading that file directly saves everyone the column-mapping step. That is usually the second thing worth building. An API import from their old account is a bigger job with more ways to break, so build it only when your sheet clearly says so. Before you build against anyone's API, read their terms of service and API terms; some limit how the API may be used. That is a general caution, not legal advice.
Before you call it done, import the competitor's actual export yourself and run the same file twice. If the second run creates duplicates, fix that first.
What goes on a "switching from X" migration guide?
Write one page for your biggest source, with a plain title like "Switching from a spreadsheet to Jobwren". It answers the questions someone asks the evening before they decide:
What moves over, and what does not. Be honest. "Clients, addresses, recurring jobs and notes come over. Photo attachments and staff pay rates do not, so keep your old export for those." A buyer who finds the gap after importing will not trust the rest of the page.
The steps, with a time estimate. Export, upload, check the preview, invite your team. Give a realistic time for a typical account.
Screenshots, if they help. Optional. Showing where the export option lives in the old tool saves support email.
A short FAQ. "Can I run both for a while?", "What happens to my history?", "Can you do the import for me?"
One way to get help. An email address or a booking link for the migration call below.
This is not the same page as a comparison page. A comparison page helps someone decide whether to switch, and it targets "X vs Y" and "X alternatives" searches. If you want one, the Aura++ guide on writing a SaaS comparison page that ranks covers it. A migration guide helps someone who has mostly decided, and its job is to make the move feel small. Keep the selling to one line at the end. Link it from your import screen, your help docs and every reply to a "does it import from X?" question.
Should you migrate customers' data for them?
For your first switchers, yes, if you can. Doing the import yourself is the fastest way to learn what breaks, and it removes the biggest fear in one step. With a handful of new customers a week, it costs a few hours.
What to ask for before the call:
The export file from the old tool, or the spreadsheet, sent in whatever way they are comfortable with
A list of the three to five things they must keep (for Ines's customers: client addresses, recurring jobs and access notes like door codes)
Who on their team will use the product in week one
A 20-minute migration call that stays a setup call, not a sales demo:
Minutes 0 to 3: confirm what they are moving from and the must-keep list.
Minutes 3 to 8: open their file together and point out anything that will not move, before you import.
Minutes 8 to 13: run the import as a preview, then for real, while they watch.
Minutes 13 to 18: check three real records together. Fix anything odd or write it down.
Minutes 18 to 20: agree the first-week plan, including when the old tool gets switched off, and tell them how to reach you.
Write down every problem you hit. After ten calls you have your importer's fix list, in the order customers need it. Stop offering calls to everyone once self-serve import works for most files, and keep them for bigger accounts or messy sources.
How do you handle the overlap period?
Almost nobody switches off the old tool on day one, and you should not ask them to. Plan for a week or two of running both:
Let them run both. Say it out loud on the migration guide: "Keep your old tool for a couple of weeks while you get used to this one."
Start the trial when the import finishes, if that fits your model. A trial clock that runs while someone is still cleaning a spreadsheet works against you.
Switch discounts. If you offer a switch discount, keep it simple.
Agree a switch-off date on the migration call, so the overlap does not drift into two half-used tools.
Give switchers a short first-week checklist, written for someone moving, not for a brand new user:
Check five records you know well and confirm they came over correctly
Invite the people who will use it daily
Do the main job once in the new tool (for Jobwren, schedule tomorrow's jobs)
Reconnect the one integration you cannot live without
Set a date to stop entering anything new in the old tool
Keep the old export file somewhere safe
How do you measure whether switching is getting easier?
You do not need a dashboard. A tab in the switch-source sheet with a few numbers per week is enough:
Signups that name a previous tool, split by source.
Import started, import finished, active in week two. The drop between each step tells you where the move breaks.
Time from import finished to first real use, such as the first job scheduled with imported data.
Import errors per hundred rows, by source.
Migration calls done and switched off the old tool, if you run calls.
With small numbers, read the rows, not just totals. Three stuck imports from the same tool tell you more than a percentage. If basic product tracking is not set up yet, see the IndieHunt guide to tracking product metrics before 100 users.
What traps make switching harder?
Promising a perfect migration. Something always gets left behind. Say what, up front.
Building importers for five tools nobody uses. Build for the top of your sheet first.
Insulting the competitor. Your switchers chose that tool once. Calling it bad calls them bad too.
Hiding what does not move. It will come out in week one, at the worst moment.
A migration guide that is secretly an ad. Feature bragging buries the steps people came for.
A 14-day plan to make switching easier
Day | Do this | Done when |
|---|---|---|
1 | Add the optional "What were you using before?" question to signup | Live, with a free-text option |
2 | Start the switch-source sheet from past calls, tickets and signups | Top three sources listed |
3 | Export your own test data from the top source and try importing it | You know every place it breaks |
4 to 5 | Add or fix column mapping and the preview step | A messy real file previews correctly |
6 | Add the row-level error report and an undo for recent imports | A broken row tells you exactly what to fix |
7 | Write the "switching from X" guide for the top source | Published, honest about what does not move |
8 | Link the guide from the import screen, help docs and saved replies | Three entry points |
9 | Offer a free migration call to every recent stuck trial | Offer sent, one line each |
10 to 12 | Run the calls and log every problem | Problem list ranked |
13 | Write the switcher first-week checklist and add it after import | Shows after a finished import |
14 | Review the funnel: started, finished, active in week two | Next fix picked |
The day numbers are a planning guess for a solo founder, not a measurement. Move them around to fit your week.
FAQ
How do I get customers to switch from a competitor?
Make moving cheap and safe rather than arguing that your product is better. Learn which tool people leave, build an import that previews and can be undone, publish an honest migration guide, do early migrations yourself, and show up when they are already looking, like near a renewal.
Should I build an importer before launch?
A solid CSV import with a preview is usually enough at launch. Build a format-specific or API importer once one source clearly leads your signups.
Is it legal to import data from a competitor's export?
Customers moving their own data is normal, and many tools offer an export for exactly that. In the EU, the European Commission's page on data protection rights for individuals explains the GDPR right to data portability: where a company processes your personal data by automated means on the basis of consent or a contract, you can ask for it, and ask for it to go directly to another company when that is technically feasible. That right covers personal data, not every business record. The risky parts are using a competitor's API or site against their terms, or data the customer had no right to share. This is general information, not legal advice.
Should I offer to migrate data for free?
For your first switchers it is usually worth it: it removes the biggest fear and shows you what your importer is missing. Keep it to a short call with a must-keep list, and narrow it to bigger or messier accounts once self-serve import handles most files.
Where should you start this week?
Add the "What were you using before?" question today and look at your last ten quiet trials. If most of them came from the same place, that is your first importer and your first migration guide. And when you are ready to put the product in front of people who are already looking, a listing on IndieHunt brings new visitors, and a short move is what turns them into customers who stay.
