To move shared company files to the cloud without losing access permissions, plan the migration around the way people actually use the files, not just the folder structure. Document who needs access, how that access is granted, and what should happen when the files reach the destination. Then test those expectations with representative accounts before and after cutover.
Permission settings do not always transfer exactly as they work on a local file share. The destination platform, identity mapping, and types of rules in use can all affect the result. Microsoft’s guidance on permissions when using the SharePoint Migration Tool is one example of why it is important to check the behavior of the specific migration path you plan to use.
Start with an inventory of folders and owners
Before moving data, build an inventory that explains what each shared area is for and who is responsible for it. A folder list alone is not enough. Include the business owner, the teams that use the content, whether access is read-only or editable, and any external sharing that is intentional.
- Record the main folders and important subfolders.
- Identify the business owner and the groups or roles that use each area.
- Note folders with unique permissions that differ from their parent folder.
- Flag inherited permissions, nested groups, explicit deny rules, and other exceptions for review.
- Mark stale accounts, broad groups, and content that may no longer need to be shared.
Pay special attention to exceptions. A folder that inherits access from its parent behaves differently from one with its own rules. If an exception is undocumented, it can be easy to miss during migration or to preserve without understanding why it exists.
Use this review to decide whether old permissions are still appropriate. Remove access that is no longer needed only after confirming with the relevant owner. If an unusual rule must remain, document its purpose and who should have access so it can be checked after the move.
Map users and groups to cloud identities
Next, connect the people and groups on the existing file share to the identities that will be used in the cloud. Confirm that employees who need access have the right destination accounts, and identify groups that need to be recreated, renamed, or mapped to an equivalent cloud group.
Do not assume that a group with a familiar name contains the same people in both places. Check membership, nested groups, and ownership. If an account is inactive or cannot be matched to a current identity, resolve that before the migration rather than letting an unclear permission carry over unnoticed.
Also check how the destination handles the permission types in use. For example, a source file share may rely on NTFS permissions, while a cloud service may represent access through a different permission model. SharePoint, OneDrive, and cloud file storage do not necessarily behave alike. Review the documentation for the particular destination and migration tool; Microsoft’s file-share migration guide describes the SharePoint, Teams, and OneDrive context.
Be especially careful with explicit deny rules, nested groups, and unique folder permissions. Do not assume they will have an identical effect after migration. Record what each rule is intended to accomplish, confirm how the destination handles it, and plan a replacement access rule if needed.
Run a pilot before moving everything
A pilot lets you test the migration approach on a representative set of files before relying on it for the full share. Choose a sample that includes ordinary folders as well as cases with inherited access, unique permissions, nested groups, or external collaborators. Include files used in everyday work so the pilot can reveal practical access issues.
Agree on expected access before the test. A simple permission matrix helps make the results clear:
- Read-only user: Can open the intended files but cannot edit them.
- Editor: Can make the changes required for their role.
- Group member: Receives the intended access through the correct group.
- External collaborator: Can access only the content intentionally shared with them.
- Unauthorized user: Cannot open folders or files outside their approved access.
Test with representative accounts, not only an administrator account. Administrative access can conceal problems that ordinary users would encounter. Compare what each account can do in the destination with the expected result in the matrix, and record any differences for correction before the wider move.
If the pilot exposes confusing or overly broad access, pause and fix the source rules or revise the destination mapping. The aim is not simply to reproduce every old setting. It is to carry forward the access people need while addressing outdated or unclear permissions.
Verify permissions after cutover
After the main migration, repeat the access checks against the live destination. Ask folder owners and representative users to confirm that they can reach the files they need and that they cannot reach areas outside their role. Include read-only users, editors, groups, external collaborators, and users who should be denied access.
Review folders with unique permissions and documented exceptions first. Check group membership and inherited access, then investigate unexpected access or denied access against the migration record. Keep a list of issues, the affected folders, and the person responsible for confirming the correction.
Do not treat a successful file copy as proof that permissions are correct. File transfer and access verification are separate checks. Keep the old share available during the agreed transition, if your migration plan allows it, and communicate which location users should work from so teams do not create competing versions.
For organizations considering broader cloud changes, Zevonix also has guidance on choosing which workloads to move first and planning a cloud migration cost estimate. Those topics can help shape the wider project, while permission planning remains specific to the files and people involved.
Frequently asked questions
Do NTFS permissions transfer exactly to cloud storage?
Not necessarily. The result depends on the destination platform, migration method, identity mapping, and permission types involved. Check the documentation for your specific migration path and validate access in a pilot.
Should we simplify old file-share permissions before migrating?
Review them before the move. Remove stale access or simplify rules only when the responsible owner confirms the change. Document exceptions that need to remain and verify them after migration.
How should explicit deny permissions and nested groups be handled?
Identify and document them during the inventory. Confirm how the destination handles each rule and test the outcome with representative accounts. If the rule cannot be carried over as intended, define and test an appropriate alternative before cutover.
What is the most useful way to check access after migration?
Test with real, representative account types against an agreed permission matrix. Confirm both that authorized users can do their work and that users without permission are blocked.
Make permission checks part of the migration plan
A deliberate inventory, identity map, pilot, and post-migration review can reduce surprises and give file owners a clear way to confirm access. If your business is planning a shared-file move and wants help reviewing the IT work involved, contact Zevonix at (904) 658-0777.