Blog
The forced migration to the new platform
A forced migration to a new platform is often a price increase in disguise, because retiring the old plan deletes the price point you would have compared against. Treat the migration as a negotiation, request legacy pricing, value the change honestly, and refuse to pay a premium for capability you already had.
Key takeaways
- A forced platform migration retires the plan you are on and moves you to a new one, which conveniently removes the old price as a comparison.
- It is one of the main ways vendors mask increases, alongside unbundling then rebundling and credit based pricing, in a year when about 60 percent of vendors mask increases per 2026 analyses.
- The counter is to treat the migration as a negotiable event, request legacy pricing explicitly, and separate genuine new value from a rebadge of what you already owned.
- Handled as a negotiation rather than an administrative step, a forced migration can still land inside the 10 to 30 percent savings range disciplined buyers reach at renewal.
What is a forced migration to a new platform?
A forced migration to a new platform is when a vendor retires the product, edition, or pricing plan you are currently on and tells you the only path forward is to move to a newer one. It is presented as a roadmap decision or an end of life notice rather than a price negotiation, which is exactly what makes it effective. By the time you are choosing between new tiers, the plan you would have renewed at last year's price no longer formally exists, so there is nothing clean to compare the new price against.
That comparison gap is the point. A migration is one of the standard ways a vendor masks a price increase, and treating it as an administrative step rather than a commercial event is how buyers overpay. The counter starts with recognizing it for what it is and negotiating accordingly, using the method in our SaaS Negotiation Guide.
Why do vendors force migrations?
Vendors force migrations for a mix of legitimate and commercial reasons, and the buyer's job is to tell them apart. The legitimate reason is genuine product evolution: an old architecture is being retired and the new platform really does deliver more. The commercial reason is that a migration resets the pricing relationship in the vendor's favor, bundles in capabilities and premiums the buyer did not ask for, and removes the legacy price that anchored the negotiation. Often both are true at once, which is why the change cannot simply be accepted or refused wholesale.
The discipline is to value the migration honestly. Ask what genuinely new capability the new platform adds, what of it you will actually use, and what you are being asked to pay for things you already had. This is the same masking pattern described in forced SKU migration into AI bundles, where the new bundle quietly deletes the old price point.
How does a forced migration hide a price increase?
A forced migration hides a price increase by destroying the reference price. When you renew the same plan, any increase is visible as a percentage on a known number. When you migrate to a new plan, the vendor can present a single new price that blends the old cost, an inflation uplift, an AI premium, and capabilities bundled in whether you wanted them or not, with no clean way to separate the parts. The increase is still there, but it is folded into a number that looks like a fresh decision rather than a rise on an existing one.
The counter is to rebuild the comparison the migration removed. Insist on a per unit price for the new platform, map each capability in the new bundle back to what you had before, and request the legacy price explicitly as a reference even if the plan is being retired. The related tactic of selling back what you already owned is unpacked in unbundling then rebundling, the tactic explained, and the bundle version in the bundle that hides the increase.
| The migration claim | What it can really mean | The buyer side check |
|---|---|---|
| Your plan is being retired | The old price point is being removed | Request legacy pricing as a reference |
| The new platform adds value | Some value is new, some is rebadged | List new capability you will actually use |
| Everyone is moving | Manufactured urgency to close fast | Hold to your renewal date and notice window |
| It is a simple migration | Bundled premiums travel with it | Unpack to a per unit, like for like price |
How do you counter a forced migration?
You counter a forced migration by treating it as a negotiation with the same leverage points as any renewal. Start early, because a migration framed as urgent loses its pressure when you have months of runway. Request legacy pricing explicitly, so the retired plan still anchors the conversation, a move covered in requesting legacy pricing explicitly. Demand evidence of value before accepting any premium, and ask for the version without the features you will not use. If an AI capability is bundled in, carve it out of the automatic uplift so you can evaluate it on its own later.
Where the new platform genuinely is better, the migration can be a fair trade, but only when you are paying for value you will use rather than for the loss of a comparison. Lock the new prices at unit level, cap any uplift at 3 to 5 percent indexed, and secure downgrade and exit rights so a retired plan does not become a captive one. These are the same protections that govern every renewal in our SaaS Negotiation Guide.
What does a fair migration look like?
A fair migration looks like a trade in which the buyer pays for genuinely new value they will use, at a price that can be compared honestly to what they had. Not every migration is a trap. When an old architecture really is being retired and the new platform delivers capability the team will adopt, moving is reasonable, and a vendor that prices the change transparently against the legacy cost is dealing fairly. The test is whether you can see what is new, what is rebadged, and what the increase actually buys.
The unfair version fails that test by design: a single blended price, no legacy reference, capabilities bundled in regardless of need, and a deadline that discourages scrutiny. The buyer's job is not to refuse all migrations but to insist on the conditions that make one fair, transparency on the components, a legacy price as a reference, and the freedom to take only the scope they need. A vendor confident in the value of the new platform will meet those conditions; one relying on the comparison gap will resist them.
How do you protect yourself in the new contract?
You protect yourself in the new contract by locking the terms that a migration tends to loosen. Because a migration resets the pricing relationship, it is the moment to secure SKU level price locks, an uplift capped at 3 to 5 percent indexed, and downgrade and seat reduction rights that let you adjust if the new platform proves heavier than you need. Without these, a migration can quietly hand the vendor a higher base and fewer of the protections you held under the old plan.
Pay particular attention to anything AI priced that travels with the migration. Carve AI features out of the automatic billing uplift so they remain an optional decision you can evaluate on evidence later, rather than a premium baked into the base for the life of the contract. Disarm any auto renewal that the new agreement introduces, and confirm the notice window, so the next renewal does not arrive on the vendor's terms. These are the same protections that govern every renewal in our SaaS Negotiation Guide.
A worked example
Indicative example. A vendor told a buyer their current edition was being retired and offered a single new platform price roughly 28 percent above the prior spend, framed as a like for like move. The buyer asked for the legacy price as a reference, unpacked the new platform into the capabilities they would actually use, and found that much of the increase paid for bundled features the team had no plans to adopt. By migrating only to the scope they needed, carving out the unused premium, and locking unit prices, the buyer brought the change down to a modest, justified uplift. The figures here are indicative and shown to illustrate the mechanics.
What is the move?
Treat a forced migration as a price negotiation, not a roadmap formality. Rebuild the comparison the vendor removed by requesting legacy pricing, unpacking the new platform to a per unit price, and mapping each capability back to what you already owned. Pay only for genuinely new value you will use, carve out bundled premiums, and lock the new prices at unit level with a capped uplift. Handled this way, even a forced change can land inside the 10 to 30 percent savings disciplined buyers reach, using the full method in our SaaS Negotiation Guide.
Make the migration a negotiation, not a default.
Use the SaaS Negotiation Guide to run the counter, and read forced SKU migration into AI bundles and unbundling then rebundling, the tactic explained.
Download guide →Frequently asked questions
Why do vendors force migrations to a new platform?
For a mix of reasons. Sometimes the old architecture is genuinely being retired and the new platform adds real value. Commercially, a migration also resets the pricing relationship, bundles in premiums the buyer did not ask for, and removes the legacy price that would have anchored the negotiation, so both motives often apply at once.
How does a forced migration hide a price increase?
It deletes the reference price. Renewing the same plan shows any increase as a clear percentage on a known number, but migrating to a new plan lets the vendor present one blended price that mixes the old cost, an uplift, a premium, and bundled extras with no clean way to separate them. The counter is to rebuild a per unit, like for like comparison.
Can you refuse a forced migration?
You can usually negotiate it even when you cannot refuse it outright. Request legacy pricing as a reference, migrate only to the scope you will actually use, carve out bundled premiums, demand evidence of value before paying any of it, and lock unit prices with a capped uplift and exit rights so a retired plan does not become a captive one.
Published market figures reflect 2026 SaaS pricing analyses and are labelled indicative where appropriate.