How to Size MAS AppPoints Without Overpaying

Maybe a reseller handed you a quote that feels high, maybe you were told to go figure it out, and either way you do not want to sign a multi-year contract sized around a guess. This is how to build a number you can defend, and how to make it smaller without cutting anything anyone actually uses.

Why most sizing comes out too big

Most AppPoint sizing starts from the wrong place. Someone exports the current user list, counts heads, assumes every head needs a full license, and asks the reseller to price that. The number that comes back is almost always too big, for a reason that is structural and easy to miss. It sizes your future bill off your present access, and your present access is the accumulated mess you are migrating to get away from. Ten years of "just give them access so they stop calling me" becomes ten years of AppPoints you pay for, every year of the new contract.

And it is every year. In many MAS deals, AppPoints are purchased as a committed pool for a defined subscription term, and if you over-size that pool you may be stuck carrying the overage until renewal or renegotiation. An oversized number is not a one-time mistake you fix next quarter. It is a recurring charge you locked in. That is the whole reason this work pays back: get the number right once, before you sign, and the savings repeat across the term.

The good news is that sizing AppPoints right is not a negotiation with IBM and it is not guesswork. It is a method. You decide what each role actually needs, you model how those roles consume, and you tighten the access that is padding the bill. Every move is a security design decision with a license consequence. Here is the difference between the two approaches.

Tier follows the apps, not the title

Start from what people do, not what they can currently open. MAS has six license types. From most to least capable: Premium is full access to the premium applications, Base is standard access for the everyday Manage user, Limited is a narrow slice, Self-Service covers approved self-service use cases such as request and status activity and is modeled at zero AppPoints, Admin Premium is the administrator tier, and No-Access holds a user record with no consuming license at all.

Assign each role the lowest tier that still covers the apps its work requires. A role lands on Premium only because it genuinely needs a premium app. If a role's app set fits inside Base, it is a Base role, and you just saved the difference on every person who holds it. The rule that matters most here: do not assign tiers by job title or seniority. A senior reliability engineer who only opens base apps is a Base user. The tier is about what the work requires, not about how important the person is. The moment you start handing out Premium because someone is senior, you are back to sizing off status instead of work, and status is expensive.

Two more decisions ride alongside the tier. The first is the access type, Authorized or Concurrent, which is a separate lever from tier. Tier is what a role can do. Access type is how it consumes. An Authorized license is named and dedicated to one person whether they are logged in or not. A Concurrent license is shared from a pool and only consumes while someone is actually logged in, so a pool can cover a larger headcount as long as they are not all on at once. Decide it per role, and do not assume Concurrent is the cheaper option. It costs more per seat, and it only wins on roles whose peak on at once runs well below their headcount. That is a narrower set than most people expect, and getting it backward is the most common sizing mistake I see, so it gets settled deliberately, one role at a time. For your own roles, put the real peak into the free Concurrency Calculator before you commit.

The second is admin. Admin Premium is the most capable and most expensive tier. Use it for the few people who genuinely administer the platform, not as a convenience for power users or consultants who could work on a lower tier with the right app access. Admin accumulates, especially during a migration, when every temporary admin granted to get through go-live quietly stays a premium license until someone takes it back. Grant it narrowly, write down who has it, and put it on the audit list from day one.

The output is one line per role: the tier, the access type, and a flag for the self-service and admin roles.

The three things that break simple headcount math

Once each role has a tier and an access type, the temptation is to multiply tiers by headcount and call it sized. Three things make that wrong, and missing any of them throws the model off enough to matter at budget time.

First, weight by tier. Modeled consumption is not a headcount. It is the sum across roles of headcount times the AppPoint weight for that role's tier, and the heavy tiers carry far more weight than the light ones. Your handful of Premium and admin users is where the points concentrate. Model it as a flat per-head rate and you will undercount badly. Model it as a weighted sum, tier by tier, and the mix tells the truth.

Second, model concurrent roles on peak, not headcount. An authorized role multiplies by its full headcount, because those seats consume whether or not anyone logs in. A concurrent role multiplies by peak concurrency, the largest number on at once, because that is all the pool has to cover. Get that peak honest, because that single number, not the shift count, decides whether concurrent saves anything at all.

Third, self-service is zero, but keep the row. Every role you moved to Self-Service contributes zero AppPoints. Model it as zero and leave the row in your sheet anyway, because the budget owner needs to see the headcount you took to zero. A line that reads two hundred requesters at zero points is not clutter. It is the visible proof of the biggest reduction you made.

That last row is the one that quietly wrecks budgets, and it is also the one where the rules depend on your deployment model, so it is worth slowing down on. Not everything in MAS is priced per user. Several add-ons are licensed by the install or the environment rather than by AppPoint per head, so they do not flow through the per-user math at all. Model them on their own lines. How non-production gets priced is one of the biggest swings in the whole model, and it splits by deployment. In a customer-managed or subscription install, applications, add-ons, and solutions carry zero install AppPoints in a non-production environment, so dev and test do not repeat the production install cost, though the users who work in them still consume. In the hosted SaaS model it can be the opposite: a non-production environment is not free at all. It carries its own defined block of AppPoints, and a second non-production environment carries another. Either way the discipline is the same. Find out how your model prices non-production, put each environment on its own line, and never size dev and test as if each one were a second full production. Confirm the current terms against your IBM agreement, because this is exactly the kind of commercial detail that differs by model and changes between releases.

Where tightening access cuts the bill

This is the payoff. Every reduction below is a security change with a license consequence. You are not negotiating price. You are designing access more tightly, and the AppPoint number follows.

A word on that last one, because it is the least obvious. Access combines across a user's groups toward the most permissive, so every excess app sitting in a base role is carried by everyone who holds that role. Tightening one bloated base role can lower the effective tier for an entire population at once. It is the highest-impact cleanup you can do, and it is invisible until you go looking for it.

The part nobody warns you about

Here is the senior insight, and it is not technical. The hardest part of taking access away is not the configuration. It is the people. Access reads as status. The manager who has had Premium for years hears "we are moving you to Base" as a demotion, even when they have never opened a premium app. The supervisor who loses admin hears it as a loss of trust. Treat this as a pure spreadsheet exercise and start pulling access by the numbers, and you will be technically right and you will lose, because the resistance will route around you to someone who can overrule you.

So handle it like the political act it is. Lead with the data, not the judgment. Show the login record and the app usage, so the conversation is about facts and not about whether someone is important. Frame it as cost, not punishment. The organization is paying for a tier this person does not use, and that money is better spent elsewhere. Give people a clean path back. If someone genuinely turns out to need the access, the add-on role is one assignment away, so the change is reversible and low-risk. And get air cover before you start. The security owner and the budget owner should agree on the reduction targets up front, so when the pushback comes, and it will, you are executing an agreed plan instead of picking a fight. Take access away the right way and you keep both the savings and the relationships. Do it clumsily and you will have the access restored and your model unwound inside a month.

Validate before you sign

A model is not a purchase. Before you commit, put three numbers side by side: what your target design will consume, what you currently hold, and the gap between them. If your modeled need is below your holdings, you have room to let some lapse or redeploy at renewal. If it is above, you decide whether to procure the difference or go back and cut more access. Many well-run designs land at or below holdings after the reductions above, which is the point of doing the work.

If you are still on 7.6 and do not have an AppPoint number yet, IBM ships a small usage tool you install into 7.6 that captures actual connection counts and peak concurrency without sending anything out. Install it and let it run for a few weeks before you finalize. It hands you a measured peak instead of an estimate, and peak concurrency is exactly what your concurrent pool has to cover. It also gives you a defensible number to hand procurement, which beats a model you built by hand when someone challenges it.

And do the compare against the clock. The dual-support window for running EAM 7.6.1.x under a MAS license is currently set to end April 30, 2027. IBM also states that perpetual trade-up customers must complete migrations to MAS by that date, because EAM usage rights expire after it. Treat that as a planning marker, not a hard wall, and confirm your specific trade-up and subscription terms with IBM or your reseller before you let it drive a purchase. I am giving you the shape of the decision, not financial advice. I am not a licensing rep and I am not your accountant. The number that matters is the one on your quote, not the one in this article.

What good looks like

You know your sizing is right when you can defend every line of it. The heavy tiers are weighted, not flattened. The intermittent, low-peak roles are modeled on peak concurrency, not headcount, and steady crews are not assumed cheaper on concurrent just for running shifts. The self-service rows are visible and sitting at zero. Dev and test are modeled as their own environments, priced the way your deployment model prices them. And every tier assignment traces back to an app the role actually uses, not to a title. When someone challenges the number, you answer with usage data, not opinion. A well-run design usually lands at or below what you already hold, and you can walk a budget owner through it in one meeting without flinching.

Where to start

1. List your roles by what people actually do in a normal week, not by what they can currently open.
2. Map each role to the apps its work requires, and assign the lowest tier that covers them.
3. Flag every role whose whole job is requesting and checking status, and move it to Self-Service.
4. Decide Authorized or Concurrent for each role by how it actually works: constant coverage leans authorized, intermittent low-peak populations lean concurrent.
5. Model it as a weighted sum: tier weight times headcount, concurrent rows on peak, self-service at zero, install-based add-ons on their own lines, and each non-production environment priced the way your model prices it.
6. Compare that number to what you hold, and find your gap.

That gets you a defensible first-pass number you can take into a budget conversation.

What this is worth

Work a rough example. Say five hundred people touch Maximo. The naive sizing licenses all five hundred at Base or above. Now run the levers. Two hundred of them only submit and check requests, so they move to Self-Service at zero. Of the three hundred left, maybe thirty genuinely need a premium app, so those thirty hold a Premium add-on and the other two hundred seventy sit at Base instead of the whole group riding Premium. A slice of that group only logs in intermittently, so instead of an authorized seat each they draw from a concurrent pool sized to their peak, which sits well below their headcount. The crews on steady coverage stay authorized, because for them concurrent would not pay. You have not removed a single capability anyone uses. You removed paying for capability nobody uses.

Put your real headcount and the current AppPoint weights into that math and the gap between the naive number and the designed number is usually large. Then remember it repeats every year of a multi-year term. That is why an afternoon of honest role design is worth more than any discount a reseller can offer you.

This article covers the method. The next step is a number: run your role counts through the free AppPoints Estimator. It does this math on your own headcount and tiers, so you can walk into the budget conversation with something concrete. When you are ready to build it for real, the Maximo Right-Sizing Playbook walks the full process, from the role model through the Access-to-AppPoint Impact Matrix, the consumption model, and the validation against your entitlement and the trade-up window.

If your operation spans many sites and thousands of users, this method still holds, but it is a project rather than an afternoon. If you want to talk through your situation, quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.

Frequently Asked Questions

How do I size MAS AppPoints without overpaying?

Start from what each role actually does, not the current user list. Assign each role the lowest tier that covers the apps its work requires, move pure requesters to zero-cost Self-Service, decide Authorized or Concurrent per role on real peak concurrency, and model consumption as a weighted sum by tier. Then tighten the access that is padding the bill, because every reduction is a security change with a license consequence.

What are the MAS license tiers?

MAS has six license types, from most to least capable: Premium for full access to premium applications, Base for standard Manage use, Limited for a narrow slice, Self-Service for approved request and status use cases and modeled at zero AppPoints, Admin Premium for the administrator tier, and No-Access for a user record with no consuming license. Assign each role the lowest tier that covers its apps.

Is Concurrent licensing cheaper than Authorized in MAS?

Not automatically. A Concurrent license costs more per seat and only wins on roles whose peak logged in at once runs well below their headcount. Steady, full-coverage crews are usually cheaper Authorized. Put the real peak into a concurrency model before you commit, because peak, not shift count, decides whether concurrent saves anything.

Why does tightening security reduce the AppPoint bill?

Because in MAS the tier a role consumes is set by the most capable app it can open, and access combines across a user's groups toward the most permissive. An excess app sitting in a base role is carried by everyone who holds it, so trimming one bloated base role can lower the effective tier for an entire population. Access design is the bill.

Quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.