If you’ve been putting off the Profile-to-Permission-Set-Group migration, you’re not alone. Most orgs I walk into still have Profiles doing real work — controlling object access, page layouts, login hours, the whole tangle. The good news: Salesforce has been clear about the direction. The better news: the migration isn’t as scary as it looks if you do it in stages.

Here’s the framework I’ve used on a half-dozen migrations.

From Profiles to Permission Set GroupsOld: ProfileObject permissionsField permissionsApp accessTabs & record typesUser permissionsAll bundled togetherMinimum-Access ProfilePermission Set Group(role-based bundle)Permission SetPermission SetProfiles become thin shells. Permission logic moves to composable groups.

Why this migration matters

The Profile model was built when Salesforce was a much simpler product. One Profile per user, all permissions bundled inside. As orgs grew, that turned into Profile sprawl: 40 Profiles, half of them differing by a single permission, nobody sure who needs what.

Permission Set Groups solve that by letting you compose access from reusable building blocks. A user gets the Minimum Access Profile (almost nothing), then you layer Permission Set Groups on top based on what they actually do: Sales Rep, Renewal Rep, Sales Manager.

The migration in five stages

1. Audit what you have. Pull every Profile in the org, list which users are on it, and document the permissions that actually matter. Most orgs find that 80% of their Profiles can collapse into 4–6 access patterns.
2. Define your access patterns as Permission Set Groups. Think in terms of job functions: Sales Rep, Sales Manager, Service Agent, Marketing User. Each group bundles the Permission Sets that role needs.
3. Build the Permission Sets. Granular by purpose: “Account — Read/Edit,” “Opportunity — Convert,” “Reports — Build.” Avoid building Permission Sets that mirror a single Profile.
4. Migrate users in cohorts. Pick a small group (10–20 users), assign them the Minimum Access Profile plus the new Permission Set Group, and watch for breakage for a week. Repeat with the next cohort.
5. Decommission old Profiles. Once nobody is assigned to them, archive them. Don’t delete — keep them around for a release cycle in case you need to reference what they used to grant.

Pitfalls I keep seeing

• Mirroring Profiles 1:1 in Permission Set Groups. If your new “Sales Rep” group is just a copy of the old Sales Rep Profile, you haven’t simplified anything. Break it apart by capability, not job title.
• Forgetting login hours, IP ranges, password policies. Those still live on Profiles. Your Minimum Access Profile is doing real work — don’t leave it default.
• Assigning Permission Sets directly instead of grouping them. One-off assignments are fine for exceptions; everything else should flow through a Group. Otherwise you’re re-creating Profile sprawl in a new costume.
• Not testing record type and page layout assignments. Those move to Permission Sets too, and they’re the most common source of “why can’t this user see the field anymore” tickets.

A small first step

If a full migration feels like too much right now, start with new hires. From the next person onboarded, give them the Minimum Access Profile plus a Permission Set Group. You’ll learn the patterns on a small population before you touch your existing 200 users.

The migration is real work, but it’s the kind of investment that pays back the first time someone asks “can you give Sarah the same access as Mike” and you can answer in 30 seconds instead of an afternoon.