Why Every Salesforce Org Needs to Plan a Permission Set Migration

Your Salesforce org's security model is built on profiles. It has been since the day you went live. And for years, that worked well enough.

But the ground has shifted. Salesforce is moving its entire security architecture toward permission sets and permission set groups. Recent releases have shipped zero new profile features. Every platform investment — new object permissions, field-level security enhancements, muting permission sets for exception handling — lands exclusively on the permission set side.

The hard deadline for profile deprecation that Salesforce originally announced? Salesforce removed it. But dropping the deadline did not reverse the direction. If anything, it made the problem worse — teams that were finally starting to plan lost their urgency trigger while the platform kept pulling further away from profiles.

Whether your org migrates this quarter or next year, the question is no longer "if." It is "how prepared are you when it happens?"

The Real Scope of Migration

Most Salesforce admins understand what permission sets are. The Trailhead modules are thorough. The help documentation is clear.

What catches teams off guard is the gap between understanding the concept and executing the migration in a real org with years of accumulated complexity.

Consider what a typical mid-market Salesforce org looks like after five or six years of operation. You have 15 to 30 profiles, many created ad hoc to handle edge cases that no longer exist. Some profiles have nearly identical field-level security settings with a handful of differences nobody can explain. Others grant access to objects and fields that were deprecated two releases ago. A few were cloned from each other so many times that the original intent is lost.

Now multiply that by every custom object, every record type, every page layout assignment, and every field-level security setting tied to those profiles. For a mid-complexity org, the manual effort to audit, map, and migrate that profile structure into a clean permission set model runs between 40 and 80 hours of focused admin time — and that estimate assumes you already know what every profile is supposed to do.

Most orgs do not have that documentation.

Why Teams Delay (and Why Delaying Gets More Expensive)

The most common reason organizations postpone permission set migration is straightforward: the scope feels overwhelming and the current model still works.

But "still works" masks a compounding problem. Every month you delay, the migration scope grows:

New users get added to existing profiles. Each new hire inherits whatever excess permissions that profile carries, expanding the blast radius of any security issue.

New custom objects and fields get built. Every new object requires field-level security settings on every profile it touches. If those profiles eventually need to become permission sets, each new object adds another row to the migration matrix.

Integrations multiply permission dependencies. API users, connected apps, and third-party integrations often rely on specific profile-based permissions. The more integrations you add while still on profiles, the more tightly coupled your migration becomes to external systems.

Permission set groups add a third layer. If your org has started using permission set groups alongside existing profiles — as many have, to take advantage of new features — you now have three overlapping permission models running simultaneously. The migration path gets harder to trace with every passing sprint.

This is not a linear problem. An org that waits 12 months to migrate is not facing 12 months more work. It is facing the cumulative complexity of everything added during that window, layered on top of the original debt.

The Security Cost of the Status Quo

Delayed migration is not just a technical debt problem. It is a security exposure.

Profiles grant permissions in broad strokes. An admin who needs to give a user access to one additional field on the Opportunity object has to either modify the entire profile (affecting every user assigned to it) or create a new profile (adding to the sprawl). In practice, most admins choose the faster option: modify the profile. Over time, this creates a pattern where users accumulate permissions far beyond what their role requires.

This is the over-permissioning problem, and it is pervasive. The average Salesforce org carries significantly more permission grants than its users need. When security teams audit these environments, they routinely find users with access to objects and fields they have never opened — and in regulated industries, that finding triggers formal remediation.

Here is what over-permissioning looks like in practice:

Audit exposure. SOC 2, HIPAA, and SOX audits require demonstrable least-privilege access. Profile-based models make it nearly impossible to prove that each user has only the access they need. Auditors see profiles with 200+ field-level security grants and ask how many of those the assigned users actually require. If you cannot answer precisely, you have a finding.

Data breach amplification. If a single user account is compromised, the attacker inherits every permission that user's profile grants. In over-permissioned orgs, that can mean access to financial records, customer PII, or protected health information that the compromised user never actually touched in their day-to-day work.

Compliance drift. Without granular permission controls, keeping up with evolving regulatory requirements means constantly patching profiles — which affects all users on that profile, including ones who should not be changed. Permission sets solve this by allowing additive, user-specific grants without the blast-radius problem.

Patterns We See in Successful Migrations

The organizations that handle this well share a few common patterns. None of them try to migrate everything at once. And none of them treat it as purely a technical exercise.

Start with a permission audit, not a migration project. Before you move anything, understand what you have. Document every profile, the users assigned to it, and the specific permissions it grants. Identify which profiles are functionally identical, which carry excess permissions, and which serve a clear, current business purpose. This audit is the foundation — skip it and your permission sets will inherit the same problems your profiles have.

Identify your highest-risk profiles first. Not all profiles are equal. Profiles assigned to users who handle sensitive data (financial records, customer PII, healthcare information) or who have broad system access (System Administrator clones) should migrate first. These are the profiles where the security benefit of permission sets is immediate and measurable.

Design permission sets around roles, not profiles. The temptation is to do a one-to-one conversion: one profile becomes one permission set. This is fast but misses the point. Permission sets work best when they map to job functions — "Sales Rep Access," "Finance Read-Only," "Support Case Manager" — not to the legacy profile names that accumulated organically over years.

Plan for permission set groups. Salesforce introduced permission set groups specifically to address the management overhead of assigning multiple individual permission sets. Your migration plan should account for grouping related permission sets from the start, rather than adding groups as an afterthought.

Test with a rollback path. Migrate one profile at a time. Assign the new permission sets to a subset of users. Verify that access is correct. Keep the original profile available as a fallback until the new model is validated. A phased approach takes longer but prevents the scenario where a migration error locks out an entire team mid-quarter.

Establish ongoing governance. Migration is not a one-time event. Once your org runs on permission sets, you need a process for creating, reviewing, and deprecating them as roles change. Without governance, permission sets will accumulate the same sprawl that profiles did — and you will be back where you started in two years.

The Role of Automation in Migration

Manual migration is viable for small orgs with fewer than ten profiles and limited customization. For anything larger, the question is not whether to automate but how much of the process you can automate safely.

The core migration steps — analyzing existing profiles, mapping permissions to new permission set structures, generating permission sets, and deploying them — are repetitive and rule-driven. Manual execution introduces errors in exactly this kind of work. Automation delivers consistency.

Automated tools can also surface insights that manual analysis misses: redundant permissions across profiles, unused permission grants, and conflicts between permission sets and profiles that would create security escalations rather than reductions.

When evaluating tools, prioritize ones that handle the complete lifecycle — not just the initial conversion, but the ongoing optimization that keeps your permission model clean over time.

Planning Starts Now

The permission set migration is one of those projects that rewards early planning disproportionately. The longer you wait, the more complex your org becomes, and the more scope the eventual migration carries.

You do not need to migrate everything tomorrow. But you do need a plan: an audit of your current state, a prioritized sequence, and a timeline that accounts for the security exposure you carry while profiles remain your primary model.

Salesforce has made its direction clear. Every new security feature, every platform enhancement, every governance capability is built for permission sets. Your org's security model needs to move in the same direction — and the organizations that move deliberately, with a plan, avoid the pain of forced migration under pressure.

If you are evaluating how to approach your migration, SimplePerm by Simplementix is building a free migration wizard that will analyze your current profile structure and generate permission set recommendations. Join the waitlist at simplementix.com/simpleperm to get notified when it launches.

For organizations that need hands-on consulting support for complex migrations, our team has guided dozens of clients through this transition. Explore our Salesforce services to see how we can help.

Related articles

SimplePerm vs. Manual Migration: Why Free Tools Beat Spreadsheets

We have seen teams spend three months on what should take an afternoon. Here is an honest comparison of the paths available for Salesforce permission set migration.

Read Article →

How AI-Powered Recommendations Eliminate Salesforce Over-Permissioning

Most Salesforce orgs do not discover they are over-permissioned until something forces the question. AI-powered analysis can identify and eliminate excessive permissions at scale.

Read Article →