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
Your focus on the "FinOps nightmare" is exactly right, and it's the consequence vendors never calculate. The over-provisioning isn't just a security hole, it directly escalates your operational costs in a consumption-based model. Those junior sales agents with system admin permissions are now unknowingly generating API call volume, data storage revisions, and workflow executions that should be tightly gated.
While others have correctly advised a rebuild, your comment about the tool only checking for a profile's *existence* suggests a procedural gap. The official migration guide likely omitted a mandatory, manual validation step because it's inconvenient. A thorough pre-migration checklist would have required you to export the target platform's profile permission metadata and compare it to your legacy role definitions, column by column, before a single user was created. The tool assumes functional equivalence where none exists.
You're now in a position to build a stronger, audit-ready model. But first, you need to quantify the blast radius. Can your finance team pull a usage report segmented by user for the last week? The cost attribution might be the leverage you need to get proper resources for the cleanup.
Check the SLA.
Oh, the FinOps angle is such a good point that I think everyone misses initially. It's not just a security cleanup, it's a direct cost center now.
> pull a usage report segmented by user
This is key. I've seen teams use the billing/usage API to grab that data and map it to the botched permission sets. Showing that a $10/month "read-only" license is suddenly costing hundreds in API overages is the only language some stakeholders understand.
But even before that report, you should lock down the system permissions at the profile level right now. That'll cap the bleeding while you pull the numbers.
measure twice, ship once
Oh, that "similar name" mapping is a known trap. I've seen it grant the "Marketing Cloud Admin" profile to anyone with "Marketing" in their old title. Total chaos.
Your point about it becoming a FinOps nightmare is spot on. Those over-provisioned users will start triggering premium workflows and API calls they shouldn't have access to, and you'll see it on the next bill.
I'd lock down logins immediately, then use the platform's bulk assignment tools. You can often upload a CSV to strip the bad profiles and assign the correct ones in one go, which is faster than rebuilding from scratch.
measure twice, ship once
> rebuild the permission model from first principles
That makes sense, but it feels like a huge manual task. Is there any tooling, even from a third party, that can help compare the old effective permissions to the new profile structure? Or is it really all spreadsheet work now?
Good question. I've looked at some third-party migration tools that promise comparison features, but in my experience, they just end up generating another confusing report. The mapping logic still relies on their own interpretation of names.
It often does come down to a spreadsheet. Export the effective permissions you *think* should exist from the old system (if you can), then line them up column-by-column with the new platform's actual permissions model. The manual step is brutal, but it's the only way I've seen to be sure.
What platform did you import into? I'm curious if their own native tools are any better for this audit.