Xanadu - ServiceNow’s most intelligent release, ever
Yet again, ServiceNow has delivered by far its largest release of new capabilities for generative AI powered by a platform with an entire new...
Tereza Schneider • 8 min read • Jun 26, 2026
If you own a ServiceNow platform, you are used to thinking in modules, plugins, entitlements, roles, and ITIL processes. You probably do not spend your days inside order forms, true-up clauses, and uplift percentages. That division of labour worked fine for years. The April 2026 repackaging is the moment it stops working, because the change that looks like a feature reshuffle on the surface is a commercial restructuring underneath, and the two are now inseparable.
This article explains what changed, the timeline that decides when it reaches you, and the single most expensive misconception in the market right now: that moving to the new model is a simple, like-for-like swap.
On 9 April 2026, ServiceNow retired its five legacy tiers (Standard, Pro, Pro Plus, Enterprise, and Enterprise Plus) and replaced them with three AI-native tiers: Foundation, Advanced, and Prime. The headline you will hear from your account team is "simplicity": fewer tiers, no separate AI procurement, AI included everywhere.
But the substance sits in three structural shifts that matter far more than the tier count:
AI is now included in every tier. The Now Assist capability that used to sit behind the Pro Plus tier is now part of all three packages. What separates the tiers is how far the AI is allowed to go. Foundation ships with out-of-the-box generative skills, the kind that summarise a record or draft a response for a person to review and send. Advanced and Prime extend that into agentic AI, which can take action and work through multi-step tasks on its own. Moveworks and the new Context Engine fold into the platform alongside Now Assist, and Virtual Agent moves to unlimited conversations. Each tier then carries an Assist allocation, the unit ServiceNow uses to measure how much AI you consume.
Pricing moves toward consumption. The seat is no longer the whole story. That Assist allocation is defined by your contract and pooled at the account level. Different tasks draw the pool down at different rates. A straightforward generative task such as summarising a record costs roughly one assist. An agentic task that takes real action costs far more, and a single multi-step workflow can consume up to 150 assist units. When the pool runs out, top-up packs apply at a per-unit rate, and usage in your sub-production and development instances counts against the same pool. Your annual cost now has a variable component that depends on how your users and agents behave, not just on how many seats you bought.
Capability moved between tiers. This is the part platform owners need to read twice. The processes and features you rely on did not stay where they were. The most common ITIL processes (Problem, Change, and Major Incident) now sit in Advanced rather than the entry tier. DevOps Change Velocity, which was inside ITSM Pro, is now exclusive to Prime. Building net-new custom AI skills and agents is also a Prime-only right.
Translated into platform-owner language: the new tiers are not relabelled versions of your old plugins. The boundaries moved. A capability you switched on years ago may now live two tiers above where you expect it.
Here is the reassuring part, and the trap inside it.
A vendor cannot rewrite an active contract overnight. Existing customers stay on their current SKUs, entitlements, releases, and capabilities until a triggering event moves them onto the new model. That trigger is a renewal, a new subscription, add-on, or any other contractual change. Until then, nothing about your live environment changes. Most existing customers are not on the new commercial model yet.
The deadline that makes this urgent is the reported end of sale date for the legacy SKUs on 1 July 2026. After that date, legacy pricing cannot be reinstated. It is worth being precise about what does and does not move you, because the common fear is overstated in one direction and understated in another. Adding more of what you already own does not, by itself, move you to the new model. On an active contract you can usually co-term additional quantities of your existing SKUs at your existing terms. What moves you is buying something net-new, and after 1 July 2026 any fresh product, module, or AI capability is sold on the new model rather than the retired one. The quieter risk is the sales motion: an expansion or AI conversation is precisely the moment the account team will propose migrating the whole estate, and a routine "add a few licences" request is the meeting where that pitch arrives. The expansion does not trigger the repackaging on its own. It opens the door to it.
So the timing question is not only "when does my contract renew." It is "what is the next thing I will ask ServiceNow to sell me, and will that move me across the line." If a renewal, an expansion, or an AI initiative sits anywhere on your 2026 roadmap, that conversation is closer than you think, and the time to prepare for it is well before you sit down with the account team.
When the account team walks you through your migration, it will look clean. A neat table maps your old tier to its new equivalent, and the message is reassuring: continuity, with more capability than you had before. But it is worth slowing down here, because two things complicate that tidy picture.
The mapping is not feature-for-feature. Because capabilities moved, the "equivalent" tier may not actually contain what you run today. A customer on ITSM Pro who relies on Change and Problem Management maps to Advanced to keep those processes, not to Foundation. A team using DevOps Change Velocity has to reach Prime to keep it, a tier jump from where that feature used to live. CSM and ITOM customers should apply the same caution. If you accept the obvious mapping without auditing your real footprint, you can sign a contract that silently drops a process your operations depend on, or forces you up a tier to recover it.
The mapping is not one-for-one on price either. This is the point most customers miss. Under the old model, AI lived only in Pro Plus and Enterprise Plus, and it carried a premium of up to 60 percent over the base tier. Under the new model, that AI layer is baked into the floor. Foundation, the entry tier, already includes the Now Assist rights that used to sit behind the Pro Plus paywall.
If you were a Pro Plus customer, that bundling is close to what you already paid for. But if you were on ITSM Standard or ITSM Pro and never bought the AI add-on, you are now being quoted a rate that includes an AI layer you never had. You inherit the premium whether or not you intend to use the AI. The "like-for-like" renewal arrives with a higher effective per-fulfiller rate, and the justification is capability you did not ask for and may not yet be ready to operate.
Neither of these is a reason to avoid the new model. AI included in the platform is a good direction, and removing the separate procurement step lowers the barrier to getting value from it. The point is narrower and sharper: the migration is a set of commercial decisions wearing the costume of a feature update, and treating it as a swap is how value leaks out of the contract.
The awkward reality of 2026 is that the people who understand what the platform actually does (you, the platform owners and architects) are not usually the people who sit in the commercial negotiation. Procurement owns the order form. You own the instance. The repackaging has fused those two worlds, because tier choice is now simultaneously an architecture decision and a pricing decision, and neither team can make it well alone.
Consider what the tier decision now requires. To choose correctly between Foundation, Advanced, and Prime you have to know which ITIL processes you truly need over the contract term, whether you are configuring shipped AI or building custom skills and agents, and what your realistic assist consumption looks like once agents start doing work. Those are platform-owner questions. The answers then determine the commercial construct: which tier, how large an assist pool, what top-up rate, what uplift cap, what true-up mechanism. Those are contract questions. Get the platform answers wrong and the commercial terms are built on sand. Get the commercial terms wrong and the right platform design is locked into a contract that bleeds value.
Industry research has shown for years that a large share of features bought in tier upgrades go unused in the first year. The new model adds a second way to overpay: an assist pool sized for ambition rather than reality, or sized too small and topped up at premium rates. Both are value leaks, and both originate in the gap between the technical view and the commercial view.
No platform owner would let someone reconfigure a production instance without a certified system architect at the table. The commercial construct deserves exactly the same discipline, and for the same reason: small structural choices made early define what is possible later, and they are expensive to unwind once signed.
A contract architect does for your order form what a system architect does for your instance. They map your real, measured footprint against the new tiers before you accept any mapping, so you know precisely which capabilities move and what it costs to keep them. They help model your assist consumption against a tier's allocation, so the AI pool fits your roadmap rather than the vendor's optimism. They time the change to a moment of leverage, so an expansion or AI conversation becomes a planned migration on your terms rather than the vendor's. And they translate the commercial mechanics (uplift, true-up, top-up rates, price protection) back into language you and your finance team can both act on.
The goal is not to spend less for its own sake. The goal is value alignment: making sure every line on the bill maps to a capability funded in your roadmap and that the AI you are now paying for converts into outcomes rather than activated but idle features. That way you reach your time-to-value faster because the contract is built around how your platform actually runs. That is the difference between a renewal that inflates and one that accelerates the platform.
If a renewal, an expansion, or an AI initiative is anywhere on your 2026 plan, three moves protect your position:
Treat these as one connected decision, not separate technical and procurement workstreams. This is where the platform view and the contract view have to meet and the boundary between technical and commercial is exactly where value is lost.
The April 2026 model is not something to fear, and the ServiceNow platform remains as central and capable as ever. It is something to enter with your eyes open and the right expertise on your side of the table. The customers who extract real value from the AI layer will be the ones who did the unglamorous work of getting the structure right first.
Resources:
ServiceNow official
ServiceNow Community
Yet again, ServiceNow has delivered by far its largest release of new capabilities for generative AI powered by a platform with an entire new...
At The Cloud People, we’re basically on a first-name basis with them. If Yokohama were a dessert, Zurich would be the main course. All joking aside,...
Do you want to accelerate productivity and drive efficiency powered by GenAI? Do you want to improve experiences for both your employees and...