A retirement is not a price rise
A price rise arrives as a number you can compare against last year's number. You can approve it, argue about it, or leave. It is a decision with a date on it.
A plan retirement does none of that. The plan you are on keeps working and keeps costing what it cost, and the change is held in reserve: it applies the next time you do something, or the next time your billing cycle rolls, or at a date the vendor has not committed to. Nothing appears on an invoice until it does.
That makes them hard to budget for and easy to miss, which is why they are worth collecting. What follows is quoted from each vendor's own documentation, because a plan retirement is exactly the kind of change that gets described second-hand and inaccurately.
Clay: the trigger is you
Clay's own documentation is unusually clear about the mechanism, and the mechanism is the interesting part.
After April 10, 2026 11:59pm PDT, any plan change forces migration to modern plans.
Read that carefully. There is no date on which Clay moves you. There is a date after which your own action moves you, and it is one-way: a plan change is the trip switch, and you cannot go back to legacy pricing afterwards.
The practical consequence is that ordinary account administration becomes consequential. Adding seats because the team grew, moving down a tier for a quiet quarter, or any other adjustment that would normally be routine now also converts your pricing permanently.
The meters changed, not just the price
Clay's modern plans introduce, in its words, "two simple usage meters": Actions, which measures "platform usage of enrichments and GTM execution", and Data credits, "for accessing data from our marketplace".
Legacy plans charged credits only. Modern plans charge both. So the comparison most people will make, old monthly price against new monthly price, is not measuring the same thing, and whether the change costs you more depends entirely on the ratio of execution to data purchase in how you actually use it.
The end date is deliberately absent
Legacy plans will be supported for the foreseeable future with bug fixes, security updates, and quality of life improvements. We may sunset legacy plans in the long term as they become a smaller part of our customer base.
This is a fair thing to write and an impossible thing to plan around. It is also self-fulfilling: the condition for sunsetting is that few customers remain on legacy plans, and every forced migration makes that condition truer.
Z.AI: auto-renew switched off
Z.AI's GLM Coding Plan transition takes the opposite approach, and is the clearer of the two to plan for because it names a date and an action.
Starting on April 30, 2026 (Singapore Time), auto-renew for eligible legacy plans will be automatically canceled.
With the important qualifier:
Your existing plan will remain active until the end of its current billing cycle.
So nothing stops on 30 April. What stops is the plan renewing itself, which means the effective date is different for every subscriber and falls whenever their cycle happens to end. If you are on an annual cycle you may not encounter this for another eleven months, and you will encounter it as a subscription that simply did not renew.
The change is the limit, not the price
The documentation notes that legacy plans operate "without weekly usage limits", while current plans include them. It does not state what the weekly limits are.
That is the substantive difference. For a coding plan, an unmetered plan and a weekly-capped plan are different products regardless of what each costs, and anyone whose workload is uneven across a week will feel a cap that an average would not predict.
What subscribers get
Z.AI provides compensation, which is more than most retirements offer. Existing subscribers receive two complimentary months of the equivalent tier, beginning after the current subscription ends, and eligible users get 50% off the latest discounted price during a window that runs from 30 April 2026 until three months after their legacy plan ends.
Atlassian: a date on which the software stops writing
The two examples above are SaaS, where the vendor controls the servers and a retirement is a billing decision. Atlassian's is the harder case, because Data Center is software customers run on their own infrastructure, and the retirement still applies.
The timeline is unusually precise, which is to Atlassian's credit and makes it the clearest example of the category:
- 30 March 2026: "Sales of new Data Center subscriptions and Marketplace apps will end for new customers."
- 30 March 2028: "Last date for existing customers to purchase new Data Center licenses, Marketplace apps, and license expansions."
- 28 March 2029: "Data Center end of life. All Data Center licenses and associated Marketplace app licenses will expire and become read-only."
Read-only is not the same as unsupported
The word doing the work in that last line is read-only, and it is worth separating from the thing people usually assume an end-of-life date means.
An end of support is a commercial event. The software carries on exactly as it did, you stop receiving patches, and the risk you take on is security and compatibility rather than availability. Plenty of organisations run unsupported software deliberately, with that risk priced in.
A licence expiring to read-only is an operational event. On that date, a system running on hardware you own, in a datacentre you pay for, stops accepting writes. There is no version of "we will deal with it later" that survives that, because the failure mode is not a vulnerability, it is a Jira that will not accept a ticket.
The second migration problem
The other thing that makes this case instructive is that many of the customers affected have already migrated once. Atlassian ended Server support in February 2024, and the recommended path at the time was Data Center. Organisations that did the responsible thing and moved are now being asked to move again, on a clock, to a product with a different operating model.
That is worth naming because it changes how you should read any vendor's recommended migration target. The target is where the vendor's strategy currently points, and vendor strategy has a shorter half-life than most enterprise migrations.
What Atlassian is offering
Atlassian's migration programme, Ascend, is tiered by size: self-service tooling under 1,000 users, a complimentary "FastShift Program" for 1,000 to 5,000 users which it says reduces migration from 12 to 16 months down to 2 to 6, and a Solution Design Acceleration programme above 5,000. There is also "extended maintenance by exception" for organisations with circumstances that do not fit the timeline.
Those numbers are useful even if you are not an Atlassian customer, because they are a vendor's own estimate of how long this class of migration takes. Twelve to sixteen months unaided, for a product a team uses every day, is the realistic scale of a forced migration at enterprise size. Any plan that assumes weeks is not a plan.
VMware: the case that made everyone read their contracts
No survey of this is complete without VMware, because it is the example that moved the topic from procurement trivia to board-level risk, and because it is the most extreme version of the pattern.
After Broadcom's acquisition closed, perpetual VMware licences were withdrawn and replaced with annual subscriptions. That is the whole change in one sentence, and every consequence follows from it.
Why perpetual mattered
A perpetual licence is a purchase. You buy the right to run the software indefinitely, and you buy support separately and optionally. If a renewal quote is unacceptable you can decline it and keep running, which is a bad long-term position and an excellent negotiating one.
A subscription is a rental. Declining a renewal means the software stops. The negotiating position that came free with a perpetual licence disappears, and it does so at exactly the moment renewal terms change.
The reported numbers
The figures here come from reporting and from customers rather than from a published price list, and they should be read that way. Reporting has put renewals at two to five times prior cost as a general range, with perpetual-to-subscription conversions considerably higher in individual cases. The restructuring also introduced a minimum core count per subscription and collapsed a catalogue of thousands of SKUs into a small number of bundles.
The bundling is the part that generalises. When a catalogue collapses, customers who bought one component start paying for a suite, and the increase is not a price rise on the thing they used. It is the price of things they did not ask for, which is a different argument to have with a finance team and a much harder one to forecast.
Four mechanisms, four different things to do
These four cases look like one story and are not. The mechanism determines what you can do about it, and the mechanisms are genuinely different.
1. The trigger is your own action
Clay's model. Nothing happens until you change something, and then it happens permanently. The correct response is administrative rather than technical: make sure the people who can change the plan know that changing it is a pricing decision, because it is usually not the contract owner.
The trap is that this feels like the mildest version and is the easiest to walk into. Nobody schedules a migration. Somebody adds a seat.
2. The trigger is your renewal date
Z.AI's model. The announced date is not your date, and every subscriber has a different one. Working from the vendor's announcement will mislead you. The response is a calendar entry set from your own billing cycle, roughly a month before it, which is the only date that actually applies to you.
3. The trigger is a fixed date for everyone
Atlassian's model, and the easiest to plan against precisely because it is the least flexible. Everyone hits it simultaneously, which has a second-order consequence worth pricing in: so does every migration partner, every consultancy and every competitor's sales team. Capacity gets scarce as the date approaches, and the cheapest time to move is the least urgent one.
4. The product you bought no longer exists in that form
VMware's model. This is not a plan retirement so much as a change in what you are buying, and the options narrow to negotiating the new terms or replatforming. Both are expensive; the mistake is discovering that at renewal rather than a year before it.
The common thread
In all four, the vendor published the change and the customer found out late. None of these were secret. They were in documentation, a blog post or a support article, which is to say they were in places nobody reads on a schedule. That is the actual failure mode, and it is addressable.
How to check your own stack
The awkward thing about plan retirements is that the vendor has usually told you, in a product update or a support article you had no reason to read. These are the checks that actually surface them.
Look for the word "legacy" in your billing page
Most vendors that have moved to a new pricing model will label your plan. If your plan name does not appear on the vendor's public pricing page, you are on a legacy plan whether or not anything says so.
Find out what the meter is
The single most useful question is what unit you are billed in, and whether the vendor still sells that unit. A move from seats to credits, actions, resolutions or outcomes means old and new prices are not comparable, and it is where the increase usually hides. We covered how that works for support tooling in our piece on per-resolution pricing.
Treat any plan change as a decision
Where a vendor uses Clay's mechanism, adding a seat is a pricing decision. That is worth writing down somewhere your finance team will see it, because the person who adds a seat is rarely the person who owns the contract.
Check what happens on renewal, not today
Z.AI's approach means nothing changes until your cycle ends. A calendar entry a month before renewal is worth more than a note about the vendor's announced date, because the announced date is not your date.
A one-afternoon audit of your own stack
The checks below are ordered by how much they tell you per minute spent. Most organisations can get through the first three for their whole stack in an afternoon, and that is enough to find anything urgent.
Step one: list what you are on, not what you buy
Export your subscriptions from whoever holds the cards, usually finance rather than IT. For each line, write down the plan name exactly as the invoice states it.
Then open each vendor's public pricing page and look for that name. If the plan is not listed, it is a legacy plan. That single comparison finds most of them, takes a couple of minutes per vendor, and requires no access to anything you do not already have.
Step two: identify the meter
For each product, answer one question: what unit am I billed in? Seats, cores, credits, actions, resolutions, gigabytes, endpoints, records.
Then check whether the vendor still sells that unit to new customers. A vendor with two live meters is a vendor mid-transition, and the old one is on borrowed time. This is the check that predicts a retirement before it is announced, because a company cannot maintain two billing models indefinitely and knows it.
Step three: find your own dates
For anything on a legacy plan, the relevant date is rarely the one in the announcement. Write down your renewal date, your contract end date and any notice period for cancellation. The notice period matters more than people expect: a 90 day notice requirement means the decision point is three months before the date you had in your calendar.
Step four: check the exit before you need it
For anything where migration would be expensive, establish now what getting your data out actually involves. Is there a documented export, does it include history and attachments, and has anyone tried it? An export that exists in documentation and has never been run is not an exit, it is a claim about one.
This is the step that is worthless in a crisis and valuable a year early, which is why it never gets done. It is also the only one that changes your negotiating position.
Step five: write down who gets told
Every case here was announced publicly and missed privately. Decide who reads vendor changelogs for your top ten products and where that goes when they find something. For most teams it is nobody, which is the whole problem, and one named person and a shared document is a complete fix.
What is actually negotiable
The instinct on receiving a migration notice is to argue about the price. That is usually the least negotiable part, because it is set centrally and the person you are talking to cannot change it. Several other things are more flexible and matter more.
Timing
Vendors running a migration programme are managing a queue, and a customer willing to move early is worth more to them than one who moves at the deadline. Early movers are also the ones offered transition pricing. Z.AI's two complimentary months and discount window are a small version of this; enterprise equivalents are considerably larger and are rarely advertised.
The transition period, not the end price
A three-year ramp to the new price is a materially different deal from paying it on renewal, and it is frequently available when a discount on the final number is not. Ask what the price is in year one, year two and year three, rather than what the price is.
Which bundle you land in
Where a catalogue has collapsed into a few bundles, which bundle you are placed in is a judgement call somebody makes, and judgement calls are negotiable in a way list prices are not. This is worth more attention than the per-unit rate.
The floor
Minimums, whether core counts, seat counts or committed spend, are where the increase often hides for smaller customers. A rate that looks reasonable against a minimum you cannot fill is not a reasonable rate. Establish the floor before comparing anything else.
What to bring
A credible alternative, priced. Not a threat to leave, which everyone hears and nobody believes, but an actual number for what the alternative costs including migration. That number changes the conversation whether or not you intend to act on it, and producing it is most of the work of deciding anyway.
Why this is happening now
Grandfathering is expensive to run. Every retired price is a code path, a billing rule and a support case, and a vendor carrying years of them is maintaining a museum of its own past pricing.
What has changed in 2026 is that the migration is worth more than it used to be. When the new model meters something different, moving a customer from an old plan to a new one is not a small percentage increase, it is a re-pricing against a different unit. That makes the clean-up worth doing now rather than deferring it again.
None of which makes it improper. A vendor is entitled to stop selling a product, and both examples here documented the change publicly rather than quietly. The problem for a buyer is not that it happens, it is that it does not show up anywhere until it does, and the sequence of events is different for every vendor.
If you are auditing costs generally, the related reading is our list of promotional pricing expiring in 2026, which is the same class of surprise arriving through a different door, and what the SaaSpocalypse means for buyers, which is the market pressure behind both.
Questions people ask
- What is a legacy plan?
- A pricing plan the vendor no longer sells but still bills existing customers on. It is normally created when the vendor changes pricing and chooses not to move existing customers immediately. The plan is usually absent from the public pricing page, which is the easiest way to tell you are on one.
- Can a vendor force me off a plan I am paying for?
- Within the terms you agreed, generally yes, and the two mechanisms in 2026 differ. Clay states that after 10 April 2026 any plan change forces migration to modern plans, so the trigger is your own action. Z.AI cancelled auto-renew on eligible legacy plans from 30 April 2026, so the trigger is your renewal date. Your own contract governs, and enterprise agreements often say something different from the public documentation.
- How do I know if my plan is being retired?
- Compare your plan name against the vendor’s current public pricing page. If it is not there, it is legacy. Then check what unit you are billed in and whether the vendor still sells that unit: a change from seats to credits, actions or outcomes is the clearest sign a migration is coming, because the vendor cannot maintain two meters indefinitely.
- Is a plan retirement the same as a price increase?
- No, and the difference matters when budgeting. A price increase is a number you can compare with last year and approve or refuse. A retirement changes what you are buying, often including the unit you are charged in, so there is frequently no like-for-like comparison to make. It also has no single date: it applies at your renewal, or the next time you change something.
- What does it mean when a licence becomes read-only?
- That the software stops accepting writes on a stated date, which is different from losing support. Unsupported software keeps working and you carry the security risk. A licence that expires to read-only means a system you host yourself stops functioning for its purpose. Atlassian states that on 28 March 2029 all Data Center licences and associated Marketplace app licences "will expire and become read-only", which is an operational deadline rather than a commercial one.
- Why did perpetual licences disappearing matter so much?
- Because a perpetual licence is a purchase and a subscription is a rental. With a perpetual licence you can decline an unacceptable renewal quote and keep running the software, which is a poor long-term position and a strong negotiating one. Once the product is subscription only, declining a renewal means the software stops, so the leverage disappears at exactly the point renewal terms change. That is the substance of the VMware change, independent of the numbers.
- How far ahead should I plan for a forced migration?
- Longer than feels necessary. Atlassian tiers its migration help by size and describes its assisted programme as reducing a migration from 12 to 16 months to 2 to 6, which is a vendor stating that this class of move takes over a year unaided at enterprise scale. There is also a capacity problem near any fixed deadline, because every affected customer, partner and consultancy hits it at once.
- Should I move to the new plan early?
- Only after working out what you would pay under the new meter using your own usage, not the headline price. Where the meters differ, as with Clay’s split into Actions and Data credits, the answer depends on your mix of usage rather than on the tier names. Where compensation is offered for moving, as with Z.AI’s two complimentary months and discount window, that is worth putting into the comparison too.
Sources
Every price, limit and date above was checked against these pages on the day shown. Where a figure has since moved, the vendor’s own page is the authority and this one is a snapshot.
- 1Legacy plans · ClayStates that after 10 April 2026 any plan change forces migration, defines the Actions and Data credits meters, and declines to give a sunset date.Checked
- 2Legacy Plan Migration Notice · Z.AIStates auto-renew cancellation from 30 April 2026, that existing plans run to the end of the billing cycle, the absence of weekly usage limits on legacy plans, and the compensation offered.Checked
- 3Ascend to the cloud: The next chapter for Atlassian and our customers · AtlassianStates the 30 March 2026, 30 March 2028 and 28 March 2029 dates, that licences expire and become read-only, and describes the Ascend migration tiers.Checked