Bring your own software licence, the cloud policy, and running on AWS and Azure without losing sub capacity. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real IBM negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to session fourteen. Today the workloads leave your data centre, and almost nothing about the licensing leaves with them. That is the whole session in a sentence, and it is worth sitting with, because the instinct when moving to a public cloud is that somebody else now owns the infrastructure and therefore owns the counting. They do not. The same PVU you counted on a host has three possible homes now, and two of the three leave you counting exactly as before, on hardware you no longer control and cannot see. Three knowledge checks. Let's begin.
Five objectives. First, state what bring your own software licence actually gives you, which is that existing entitlements move to eligible providers and sub capacity rules still govern the count. You do not buy the licence again, you move it. Second, name the two conditions that void it, because maintenance must be current since a lapse disqualifies bring your own licence on most products, and the cloud target must be on the eligible list. Third, keep the clock running through a migration, because the tool is mandatory in cloud, the ninety day window runs from deployment, and IBM accepts quarterly reports and almost nothing else as proof. Fourth, handle elastic capacity, because bursts, replicas and autoscaling are each a counting argument. And fifth, compare the three tracks honestly, since only one of them retires the metric and ends the reporting obligation.
Four numbers, from a worked twenty core WebSphere estate. One thousand four hundred, the PVUs for the deployed pods under sub capacity, against two thousand five hundred and twenty for the whole host if the reporting lapses. One hundred and forty three thousand, the dollars a year of support for cores nobody ran IBM software on, which is what a missed reporting clock buys you. Eight of ten, the migrations reviewed where the lift happened first and the entitlement reconciliation never followed at all. And two to five times, what reporting gaps on cloud hosts exposed buyers to against the sub capacity position they believed they held. Then the note, which is the honest summary of the whole track comparison. Bring your own licence wins on annual cost only if the clock never slips. If it does, that exposure erases the saving in a single audit.
Guest analyst clip. You do not buy the licence again, you move it. That sentence is the good news about bring your own licence and it is entirely true, and I want to spend a moment on why it is also the reason people get caught. Because when somebody hears that their existing entitlements simply travel to AWS, what they take away is that this is a solved problem. The licence is ours, we already paid, it comes with us. And that is right. What does not come with it is any of the machinery that made the cheaper count legal, which now has to be rebuilt on infrastructure you do not own and cannot walk into. The measurement tool has to be deployed there, inside the window, reporting quarterly, archived for two years. The support has to stay current, and if some perfectly sensible cost exercise lets it lapse, the entitlement to count sub capacity goes with it. So my framing is this: bring your own licence transfers the asset and it also transfers the obligation, and organisations remember the first half with great enthusiasm and the second half not at all. The half people forget is the half that has a price.
It transfers the asset and it transfers the obligation, and people remember the first half enthusiastically. So let us lay out the three tracks properly.
Three homes for the same workload, and a fourth option worth naming. Bring your own licence counts PVU under sub capacity on eligible providers, constrained by mandatory reporting and current support. A Cloud Pak pool counts Virtual Processor Cores against a bundle, constrained by the fact that the conversion is one way and the original PVU pool is gone once you take it. An IBM SaaS subscription counts nothing you have to count, because it retires the metric and ends the reporting obligation, at a price. And a dedicated host counts physical cores with no sub capacity needed at all, constrained by infrastructure that runs two to five times the shared rate. The note underneath is the point I would make in any business case. These are not just three prices, they are three different amounts of ongoing work, and that is the part a spreadsheet comparison almost always leaves out.
Knowledge check one. To save cost, a team lets support lapse on a product running under bring your own licence on AWS. What happens? A, nothing, the licence is perpetual and the deployment continues. B, the right to count sub capacity is lost, and IBM is entitled to full capacity on the host. C, only future upgrades are lost. D, the workload must be moved back on premises. Pause here, and ask which of the two conditions that decision touched.
The answer is B. A lapse in support disqualifies bring your own licence on most products, so the saving on maintenance buys a full capacity position on a cloud host whose size you do not control. Answer C is the one I want to highlight, because it is not a careless answer. It is precisely what session four taught you about dropping support, and on premises it is broadly right. The same decision has a different consequence once the workload sits in a cloud, and nobody making the decision is likely to know that, which is why the support register and the cloud inventory need to be readable side by side.
So, what the policy permits. Entitlements move rather than being rebought, so existing Passport Advantage entitlements apply on eligible providers and the metric is unchanged when they get there. The eligible list is a real gate, covering AWS, Microsoft Azure, Google Cloud, IBM Cloud, Alibaba Cloud and several others, while niche regional clouds typically do not qualify. Support must stay current, which is the first of the two conditions and the one a cost saving exercise is most likely to break without anybody realising what it touched. Rights are often narrower in cloud, because in most contracts reviewed the bring your own licence rights were narrower there than on premises, so read your terms rather than the marketing. And sub capacity still has to be earned, since the move does not change the four obligations from session seven at all. It changes where the hosts are, and who owns the hypervisor.
Now sub capacity on somebody else's infrastructure, five points. Reporting is mandatory and quarterly, with the tool required in cloud exactly as on premises, and IBM accepts quarterly reports and almost nothing else as proof of a cloud sub capacity position. The ninety day clock runs from deployment, not from the audit letter and not from the end of the migration project, and missing the window means full host capacity applies for that period. The rate is commonly seventy per core on standard x86 instance families across the major providers, which makes cloud arithmetic familiar rather than novel. The hardware report is the reconciler, because a cloud console vCPU is often a hyperthread rather than a physical core, so the provider hardware report is what normalises the count, and it is a required condition rather than a nice to have. And specialist hardware is rated differently, since IBM Cloud LinuxONE runs at one hundred and twenty PVU per core, so a like for like move onto specialist infrastructure is not a like for like licence position.
Guest analyst clip. The number I would carry out of this session is the gap between one thousand four hundred PVUs and two thousand five hundred and twenty on the same estate, because it is the clearest illustration I know of what the reporting obligation is actually worth. Same workload, same twenty cores of pods doing the same job. The only difference between those two numbers is whether a tool was deployed inside a window and produced reports somebody kept. In annual support that difference is around one hundred and forty three thousand dollars, every year, for cores that never ran IBM software. And here is what makes it sharper in cloud than on premises. On premises, if the tooling lapses, somebody may eventually notice a stale server. In a cloud migration the whole environment is new, the project team is temporary, and there is often no established owner for the reporting at all, because the estate did not exist six months ago. So the failure has no natural discoverer. My rule for any cloud migration is therefore blunt: the tool is part of the landing zone, not part of the follow up work. If it is on the after the migration list, it will be done late, and late has a fixed price.
The tool is part of the landing zone, not part of the follow up work. Because a new environment has no established owner for the reporting, and no natural discoverer for the failure.
Knowledge check two. Your container cluster autoscales, and the quarterly report captures a moment when it was small. What is the risk? A, none, a snapshot is a snapshot and the report is what counts. B, transient peak capacity is a counting argument IBM can open, and the defensible answer is a quarterly high water mark. C, autoscaling is exempt from sub capacity counting. D, the cluster must be pinned to a fixed size to be licensable. Pause here, and ask what an auditor does with capacity your report never happened to see.
The answer is B. Cloud raises audit risk because the things IBM counts become elastic, and autoscaling moves capacity faster than a quarterly snapshot can capture. Answer A is comfortable, and it is a position you would rather not have to defend, for a slightly subtle reason. A favourable snapshot invites the argument that unfavourable moments existed and were simply missed, and once that argument is open you are disproving a negative about a period you did not measure. Hold the high water mark yourself, quarter by quarter, and the argument has nowhere to go, because you measured the worst moment and reported it.
So, elasticity, three vectors and the evidence that closes each. Container bursts are scoped as peak virtual CPU across the cluster, and closed by pod level limits and namespace caps, which is session twelve's manifest line doing the work again. High availability replicas are scoped as standby and failover copies, and closed by the cold standby terms and the replica entitlement rules in your agreement, which means somebody has to have read them. Autoscaling is scoped as transient peak capacity, and closed by a quarterly high water mark you produce rather than an instantaneous peak somebody else selects. The pattern is the same each time, where elastic infrastructure widens what can be argued and specific retained evidence narrows it back, and nothing there is novel except the speed. And the tool needs the detail, because it has to see the pods, the limits and the namespace boundaries to count deployed cores instead of the whole node.
Guest analyst clip. Elasticity is the genuinely new thing about cloud licensing, and I want to be precise about why, because it is not that cloud is more expensive or that vendors are more aggressive there. It is that the quantities move faster than the measurement. A quarterly report was a perfectly reasonable instrument when a data centre changed shape a few times a year. Point it at an autoscaling cluster and you are sampling something that reconfigures itself hourly, and any single sample is going to be wrong in one direction or the other. Now, the interesting consequence is that this cuts both ways, and buyers usually only think about one of them. Yes, a sample can miss a peak, and that is exposure. But a sample can also catch a peak that lasted forty minutes on one unusual afternoon, and if that is the number in your report, you have handed over an unrepresentative worst case as though it were the norm. So what I recommend is that you take control of the sampling rather than accepting whatever the schedule produced. Record the high water mark deliberately, understand what drove it, and be able to say this was the peak, this is why, and here is the sustained level. That is a document you wrote on a calm day, which is worth a great deal more than a number that happened to you.
Take control of the sampling rather than accepting whatever the schedule produced. A document written on a calm day beats a number that happened to you.
Now the geography clause, which nobody reads before choosing a region. Passport Advantage is contracted by geography, so a United States agreement does not automatically permit deployment into an APAC or EMEA cloud region, however easy the console makes it look. A region choice is therefore a contract question, made routinely by architects for latency, resilience or data residency reasons, none of which surface the licensing consequence at the moment of choosing. The remediation is an amendment, adding the geographies to the agreement, or relocating the workload into in geography regions, and both are far cheaper before deployment than after. So ask it during design, with one question at architecture review, which geographies will this run in and does our agreement cover them, and that costs a minute. And it compounds with everything else, because a workload in an uncovered region with a lapsed reporting clock is two findings on one deployment, discovered at the same moment by the same person.
And then the migration itself, where five things go wrong. Paying twice for six to twelve months, because the old licence stays live and billing while the cloud entitlement starts on day one and nobody reconciles, since the project is busy doing the migration. The reconciliation that never happens, because in roughly eight of ten migrations reviewed the lift happened first and the entitlement reconciliation never followed at all. Cloud Pak conversion being one way, so once converted to Virtual Processor Cores the original PVU pool is gone, which means you model it before rather than discovering it after. An open audit not pausing, because an audit motion in progress covers the migration window, so a move made mid audit is measured by the audit it is running inside. And the reporting cadence breaking in transit, because the quarter a workload moves is the quarter most likely to be missing from both archives, and it is exactly the quarter that gets asked about.
Knowledge check three. Which of the three tracks removes the reporting obligation entirely? A, bring your own licence, because the entitlement is already yours. B, a Cloud Pak pool, because the bundle covers the components. C, an IBM SaaS subscription, because it retires the metric with the product. D, none of them, the obligation is universal. Pause here, and ask which track stops you counting anything at all.
The answer is C, the SaaS subscription. It replaces the underlying product, retires the metric and ends the reporting obligation in one move, and it is usually the most expensive of the three on paper. Answer B is the near miss and worth being precise about. A Cloud Pak changes which tool reports and which unit is counted, and the obligation itself survives entirely intact, as session twelve covered at length. So what you are really choosing between across these three tracks is not simply price. It is money now against operational discipline sustained for years, and organisations are much better at estimating the first than the second.
Guest analyst clip. When I help a client compare these three tracks, the spreadsheet always makes bring your own licence look best, and I have learned to be suspicious of that, not because the arithmetic is wrong but because of what the arithmetic omits. The annual costs across the three tracks are usually within a fairly narrow band. What differs enormously is the ongoing operational burden, and that is a cost that never appears in a row. Bring your own licence asks your organisation to maintain a measurement discipline, in a new environment, indefinitely, and to keep support current on every product forever. SaaS asks you to do nothing at all and charges you for the privilege. So the question I put to the client is not which is cheapest, it is which of these does your organisation actually do well. And I ask them to answer it with evidence rather than intention: how many quarterly reports do you hold for the estate you already have. If the honest answer is eight out of eight, bring your own licence is a good trade and you should take it. If the honest answer is that nobody is quite sure, then the cheapest looking track is the one most likely to produce a large surprise, and paying more for something that cannot go wrong may be the better decision. That is a self assessment, not a licensing question, and it is the one that actually decides the outcome.
So, running IBM software on somebody else's infrastructure, five things. A cloud licensing check at architecture review, asking whether the provider is eligible, the geography is covered, support is current and reporting is planned, and that is four questions before anything gets built. The reporting clock started deliberately, with the deployment date recorded, the tool live inside the window, and the first quarterly report generated from the first quarter rather than from the third. A high water mark held per quarter for every elastic thing, because the alternative is accepting somebody else's reading of your peaks. A decommission step in every migration plan, so the old entitlement is retired or redeployed on a date and the double payment window is weeks rather than a year. And the track decision revisited annually, because bring your own licence, pool or SaaS is not a one time answer, and the cheapest track depends on discipline you can actually sustain.
Three sentences. Bring your own software licence moves existing entitlements onto eligible providers rather than making you rebuy them, and it rests on two conditions, current support and an eligible cloud target, either of which can be broken by a decision taken for entirely unrelated reasons. Sub capacity in the cloud is the same bargain as on premises, with reporting mandatory and quarterly, the ninety day clock running from deployment, the rate commonly seventy per core on standard instances, and the provider hardware report reconciling what a console calls a vCPU to what the metric calls a core. And elastic capacity widens what can be argued, so bursts, replicas and autoscaling are each closed by specific retained evidence, while on a worked estate the difference between a reporting clock that held and one that slipped was one hundred and forty three thousand dollars a year, which erases the saving that made bring your own licence attractive in the first place.
Homework, about an hour. List your IBM workloads in cloud, meaning which products, which providers and which regions, and if that list does not exist then building it is the exercise, and it is usually shorter than people fear. Check the geography clause, asking which geographies your Passport Advantage agreement covers and whether the regions on your list all sit inside them. Confirm the reporting clock for one workload, asking when it was deployed, when the tool started seeing it, and whether you can produce a quarterly report from that first quarter. Find a double payment, by taking anything migrated in the last two years and asking whether the on premises entitlement was retired or redeployed, and on what date. And check support currency, because every product running under bring your own licence needs current maintenance, and one lapsed line is a full capacity position on a host whose size you do not set.
Five guides. The cloud migration licensing guide covers how entitlements move, what the terms library governs, and why the reconciliation after a lift so rarely happens. The cloud migration traps guide is the practical companion, with the eligible cloud list, the hardware report that normalises a vCPU to a core, the geography clause and the dedicated host trade. And the ILMT sub capacity guide covers the ninety day rule and two year retention as they apply wherever the host happens to live, which is the point.
The PVU sub capacity guide covers eligible technologies and what a lapse costs, and that arithmetic is identical on a cloud instance and on a rack in your own building. And IBM licensing explained gives the estate view, including where cloud and container deployments sit against the rest of the metric catalog. Next time, module three closes with Maximo, Watson and the newer portfolio: AppPoints, the consumption models, and the AI additions. See you there.