# How to Migrate Off Per-Seat AI Pricing > Source: https://ibl.ai/resources/guides/migrate-off-per-seat-ai-pricing > Last updated: 2026-08-19 *Modelling the real all-in cost, sequencing workloads so the move de-risks itself, and the exit-cost arithmetic that decides your negotiating position* Reading time: 13 min read | Difficulty: intermediate **On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.** ## How do you migrate Off Per-Seat AI Pricing? Per-seat AI pricing scales with headcount while AI consumption follows a power law, so the two curves separate as an organization grows. The gap is what makes migration worth the effort — but the effort is real, and a migration that stalls halfway costs more than either endpoint. The first task is arithmetic, and it is where most business cases go wrong: the advertised seat price is frequently an add-on figure that requires a base licence underneath. The second is sequencing. Moving the highest-volume, lowest-risk workload first produces a measured saving that funds and justifies the rest, which is what keeps a migration from stalling at the pilot. ## Prerequisites - **Your actual consumption data:** Requests per user per period, not licence counts. Most organizations discover that a minority of licensed users generate the large majority of usage. - **The full contract terms:** Including prerequisite base licences, promotional expiry dates, minimum commitments and renewal notice periods. These determine when a migration can actually land. - **An inventory of integrations:** Every system the current AI touches. Integration work is usually the largest line in the migration estimate and the most commonly underestimated. - **A named owner:** Migrations that belong to nobody stall at the pilot. This needs someone accountable for the end state, not just for the evaluation. ## Step 1: Model the real all-in per-seat cost Start with the number you are actually committed to, not the advertised one. AI seats are frequently add-ons requiring a qualifying base licence, which can double or triple the effective figure. - [ ] Identify every prerequisite licence the AI seat requires - [ ] Multiply the all-in rate by licensed seats, not active users - [ ] Note promotional rates and their expiry dates — Model the renewal figure, not the introductory one. - [ ] Add any consumption-based agent charges layered on top **Tips:** - A worked example: a $30 per-user add-on requiring a base plan is $69 per seat on E3 or $90 on E5 all-in — at 10,000 seats that is $8.3M–$10.8M a year against a $3.6M budget built from the sticker. ## Step 2: Measure what the same work costs as usage Take a representative sample of real requests, measure tokens consumed, and price them against the models you would actually route to — including a cheap local model for the routine tail. - [ ] Sample real requests across departments, not just power users - [ ] Measure input and output tokens separately — Output is typically priced several times higher. - [ ] Price under a realistic routing plan rather than one default model - [ ] Add infrastructure and operational cost if the plan includes self-hosting ## Step 3: Estimate exit cost from the incumbent This number rarely appears in a business case and frequently determines whether the migration is viable. What would have to be rebuilt to run equivalent workloads elsewhere? - [ ] Agent definitions, prompts and tool configurations - [ ] Retrieval indexes and any tuned embeddings - [ ] Evaluation sets and historical results - [ ] Audit history a regulator may later request — If this lives in the vendor's platform, ending the contract ends your access to it. ## Step 4: Sequence by volume and risk, not by department politics Move the highest-volume, lowest-risk workload first. It produces the largest measurable saving soonest, which is what funds and justifies the remainder of the migration. - [ ] Rank workloads by request volume - [ ] Score each for risk if output quality slips - [ ] Start with high volume and low risk — Document classification and internal search are typical first movers. - [ ] Keep the incumbent running in parallel for the first workload ## Step 5: Run both in parallel and compare on your own evaluation set Parallel running is what turns a migration from a leap into a measurement. It also produces the evidence that makes the next workload an easy decision rather than an argument. - [ ] Route a percentage of live traffic to the new platform - [ ] Compare outputs on the same held-out evaluation set - [ ] Track cost per thousand requests on both sides - [ ] Publish the comparison internally — Migrations stall on doubt more often than on technology. ## Step 6: Time the contract exit against the renewal window Complete the technical migration before the notice period closes. A migration that finishes a month after auto-renewal buys another year of the cost you were trying to remove. - [ ] Diarize the renewal notice deadline at the start of the project - [ ] Export all data and audit history before the contract ends - [ ] Verify exported data is usable, not merely delivered - [ ] Reduce seat counts progressively where the contract permits ## Common Mistakes ### Comparing the add-on sticker price to the new platform's total cost **Consequence:** The incumbent looks far cheaper than it is, and the business case fails on arithmetic rather than on merit. **Prevention:** Count prerequisite base licences on the incumbent side, and infrastructure and operations on the new side. Both or neither. ### Migrating the most sensitive workload first **Consequence:** The riskiest change happens when the team has the least experience with the new platform, and one bad outcome stops the programme. **Prevention:** Sequence by volume and risk. High volume, low risk first — the saving is largest and the downside is smallest. ### Missing the renewal notice window **Consequence:** Auto-renewal locks in another full term of the cost the migration was meant to eliminate, regardless of technical completion. **Prevention:** Diarize the notice deadline at project kickoff and treat it as the real deadline, ahead of the technical one. ### Leaving audit history behind **Consequence:** Records a regulator later requests are inside a platform you no longer have access to, and cannot be reconstructed. **Prevention:** Export and verify all audit history before the contract terminates, and confirm the export is readable outside the vendor's tooling. ## FAQ **Q: How do you compare per-seat and usage-based pricing honestly?** Model the same workload under both: headcount times the all-in seat rate against measured token consumption times the model rates you would actually route to. Include prerequisite licences on one side and infrastructure and operations on the other, or the comparison flatters whichever side you shortchanged. **Q: How long does a migration take?** Integration work dominates, so it depends on how many systems the AI touches rather than on the model or platform. Sequencing by workload lets value arrive continuously instead of at the end, which matters more than total elapsed time. **Q: What if usage-based cost turns out to be unpredictable?** Set a budget cap. A well-designed usage model has a ceiling the organization chooses, with auto-refill as an explicit opt-in, so the maximum is a number you set rather than one you discover on an invoice. **Q: Can you migrate partially and keep some seats?** Yes, and it is often the pragmatic path — particularly where the incumbent's suite integration is genuinely valuable for a subset of users. The saving still scales with the share of workload moved. **Q: What is the strongest argument to leadership?** Usually the exit-cost number. It reframes the decision from 'which tool is better' to 'how much leverage do we have at every future renewal', which is a question executives answer differently. ## Can you do this on infrastructure you own? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.