Just finished a six-month migration from a legacy, on-premise CRM to a certain popular cloud-based platform, and I’ve emerged with the distinct impression that their vaunted “seamless data migration” tools were designed by people who have never actually had to operate the system afterward. The data itself is mostly there, which I suppose is the baseline for success, but the entire user permission model is a catastrophic, unusable jumble.
Our old system had a relatively sane role-based structure: Sales Agent, Sales Manager, Admin, Read-Only Auditor. Simple. The import process, following the new platform’s official guide, seemed to go smoothly. It created users and, as instructed, “mapped” the old roles to new “profiles” and “permission sets.” The result? Every user is now a de facto system administrator. The junior sales agent can modify global email templates, and the read-only auditor can delete custom objects. It’s a FinOps nightmare waiting to happen, not to mention a compliance auditor’s fever dream.
The root cause appears to be that the migration utility only concerned itself with the *existence* of a profile with a similar name, not with the actual permissions contained within. So “Sales Manager” mapped to “Sales Manager,” but the target system’s “Sales Manager” profile has a wildly different, and far more permissive, set of object and field-level permissions. The guide’s advice was essentially “review and adjust permissions post-migration,” which is like saying “after you pour concrete, just adjust the foundation.”
What I need is a systematic, programmatic approach to audit and rebuild this mess. Manually clicking through hundreds of permission settings in a web UI isn’t an option. I’m looking at the new platform’s APIs and considering writing a reconciliation script, but I’m wary of building another fragile tool.
Has anyone else been through this particular circle of migration hell and devised a sane process? Specifically:
- How did you perform a diff between the intended permission model from the old system and the actual state in the new one?
- Did you use the target platform’s metadata API to export profile/permission set definitions, or something else?
- Is there a practical way to “lock down” all users to a baseline and then re-apply correct permissions in an automated fashion, or is it a user-by-user salvage operation?
For context, we’re on the new platform’s Enterprise tier. Here’s a trivial example of the kind of profile XML I’m staring at, trying to figure out how to transform at scale:
```xml
true
ModifyAllData
true
true
true
true
```
I have a sinking feeling the answer is “you must now manually define your entire security model from scratch in the new system and assign users,” which would mean the migration project is only half done. Please tell me I’m wrong.
-- Cam
Trust but verify.
That's a classic failure mode of migration tools that treat permission mapping as a simple string-matching exercise. The system sees "Sales Manager" in the source and assigns any profile containing "Manager," without validating the underlying object and field-level permissions.
You'll need to rebuild the permission model from first principles. Start by exporting the effective permissions for a sample user from your old system, if logs exist, to create a baseline. Then, in the new platform, construct the correct profiles and permission sets manually, ignoring the imported ones. Treat the migration as having only successfully imported user identities, not their roles.
A post-migration audit script is now essential. I'd run a query to list all users and their assigned profiles/permission sets, then cross-reference that with a table of intended access levels. Without that, you're flying blind.
Data > opinions
Ugh, I've seen this exact scenario. The string-matching logic for profiles is hilariously bad - it's like they just do a case-insensitive `contains()` on the title and call it a day. One time, our "Support Lead" role got matched to a "Lead Conversion" profile because they both had "Lead." Chaos.
What's wild is that the data import worked, but permissions are the one layer where you can't afford fuzzy logic. It's a binary, security-critical mapping. I think user621 is right about rebuilding from scratch, but before you do that, disable all user logins via a login flow or auth policy if you can. That'll freeze the system while you sort out the profiles.
Also, check if your audit logs captured the pre-migration effective permissions. Some legacy CRMs have a "permission export" hidden in the admin console. That's your gold standard for rebuilding the new profiles, not the broken mapping the tool gave you.
Exactly. The `contains()` approach to permissions is a form of technical debt disguised as a feature. It saves the vendor from building a proper mapping UI.
Your "Support Lead" to "Lead Conversion" story is perfect. I'd bet money the migration tool also grants every imported user the "View All Data" permission by default, because that's the lazy way to ensure the data "works" post-import. Suddenly your read-only auditors can delete accounts.
Before you even look at the audit logs, lock it down. But also check if the new platform has permission assignment rules or groups. Sometimes you can bulk-strip the botched profiles and assign correct ones with a single CSV update, which is faster than rebuilding each profile from zero.
That "similar name" matching is the cost-cutting measure nobody budgets for. The tool avoids building a real permission matrix, so you're left holding the bag.
Start with damage control: immediately revoke "Modify All Data" and "View All Data" system permissions from all standard profiles via a metadata API script. That'll stop the bleeding while you rebuild.
Your old roles are simple, so rebuild them as permission set groups, not just profiles. Assign Sales Agent base permissions, then stack Manager and Auditor sets on top. It's cleaner for the next audit.
Show me the bill