① Journal · BMC AMI Cloud
AMI Cloud was sold on a tape displacement savings story, and the renewal is where that story meets the invoice. What moves the number is realized savings, validated capacity, and the cloud cost that sits below the license. Here are five levers that commonly move a BMC number, and how to build each.
AMI Cloud was sold on a savings case. The renewal is where it is tested.
BMC AMI Cloud is BMC's portfolio for moving mainframe backup and archive data to cloud object storage, consolidating tape, backup and archive management into a software defined layer that aims to replace physical and virtual tape libraries. It spans AMI Cloud Data, Vault and Analytics, and is commonly sold against a tape displacement business case, the promise that cloud object storage costs a fraction of proprietary virtual tape. Because it is a newer portfolio sold on a forward projection, the renewal is the first moment the case can be tested against reality.
As a storage and data movement product, AMI Cloud is commonly priced on capacity and consumption, the volume of data managed and moved, rather than on the MSU (Million Service Units) model that governs most z/OS software. That changes the levers entirely: the renewal turns on realized savings, the capacity tier, and the underlying cloud object storage cost that sits outside the BMC license. Read this with our explainer on building the real mainframe TCO model and the BMC publisher hub.
AMI Cloud renewal levers · what moves the number and how it works
| Lever | What moves the number | How to build it |
|---|---|---|
| VTL displacement case | Realized savings against the original case sets the bar | Measure actual tape and VTL cost removed, not projected |
| Capacity tiers | A tier matched to real data volume avoids overbuy | Validate consumed capacity against the contracted tier |
| The cloud cost stack | Object storage cost below the license drives true TCO | Model the full stack, BMC license plus cloud egress |
| The consumption baseline | A base set on real volume caps the recurring number | Check the base was not set on a migration spike |
| Exit and portability rights | The ability to move data out caps the lock in premium | Write data portability and exit terms into the deal |
These are patterns and levers we commonly observe on BMC AMI Cloud renewals, not statements of BMC policy or guaranteed outcomes. Your specific entitlement, pricing model, and contract terms govern; treat them as the analysis to build, validated against your own usage and contract data.
AMI Cloud was sold on a tape displacement case, and the renewal is where projection meets invoice. Measure what actually came out: the physical and virtual tape cost removed, the floor space and hardware retired, the operational effort saved. Set that realized figure against the original business case. Where reality matched the promise, the renewal is justified on its merits; where it fell short, the gap is the buyer's leverage. Evidence negotiates; the vendor's slide deck does not.
Renew on realized savings, not the case it was sold on.
The BMC license is only one layer. Below it sit cloud object storage charges, retrieval and egress costs, and the network to move data, all of which land outside the AMI Cloud line but inside the real total cost. Model the full stack before the renewal, because a license that looks cheap above a costly storage tier is not the saving it appears to be. The TCO you build is the number you should be negotiating, not the license in isolation.
Negotiate the full stack, not the license floating above it.
Moving backup and archive data into a vendor's cloud layer creates a new dependency, and the time to address it is at the renewal, not after. Data portability terms, defined exit assistance, and clear rights to retrieve your data in a usable form cap the lock in that a storage platform naturally builds. The portability you write into the contract is the leverage you keep for the next cycle; the dependency you leave unaddressed is the one that prices you later.
Put data portability in writing, or fund the dependency later.
④ Where the AMI Cloud number is won
The AMI Cloud number moves on realized savings. Validate the capacity, model the full stack. Write portability in before the data is locked.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
The business case it was sold on. AMI Cloud displaces physical and virtual tape against a savings story, and that story sets the bar the renewal must clear. A buyer who measures realized savings against the original case, and validates consumed capacity, negotiates from evidence. The capacity tier the charge sits on is the second lever.
It is a storage and data movement portfolio, so pricing is commonly tied to capacity and consumption rather than the MSU model that governs most z/OS software. The renewal turns on the capacity tier, realized versus projected data volumes, and the cloud object storage cost below the license. Validate all three against actuals. See building the real TCO model.
At least twelve months before the term expires, with realized savings measured well before that. AMI Cloud is sold on a forward case, and the renewal is where it meets reality. Measuring actual displacement and cloud cost takes a full operating cycle. See how vendors time renewal pressure.
Renewing on the original projection instead of realized savings, ignoring the cloud storage cost below the license, and addressing data lock in too late. Our license negotiation service measures the realized case and models the full stack, and our BMC renewal advisory writes the portability and exit terms.
Related: building the real TCO model · AMI Data for Db2 renewal negotiation · AMI DevX renewal negotiation · BMC renewal advisory · license negotiation
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →