How Do You Write a Migration Page for Buyers Leaving a Competitor?

Should you build a page for buyers switching from a competitor?

Yes, if people already switch to you and you are making them work it out over email. A migration page turns a private, anxious conversation into something a buyer can read at eleven at night. It is one of the few pages that catches demand you have already earned but are quietly losing.

Most software companies build a comparison page instead and think the job is done. It is not the same job. A comparison page argues that you are better. A migration page assumes the buyer already believes that and is now afraid of the move itself.

Those are different fears, and they need different pages. Here is how I think about writing the second one.

What is a migration page, and how does it differ from a comparison page?

A comparison page targets someone choosing between options. A migration page targets someone who has already chosen and is now calculating the cost of leaving. The first sells a decision. The second removes the obstacles to a decision that has already been made privately.

You can hear the difference in the questions. A comparison reader asks which tool is better for teams like mine. A migration reader asks what happens to my three years of data, my integrations, my team's habits and the two weeks I do not have spare.

That is why the same content does not serve both. If you already have alternative and comparison pages doing their job, the migration page is the next one to build, not a variation on the ones you have.

Why do switching buyers behave differently from new buyers?

Because they have something to lose. A new buyer is comparing a blank slate against your product. A switching buyer is comparing a working system, however much they complain about it, against the risk that yours turns out worse after they have already thrown the old one away.

This changes what persuades them. Feature advantages matter less than they should. What actually moves a switching buyer is evidence that the transition is survivable: that their data comes across, that nothing important breaks on day one, and that somebody has done this before them.

It also means urgency tactics backfire. A person weighing a migration is doing risk assessment, and pressure reads as a reason to be more careful, not less. The tone that works is calm and specific. You are not closing them, you are helping them plan.

What question does the page actually have to answer?

One question, in three parts: what does this cost me in time, in data, and in risk? Everything on the page either answers part of that or is decoration. If a section does not reduce a switcher's uncertainty about time, data or risk, it belongs on a different page.

Time means elapsed calendar time and hands-on hours, and those are not the same thing. A Shopify or Webflow rebuild can run for weeks while costing the buyer two afternoons, and the reverse is just as common. Buyers care about both, and they care about who does the work. Saying a migration takes a week is useless if the buyer cannot tell whether that week is theirs or yours.

Data means what comes across and in what shape. Risk means what happens if it goes wrong, and what the way back looks like. A page that quietly avoids the third part reads as evasive to exactly the person you are trying to reassure.

How honest should you be about what does not transfer?

Completely. List what does not come across, in plain language, on the page. Every buyer discovers it eventually, and the only variable is whether they discover it while reading your page or three days into a migration they cannot reverse.

This is the part most companies get wrong, and the reasoning behind the mistake is understandable. Naming a limitation feels like handing the objection to the reader. In practice it does the opposite, because a page that admits one hard thing becomes believable about the easy things.

I would go further. The sentence that says what does not transfer is often the most valuable sentence on the page, because it is the one a buyer quotes to their team when they argue internally for the switch. Give them something accurate to quote.

Where do most migration pages lose the reader?

In the gap between the promise and the mechanics. The top of the page says switching is easy, the bottom says contact sales, and there is nothing in between that describes what actually happens. The reader leaves knowing no more than when they arrived.

The second common loss is abstraction. A page that says it supports seamless data migration is describing a category, not a process. A page that describes what gets exported, in what format, what happens to records that do not map cleanly, and who checks the result, is describing something a buyer can plan around.

The third is pretending the buyer is starting from nowhere. Someone leaving Zendesk has macros and views. Someone leaving Mailchimp has segments and automations. Someone leaving Jira has workflows their team argued about for a year. Someone leaving WordPress has a decade of URLs. Name the thing they are actually carrying, and the page immediately sounds like it was written for them.

How do you make the page findable by people mid-switch?

Write it the way the search is phrased. People mid-switch do not search for your product's migration capabilities. They type things like Salesforce to HubSpot, or Mailchimp to Klaviyo, or they search whether their data can be exported at all, usually from inside the old tool while frustrated.

That means the page needs the names in it, used naturally. Somebody moving from Confluence to Notion should see both words on the page, and should get an answer in the first two sentences rather than after four paragraphs of positioning. Answer engines and search engines both reward the same thing here, which is a page that resolves the question rather than circling it.

It also means one page per source tool, not one page covering all of them, once you have enough traffic to justify the work. The same discipline applies that makes integrations pages rank: specific pages answer specific questions, and generic pages answer none of them.

What proof belongs on a migration page?

Proof that somebody like them survived the move. Not a logo wall, not a satisfaction score. A short account of a real migration, with the shape of the company, what came across, how long it took and what went wrong, is worth more than any number you could put on the page.

The detail that persuades is usually the unglamorous one. How many records. How many days. Which part needed manual cleanup. Switching buyers are trying to build a plan, and a plan needs textures, not superlatives.

If you do not have a migration story yet, say what you do have honestly rather than dressing up something thin. There are real ways to show proof before you have case studies, and all of them beat a vague claim that customers love the process.

What should you do next?

Find the last three customers who switched to you from somewhere else and ask them two questions: what were you most worried about, and what actually turned out to be the hard part. Those two answers, written plainly, are the skeleton of the page.

Then write the honest limitation before you write anything else. If you can state clearly what does not transfer, the rest of the page gets easier, because everything else is now allowed to be confident.

If you are trying to work out whether a migration page is the right next thing for your site, or you have one that is not converting, reach out and tell me what it says. Let's chat.