Rebuild Your Security Model During the MAS Migration, Don't Port It

The easy answer, the one most vendors will quietly steer you toward, is to bring them across as they are. Lift them up, set them down in MAS, change nothing. It feels safe. It is the most expensive thing you can do, and the migration is the one moment when doing it right is actually cheap. This is how to rebuild instead of port.

Why porting is the expensive choice

Your current security model is not a clean design. It is ten years of accumulation. Groups that were created for one person and never retired. Access granted in a hurry so someone would stop calling. Data restrictions that protect nothing because the group that carries them is empty. Service accounts with insert and delete on everything that nobody remembers creating. None of that is unusual. It is the normal state of a system that has been live for a decade, and it is exactly what you are trying to get away from.

Port it forward and you carry every bit of that into MAS, where it costs more than it used to. In MAS your access design is your license bill, so the over-entitlement you tolerated for free under user-based licensing becomes a recurring charge in an AppPoint pool you commit to for years. The mess does not just survive the migration. It gets metered.

And the "we will clean it up after go-live" plan is a trap. After go-live, every change is a change-control ticket, every access you try to remove starts a fight, and the oversized license pool is already bought. The cleanup that was free during the rebuild becomes a project nobody funds. So later never comes, and you live with the ported mess for the length of the contract.

Here is the thing. You are going to touch every group, every user, and every authorization during the migration no matter what. That is the work. The only question is whether you rebuild while you are in there or copy the old model and lock it in. Rebuilding is two phases: get the truth about what you have, then design what you actually want.

First, get the truth about what you have

You cannot rebuild on top of a current state nobody understands, and almost everyone is carrying a current state nobody fully understands. So before you design anything, inventory it. Not group by group, the way the system stores it, but the way people actually experience it.

Nobody experiences security as a group. They experience it as the set of things they can do, which is the combination of every group they are in. So the inventory that matters is effective access per user: for each person, every app and action they can reach through any group they hold. That view is where the surprises live. The user who is in nine groups and can reach half the system because the groups stack. The service account with delete on everything. The manager who has had Premium for three years and opens one base app. You will not see any of that looking at groups one at a time. You see it when you roll the combination up per user.

Alongside the access picture, capture two more things. Your license footprint, what you consume today by tier, because that is the before number for the whole migration. And login activity, because granted access and used access are not the same thing, and you are paying for granted. Find the last time each person actually logged in, and the dormant licenses surface immediately.

When you go through the light users, do not sweep them all into the cheapest box. Three different situations look identical in the login data and they do not land in the same place. Some people do not need to log in at all. If someone only consumes a report, you can often deliver it by email or a dashboard somebody else maintains, and they come off the user count entirely. Some are genuine self-service users, whose whole interaction is raising and tracking their own requests, and they belong on the zero-cost Self-Service tier. And some do light but real work in a couple of applications, which still needs a license, just a lower tier. A person who logs in once a quarter to look at a report is not automatically self-service, because viewing a report is not the same as needing the self-service applications. Sort the light users by what they actually need to do, because each kind lands differently.

One discipline here, and it is hard to hold. You are taking a picture, not editing it. The inventory will surface obvious junk and you will want to fix it on the spot. Write the junk down and keep inventorying. You design better when you can see the whole current state at once than when you are fixing it one surprise at a time. And do not exit this step on a feeling that you have looked at enough. Exit it when you can show any active user's access, cost, and last login, the totals reconcile against what you believe you are running, and the people who own security and licensing have both read the baseline and agree it is accurate. A baseline only one person has seen is not a baseline. It is one person's notes.

Design roles from job functions, not groups and not people

Now you design the model you actually want, and it starts with roles, not groups. A role is a job function described in the language of the work: a storeroom clerk, a planner, a service tech, a reliability engineer, a supervisor. It is what a person does, written down before you touch a single Maximo screen. Get the roles right and the groups almost build themselves.

Derive roles from real job functions, not from the current group list and not from individual people. Sit with the supervisors, ask what their people actually do, and group the work into a manageable set of distinct functions. Most maintenance organizations land somewhere between eight and twenty roles. If you are deriving fifty, you are describing people, not functions. If you are deriving three, you are painting so broad that you will overgrant access to make the wide roles work.

Watch for the trap, because it is group sprawl wearing a different hat: do not define a role per person. The moment you have a role called Dave and a role called Maria, you are modeling individuals, and individuals change jobs, leave, and get covered by someone else. Roles outlive people. Dave is a planner. Maria is a planner. They share the planner role. If Dave also approves requisitions and Maria does not, that is not a reason for a Dave role. It is a reason for a separate approver role that Dave also holds.

That composition is what keeps the count down. You will have a handful of base roles for the core job functions, and a smaller set of add-on roles for capabilities only some people in a function have: approval authority, a configuration capability, a reporting capability. A person gets one base role plus whatever add-ons their actual job requires. That is how you cover a complicated organization with twenty roles instead of two hundred groups. People are unions of roles. Keep the roles clean and let people accumulate the ones they need.

Map roles to least access, and build up instead of paring down

With roles defined, map each one to the applications and actions it needs, and govern every decision by one principle: least access. Grant a role the minimum it needs to do its job and nothing more.

I know the easy path is to copy a broad existing group and trim it later. Resist it. Start each role from nothing and add only what the job requires. It is far easier to add an app a role turns out to need than to take away an app a role should never have had, because taking away breaks someone's workflow and starts a fight. Build up, do not pare down.

Least access is not security paranoia. It is the discipline that protects you from the way access combines. When a person is in several groups, their access is the most permissive combination across all of them. So if you overgrant a base role, every person who holds that role carries the excess, and every add-on stacks on top of an already-too-wide base. Tight base roles keep the combination honest. Loose base roles make every downstream combination wider than you intended, and since the tier a role consumes is set by the most capable application it can open, a loose base role does not just widen access, it raises the bill for everyone in it. Sizing the AppPoints that fall out of these decisions is its own method, and I covered it in the AppPoints sizing article, so I will not repeat it here. The point for the rebuild is simpler: every app you grant a role is a capability and a potential cost, so grant deliberately.

One boundary worth naming. This step is about applications and actions, the first two layers of Maximo security. It is not where you scope records. The data-level work, like giving a tech access to only their own truck storeroom, gets designed when you build, and it has its own traps that deserve their own treatment. Here you decide which apps and actions each role gets.

Check segregation of duties across combinations

Before the role model closes, run it through one filter that has nothing to do with cost and everything to do with control: segregation of duties. No single person should be able to both perform and approve their own work, or hold a combination of capabilities that lets them act without a check. The classic conflicts in a maintenance and supply shop are familiar. The person who creates a purchase requisition should not also approve it. The person who receives material should not also adjust inventory balances. The person who enters a work order should not be the only one who can close it.

Because people are unions of roles, segregation of duties is a question about combinations, not single roles. A requester role is fine. An approver role is fine. The same person holding both on the same transactions is the conflict. The combination behavior that works against your data restrictions works against your controls in the same way: capabilities accumulate across the roles a person holds, and a conflict can appear only when two otherwise-reasonable roles land on one user. Check the combinations, not just the roles.

When you find a conflict you have three honest options. Split the duty across two people, which is the cleanest and the one auditors want to see. Where headcount genuinely will not allow a split, put a compensating control in place, a review step or an after-the-fact report, and document why the split is not possible. Or accept the risk explicitly, in writing, signed by someone with the authority to own it. What you do not do is leave it undocumented and hope no one asks. In a regulated shop an undocumented duty conflict is a finding waiting to happen.

Gate each phase before you move on

The discipline that keeps a rebuild honest is the gate. You do not move from inventory to design on a feeling. You move when the baseline is complete and both the security owner and the license owner have signed that it is accurate. You do not start building in MAS on a feeling either. You start when the target role model is complete: every active user assigned to a base role and any add-ons, every role mapped to its access under least access, tiers and access types decided on the merits, self-service and admin roles flagged, segregation of duties checked across combinations with every conflict split, controlled, or accepted in writing, and both owners signed on again.

Gates feel slow. They are the opposite. Every gap you carry past a gate becomes a rework cycle once it is in the system, and rework in a live MAS environment is far slower than an hour of sign-off was. The gate is how a junior can execute this and a senior can trust the result.

What good looks like

A rebuilt model is a small, clean set of roles, usually eight to twenty, built from job functions. Base roles are tight. Add-on roles carry the capabilities only some people need. People are assigned as unions of those roles, not modeled as individuals. Every role's access is the minimum its work requires, so the tier each role consumes falls out of the apps it can open rather than being chosen by title. Segregation of duties is resolved and documented. And you can point at any user and show what they can do, what they cost, and that the design was signed by the people who own security and licensing. If a vendor or an auditor challenges any of it, you answer with the baseline and the role model, not with a shrug.

Where to start

1. Build the effective-access-per-user view: what each person can actually do across all their groups. This is the truth you design against.
2. Pull your license footprint by tier and your login activity, and flag the dormant and light users.
3. List your roles from job functions, eight to twenty, and assign every active user a base role plus any add-ons.
4. Map each role to the minimum apps and actions it needs, starting from nothing and adding only what the job requires.
5. Check segregation of duties across the role combinations people actually hold, and resolve every conflict.
6. Gate it. Get the security owner and the license owner to sign the baseline, then the target model, before anything goes into MAS.

That sequence is the rebuild. Do it during the migration, while you are already touching everything, and it is part of the work instead of a project you have to fund later.

This article covers the design half of the rebuild. Turning the role model into a number is the companion job, and the AppPoints sizing article and the free AppPoints Estimator handle that. When you are ready to build the model in MAS, including the record-level scoping this article deliberately left for later, the Maximo Right-Sizing Playbook walks the full process from the signed baseline through the build and the validation gates.

Related reading. For why the migration clock makes this urgent, see Why the Maximo Migration Clock Is Real Now. For the three layers of Maximo security this rebuild reorganizes, see Maximo Security Is Three Layers, Not One. For sizing the AppPoints once the role model is built, see How to Size MAS AppPoints Without Overpaying. For the record-level scoping this article deliberately defers, see Give Your Techs Access to Only Their Own Truck.

When this is not enough. If your shop spans many sites and thousands of users, this method 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

Should I port my Maximo security groups into MAS or rebuild them?

Rebuild. Porting carries a decade of accumulated over-entitlement forward, and in MAS access design is the license bill, so the waste becomes a recurring AppPoint cost. You are touching every group, user, and authorization during the migration anyway, so rebuilding is part of work you are already doing rather than a project you fund later.

What do I inventory before redesigning Maximo security for MAS?

Effective access per user, which is what each person can do combined across every group they hold, plus your license footprint by tier, login activity per user, existing data restrictions, and site reach per group. The surprises live in the per-user combination, not in the groups looked at one at a time.

How many security roles should a rebuilt Maximo model have?

Most maintenance organizations land between eight and twenty roles derived from job functions. If you are deriving fifty you are modeling people, not functions; if you are deriving three you are painting so broad you will overgrant. Use a handful of tight base roles plus add-on roles for capabilities only some people in a function have.

What is least access and why does it matter in MAS?

Least access means granting a role the minimum apps and actions its job requires and nothing more, building up from nothing rather than trimming a broad group. It matters because access combines toward the most permissive, and the tier a role consumes is set by the most capable app it can open, so a loose base role both widens access and raises the AppPoint bill for everyone in it.

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