Should You Pay to Migrate a Competitor's Customers?

Should you pay to migrate a competitor's customers?

Pay for the work, not the price. Covering the migration effort is usually the offer that moves a switch, and cutting your price usually is not. The two get lumped together as "a switch offer" and they solve different problems, only one of which is actually blocking the deal.

We have a strong view on this and it is worth stating plainly: most switch campaigns fail because they treat inertia as a pricing objection. The prospect is not saying your product is too expensive. They are saying the six weeks of moving is not worth their quarter.

Here is how we would build the play, and the parts of it that are honest rather than clever.

Why is switching so hard to trigger?

Because retention is the strongest force in B2B software and the data says so. SaaS Capital's 2026 research, from a survey of more than 1,000 private B2B SaaS companies, finds that "growth rate is positively and exponentially correlated with net revenue retention".

The magnitudes are large. That research reports that companies with the highest net revenue retention show "median growth that is 173% higher than the population median", and that lifting retention from the 90 to 100 percent band into the 100 to 110 percent band "improves growth rate by 5 percentage points".

Read that from the attacker's side. Your competitor's growth depends on keeping their customers, which means they are working hard on exactly the thing you are trying to break. Switching is not a neglected front. It is the one they defend most.

What has actually changed about switching costs?

At the infrastructure layer, quite a lot, and it sets a useful precedent. The European Commission describes the Data Act as introducing "new rules setting the framework for customers to effectively switch between different providers of data-processing services to unlock the EU cloud market". It entered into force on 11 January 2024 and became applicable on 12 September 2025.

The large providers moved ahead of it. AWS published that it is "waiving data transfer out to the internet (DTO) charges when you want to move outside of AWS", and stated the waiver "follows the direction set by the European Data Act and is available to all AWS customers around the world and from any AWS Region". Notably, AWS added that "we don't require you to close your account or change your relationship with AWS in any way", and that eligible customers "will have 90 days to complete their move off of AWS".

That is worth studying as a piece of positioning regardless of your category. The most defensible thing a provider can do about switching cost is remove it and say so publicly, because it converts a lock-in accusation into a confidence claim.

What does a switch offer actually need to remove?

Four things, in descending order of how often they block a deal. The work of moving data and configuration. The risk of downtime or loss during the move. The overlap period where they pay both vendors. And the internal political cost of the person who chose the incumbent admitting it.

Notice that price is not on that list. It matters at the point of comparison and it is rarely what stops someone who has already decided you are better.

The fourth item is the one nobody designs for and it is often decisive. A switch is somebody's reputation inside their company. Anything you can do to frame the change as a natural upgrade rather than a correction of a past mistake makes the internal conversation survivable.

Why is discounting the wrong lever?

Because it buys a customer at a price you then have to defend forever. A switch discount is an anchor: the renewal conversation starts from the discounted number, and the customer knows the real price was lower than the list.

It also selects for the wrong buyer. A prospect who moves for 30 percent off is a prospect who will move again for 30 percent off, which means you have won a low retention account in a category where retention determines your growth rate.

Our position is that if a switch requires a permanent discount, you have a pricing problem rather than a switching problem, and the campaign is hiding it. The wider argument is in what discounting does to B2B SaaS.

What would we offer instead?

Do the migration, absorb the overlap, and guarantee the rollback. Three concrete commitments, none of which touch your list price.

Doing the migration means your team moves the data and rebuilds the configuration, with a named person and a date. It is the single most valuable thing you can offer because it converts the buyer's unbudgeted internal project into your cost of sale, which you can actually plan for.

Absorbing the overlap means covering the months where they are still paying the incumbent's contract, usually as free months rather than cash. And the rollback guarantee is the one that lets a cautious buyer say yes: if it is not working in 60 days, you help them go back, and you say that in writing. The AWS example suggests the same instinct: removing the exit penalty is what makes the entry safe.

How do you find the switchable accounts?

Renewal timing and dissatisfaction signals, in that order. A switch is only available in a window, and outside that window the best offer in the world loses to an active contract.

Win and loss analysis is where the signals come from. If you know the three reasons customers left the incumbent, those are your campaign's message, and they are specific in a way no generic comparison claim is. The Pragmatic Framework puts win and loss analysis in its Market category for exactly this reason: it is market intelligence, not sales reporting.

The inbound version of this is people searching for alternatives to your competitor, which is the highest intent traffic in B2B and the easiest to under-serve. We wrote about capturing it in ranking for best and alternatives queries.

What does the landing page need to say?

What the migration involves, who does it, how long it takes, and what happens if it goes wrong. In that order, above anything about your features.

Most switch pages we see are comparison tables with a call to action. The table is fine and it is answering a question the visitor already answered before they arrived. They came to find out whether moving is survivable.

So the page should read like a plan rather than a pitch: the steps, the timeline, the named owner, the rollback, and one or two honest notes about what does not transfer. That last part builds more trust than any claim on the page. Our approach to the comparison side sits in building competitor comparison pages.

When should you not run this play?

Three situations. When your product is not clearly better for the segment you are targeting, because a switch offer accelerates the discovery that it is not, and you will have paid for the migration first.

When your onboarding is weak. A migration offer floods your worst process with your most sceptical customers at the moment they are most likely to regret the decision. Fix onboarding before running the campaign, not after.

And when you cannot staff the migrations. An offer to do the work that turns into a queue is worse than no offer, because you have now demonstrated the thing the incumbent would say about you. If you can do three migrations a quarter, sell three, not thirty.

What does the play look like when it works?

Quiet and unglamorous. A named list of accounts with renewal dates, a page that reads like a project plan, a migration team that can absorb a known number of moves per quarter, and a rollback promise nobody has had to use.

The measure we would watch is not the number of switches. It is the retention of switched accounts twelve months later, because a switch campaign that wins accounts and loses them again has simply moved money from your margin to your competitor's churn report. Given how tightly retention and growth are linked in the published data, that is the only outcome worth counting.

If you are building this motion and want a second opinion on the offer and the page before you spend on it, we are happy to look. Reach us at phoenix.studio.