Why the Maximo Migration Clock Is Real Now, and Why Your Security Model Is the License Bill

Short version: there are two clocks running, and they are now close enough to matter to your budget and your project plan. You can get that part from any vendor. Here is the part most of them will not tell you, because it works against the easy sale. In MAS, your security model is your license bill. Whatever access design you carry into MAS sets what you pay every year. If you lift your current setup and shift it over, you port your costs forward, waste and all.

Let me walk through both.

The two clocks, and what the dates actually mean

There are two separate timers, and people confuse them constantly.

The first is the support clock. Base support for Maximo 7.6.1.x ended September 30, 2025. You can buy Extended Support through September 30, 2026, and Sustained Support after that runs to 2030. Sustained is not a destination. It is a parking spot with a meter. You pay a premium for shrinking coverage, you get existing fixes and how-to help, and you do not get new security fixes or new functionality. IBM has been clear that the path forward for every Maximo EAM customer is to trade up to MAS. This is the universal clock, and it applies to every shop still on 7.6 no matter who you are.

The second is the licensing clock, and this is the one that costs you real money if you sleep through it. You can trade your old user-based licenses up to MAS AppPoints and keep running 7.6.1.x under what IBM calls dual entitlement until April 30, 2027. That window is the cheap door. Trade up while it is open and your move is orderly. Miss it and you may lose the favorable trade-up path, which can leave you looking at net-new AppPoint pricing instead of converting what you already own.

Brock Industries · Reference

The MAS Migration Timeline

Two clocks are running on every shop still on Maximo 7.6.1.x. Here is what each date actually means, and which one costs you money.

---

These dates come from IBM announcements and can change. Confirm the current dates with IBM before you make a decision. There is a standalone version of this timeline you can bookmark and share.

If you run in a regulated industry, there is a layer on top of all this. Unsupported software is a compliance exposure on its own, separate from whether IBM will answer the phone. Depending on the organization, utilities, transit, healthcare, and other regulated shops may also carry ISO, NERC CIP, FDA, internal audit, cyber, or contractual expectations that get harder to defend on software the vendor no longer patches.

And if you are federal, there is now a third date. MAS as a Service for Government reached FedRAMP Moderate Authorization in late April 2026, running on AWS GovCloud. IBM's own announcement says existing FedRAMP environments are required to move to MAS SaaS for Government by the end of 2027. That is not a recommendation. If you are running an existing FedRAMP Maximo environment, your timeline just got specific.

Support, trade-up, and subscription specifics are governed by IBM's current terms and can change. Confirm the details with IBM or your reseller before you act on them.

Here is the objection I expect, because I have it too. We have heard "migrate now" for three years and nothing happened. You were right to tune out the noise. The difference now is that the dates sit inside a normal budget cycle and a normal project timeline, the cheapest path has a hard close in April 2027, and for federal and regulated shops the compliance overlay is real. The alarm cried wolf for a while. The wolf has a calendar now.

The trap nobody selling you a migration will mention

Most migration vendors sell you a move, not a fix. They take what you have, stand it up in MAS, and call it done. It feels safe because nothing about how your people work changes. It is also the most expensive thing you can do, and the reason is structural.

In classic Maximo, a license was a seat. You bought a number of users. Security groups controlled what people could touch, but your security design and your license count were two separate conversations. You could let groups sprawl for ten years and it never showed up on the license invoice.

MAS does not let you keep those conversations separate.

Your security model is your license bill

In MAS, AppPoints are consumed based on a user's tier and access, and the tier is set by security. The security group itself carries a setting, the License impact value on the group, that assigns its MAS tier: Premium, Base, Limited, Self-Service, and so on. Put a user in a group mapped to Premium and you have designed them as a Premium user. Whether they ever use that access or not, your model is now sized around Premium entitlement.

Sit with what that means for a lift-and-shift. Every over-entitled user, every "just give them admin so they stop calling me," every group that quietly accreted access over a decade, stops being a harmless convenience and becomes a line item you pay for every year. You are not just porting access. You are locking in a bill.

I will name the setting once so you know this is real and not me hand-waving. The License impact value lives on the security group itself. That is the whole point of the thesis. Your group design is your invoice. You cannot size what you will pay in MAS without designing access, and you cannot design access intelligently without knowing the AppPoint consequence of each choice.

Why the migration window is the opportunity, not just the threat

Here is the part I actually want you to take away. The one time it is cheap to fix access design is while you are already touching everything.

You are going to rebuild groups, remap users, and validate access during the migration no matter what. That is the moment to right-size, by deciding each role's tier based on what the role actually does, not on what its old group happened to allow. Do it then and it is part of work you are already doing. Do it after go-live and every correction is a change-control ticket, and every over-licensed user is a sunk annual cost you chose to keep.

And the cost is stickier than a ticket, because of how you buy AppPoints. You do not buy them one at a time as you need them. You buy a pool, a fixed number. Under the subscription term model that IBM steers customers toward, you commit to that pool for the length of the term. The minimum is 12 months and the maximum is 60, and in my experience most shops sign for three years or more to get the better pricing. You agree to pay for the full term, and you cannot shrink what you committed to until it renews. You can grow into the pool and add more if you run short, but you do not get to give back the AppPoints you over-bought. So if you size your pool off a bloated lift-and-shift role model, then realize later that half your Premium users only ever needed Limited, you are not fixing that next quarter. You are living with it until renewal, paying for the gap the whole way.

That is why right-sizing before you sign is worth real effort. Get it right and the savings compound across the whole term. Get it wrong and you have locked in the overpayment for years.

Rebuild, do not port. The migration is the cheapest chance you will ever get to make access match reality, and the contract you sign at the end of it will hold that decision in place for a long time.

So what do you do first

You do not need AppPoint math yet. You need one honest artifact before you talk to any vendor: an inventory of who does what, by role, not who has what access today. Access-as-configured is the thing you are trying to escape. Role-as-performed is the thing you actually want to license.

It is not complicated to start. List your roles. For each one, write down what that person actually does in Maximo in a normal week. Planner, storeroom clerk, supervisor, reliability engineer, the executive who opens a dashboard once a month. That list is the input to every sizing and security decision that follows, and it is the one piece no vendor can hand you, because they do not know your shop. You do.

Get that on paper and you have turned a vague deadline into a plan you control, and into the one thing worth bringing to the table before you sign a multi-year contract.

Start with a MAS Role and Access Inventory, a simple worksheet that walks you through listing your roles by what people actually do, which is the one honest input you need before anyone sizes AppPoints or sells you a migration. (That worksheet is on its way to the downloads here; in the meantime the Estimator below covers the same ground.)

Once you have your roles down, the free AppPoints Estimator turns those numbers into a ballpark, so you can walk into the budget conversation with something real.

When you are ready to rebuild rather than port, the Maximo Right-Sizing Workshop and Playbook walk the full process, from designing the target role model through sizing AppPoints against it and rebuilding security in MAS instead of porting it forward.

Frequently Asked Questions

Is the Maximo 7.6.1.x migration deadline real this time?

There are two real dates. Base support for Maximo 7.6.1.x ended September 30, 2025, and the window to trade existing licenses up to MAS AppPoints under dual entitlement closes April 30, 2027. Extended Support runs to September 30, 2026 and Sustained Support to 2030, but those are paid holding patterns with shrinking scope and no new fixes. Confirm current dates with IBM before you act.

What does it mean that the security model is the license bill in MAS?

In MAS, AppPoint consumption is set by a user's tier, and the tier is set by the security group through its License impact value. Put users in a group mapped to Premium and you have designed them as Premium users whether they ever use that access or not. Your group design determines your annual AppPoint bill.

Why is a lift-and-shift migration the expensive option?

Porting your existing access model forward locks in every over-entitled user as a recurring AppPoint cost. You buy AppPoints as a pool committed for a multi-year term, and you cannot give back what you over-bought until renewal, so an oversized role model sized off a lift-and-shift becomes an overpayment you carry for years.

What should I do first, before talking to a migration vendor?

Build one honest artifact: an inventory of who does what by role, based on what people actually do in Maximo in a normal week, not the access they happen to have today. That role-as-performed list is the input to every sizing and security decision, and it is the one piece no vendor can hand you because they do not know your shop.

When this is not enough. A clocks-and-inventory read is enough to start the conversation and protect the trade-up window. If you are weighing a multi-year pool commitment across many sites, or the access cleanup is going to be contested, that is a Workshop to set the targets and a Playbook to execute, not a deadline-week spreadsheet.

Related reading. For why you rebuild security during the move instead of porting it forward, see Rebuild Your Security Model During the MAS Migration. For how to size the AppPoints once you have the roles, see How to Size MAS AppPoints Without Overpaying. For what to do with the points a clean model frees up, see Freeing Up AppPoints Is Not Automatically Savings. And for why a high quote is usually the model and not the vendor, see Your MAS Quote Is Probably Right, the Model Behind It Is Not.

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