Security Settings should Not be Automatically Transferred
Universal Migrator intentionally does not migrate security settings between systems.
The following are a few reasons why Universal Migrator does not transfer security settings between systems.
Security Settings are not Universal between Applications
If you look at how each system implements security settings, it will vary.
- Is security applied on a per-document, per-folder, or per-matter basis? How does inheritance work?
- What about security related to other record types like contacts, invoices, or financial settings?
- Does security authorize groups, users, or something else?
- How do security settings interact with internal/external users?
- What security attributes are available in each system?
- Read / Write / View / Edit / Administer
Aligning these settings between only two different systems would be really difficult - and Universal Migrator supports many, many different systems.
Security Settings Drift
If you were to interview clients about how they *think* their security settings are implemented and then audit those settings, you will always find that the settings have drifted significantly. This is because, as time goes on, exceptions get made, temporary exceptions accidently become permanent, and customized permissions are never audited or removed.
After a migration is the perfect time to reapply customized security settings and restore them back to their desired values.
Manually Transferring Security Settings
If your client requires customized security settings, these should be applied after the migration is complete using methods outside the scope of Universal Migrator.