Before You Copy File Share Permissions Into SharePoint, Review These 7 Things

Migrating file shares to SharePoint is rarely just a storage project.

It is usually a cleanup project, a governance project, a user adoption project, and a risk reduction project all at the same time.

One of the biggest mistakes I see during file share migrations is treating permissions like something that can simply be copied from the old network drive into SharePoint.

At first, that sounds safe.

The logic is understandable:

“Users already have access today, so let’s keep the same access after migration.”

But that approach can move years of permission sprawl into Microsoft 365.

Old temporary access, nested security groups, broken inheritance, former project members, contractor accounts, department-wide access, and unclear ownership can all follow the content into SharePoint. Once that content is in Microsoft 365, it becomes easier to search, easier to share, easier to sync, easier to surface in Microsoft 365 experiences, and more important to govern properly.

That matters even more for organizations preparing for Microsoft 365 Copilot.

Copilot does not create the permissions problem. It exposes the one that already exists.

If you are still deciding what should move at all, start with Before You Migrate File Shares to SharePoint: What IT Directors Should Decide First.

TL;DR

Before copying file share permissions into SharePoint, review these seven areas:

1. Business ownership and decision rights
2. Permission scope and group strategy
3. Broken inheritance and folder depth
4. Sensitive and regulated content
5. External sharing and guest access
6. ROT content, archival, and retention
7. Copilot readiness and search discoverability

The goal is not to perfectly recreate your network drive in SharePoint.

The goal is to translate old access into a cleaner, supportable Microsoft 365 governance model.

Table of Contents

• The real-world problem
• The technical insight
• 1. Business ownership and decision rights
• 2. Permission scope and group strategy
• 3. Broken inheritance and folder depth
• 4. Sensitive and regulated content
• 5. External sharing and guest access
• 6. ROT content, archival, and retention
• 7. Copilot readiness and search discoverability
• Business impact
• Recommendations
• Mistakes to avoid
• Final thoughts
• Useful Microsoft resources

The real-world problem

Most file shares were not designed all at once.

They grew over time.

A department needed a folder. A project team needed access. A contractor was added for three months. A manager requested an exception. A security group was reused because it was faster than creating a new one. Someone broke inheritance on a subfolder because one file was sensitive. Then the business changed, people moved roles, clients changed, projects closed, and the folder structure kept growing.

Years later, the file share may still work from a user perspective, but the permission model is often hard to explain.

Common issues include:

• Users with access because they were added years ago and never removed
• Nested Active Directory groups that no one fully understands
• Folder-level permissions that do not match the current business process
• Broken inheritance several levels deep
• Old project or client folders with no active owner
• Sensitive content mixed with general collaboration content
• Department-wide access where only a smaller team should have access
• Temporary vendor or contractor access that became permanent
• Disabled or stale accounts still appearing in reports
• No clear way to answer, “Who should own this after migration?”

When this permission model is copied directly into SharePoint, the risk does not disappear.

It becomes a Microsoft 365 governance problem.

SharePoint is better than a traditional file share for collaboration, search, versioning, sharing, retention, metadata, and integration with Microsoft 365. But those benefits depend on having a permission model that people can understand, maintain, and audit.

A messy file share permission model copied into SharePoint can create a messy SharePoint environment from day one.

The technical insight

File share permissions and SharePoint permissions are not the same thing.

A traditional file share usually depends on NTFS permissions, folder inheritance, Active Directory security groups, and direct access control lists. SharePoint Online uses a different model: sites, libraries, folders, files, SharePoint groups, Microsoft 365 groups, Microsoft Entra security groups, sharing links, guests, sensitivity labels, retention policies, search, and audit activity.

That difference matters.

A direct one-to-one migration of file share permissions can create several problems:

• Too many unique permissions in SharePoint
• Too much broken inheritance
• Too many direct user assignments
• Confusing site ownership
• Inconsistent access requests
• Poor user experience
• Harder support for help desk and admins
• Higher audit and compliance risk
• More exposure when content becomes searchable

SharePoint can support unique permissions, but that does not mean every old folder exception should become a SharePoint exception.

A better approach is to translate permissions into a cleaner access model:

• Use SharePoint sites to represent major business areas, departments, clients, projects, or security boundaries.
• Use libraries when content has different metadata, retention, sync, or process requirements.
• Use Microsoft 365 groups or Microsoft Entra security groups for maintainable access.
• Use SharePoint groups when Owners, Members, and Visitors make sense.
• Use folder-level or item-level permissions only when there is a strong business reason.
• Use sensitivity, retention, and data loss prevention where content requires additional controls.
• Use reporting and review processes to keep permissions clean after migration.

The goal is not to remove all complexity.

The goal is to make the complexity intentional.

1. Business ownership and decision rights

Before reviewing permissions, identify who can make decisions about the content.

This is not just an IT decision.

IT can generate reports, explain technical options, design the migration approach, and recommend a governance model. But the business needs to confirm who should own each content area and who should have access after migration.

What to review

For each major folder, department, client area, or project area, ask:

• Who owns this content today?
• Who should own it after migration?
• Who approves access requests?
• Who can confirm whether old permissions are still valid?
• Who is responsible for external sharing decisions?
• Who decides what should be archived, deleted, or migrated?
• Who will review permissions after migration?

If no one owns a folder, that is a migration risk.

Unowned content usually becomes ungoverned content.

Why it matters

Without clear ownership, the migration team usually defaults to copying what exists. That may reduce short-term debate, but it also preserves old risk.

From a business perspective, ownership supports:

• Accountability
• Audit readiness
• Faster access decisions
• Cleaner support processes
• Better adoption
• Better lifecycle management
• Reduced oversharing

Practical recommendation

Create a simple ownership matrix before migration.

Example:

Content Area	Current Owner	Future Site Owner	Access Approver	Sensitivity	Migration Action
Finance Shared Drive	Finance Director	Finance Operations Manager	Finance Director	High	Review permissions before migration
Client Projects	Client Services Director	Project Operations Lead	Engagement Manager	Medium/High	Split by client/project security model
HR Policies	HR Director	HR Communications Owner	HR Director	Medium	Move to communication site
Old Archives	Records Manager	Records Manager	Legal/Compliance	Varies	Archive or apply retention

This does not need to be complicated. It just needs to make decision rights visible.

2. Permission scope and group strategy

The next question is how access should be granted.

Copying individual users from a file share into SharePoint is usually a bad long-term strategy. It may work during testing, but it becomes painful to maintain when employees change roles, departments reorganize, or projects close.

What to review

Review the current permissions and classify them into patterns:

• Department access
• Leadership-only access
• Project team access
• Client-specific access
• Read-only access
• Contribute/edit access
• External partner access
• Temporary access
• Archive/read-only access
• Exception-based access

Then decide how each pattern should be represented in SharePoint.

Why it matters

A clean group strategy reduces support tickets and makes access easier to explain.

For example:

• “Finance Members can edit finance working documents.”
• “Finance Visitors can read published finance procedures.”
• “Client ABC Team can access Client ABC working files.”
• “Archived Projects Visitors can read closed project records.”

That is easier to manage than hundreds of direct user assignments across many folders.

Practical recommendation

Use groups wherever possible.

A practical model might include:

• SharePoint Owners for site administration and business ownership
• SharePoint Members for users who contribute content
• SharePoint Visitors for users who need read-only access
• Microsoft Entra security groups for role-based or department-based access
• Microsoft 365 groups where Teams-connected collaboration is required
• Separate security groups for sensitive areas that require tighter control

Avoid using direct user permissions unless there is a specific, documented reason.

Also avoid reusing broad legacy groups without reviewing membership. A group named “Finance” might sound safe, but it may include old users, service accounts, nested groups, or people who should not have access to migrated content.

3. Broken inheritance and folder depth

Broken inheritance is one of the most common file share migration problems.

A folder structure may look simple from the top level, but the real permission model can be hidden several levels deep.

For example:

Shared Drive
└── Clients
    └── Client A
        └── 2024
            └── Contracts
                └── Executive Review

The top-level folder may be open to a large team, but the Executive Review folder may have a special permission exception. Or the opposite may be true: a sensitive client folder may accidentally inherit broad access from a parent folder.

What to review

Look for:

• Deep folder structures
• Folders with unique permissions
• Folders that no longer inherit from the parent
• Sensitive folders under broad-access parent folders
• Folders with direct user assignments
• Folders with different permissions at multiple levels
• Folders where the permission name does not match the business purpose

Why it matters

If you migrate this structure exactly as-is, SharePoint can inherit the same complexity.

That can create:

• Confusing access behavior
• More help desk tickets
• More permission troubleshooting
• Slower migration validation
• Harder user training
• More risk during audits
• More difficult Copilot readiness reviews

SharePoint can handle unique permissions, but unique permissions should be the exception, not the default design pattern.

Practical recommendation

Treat broken inheritance as a decision point.

For every folder with unique permissions, ask:

• Is this exception still needed?
• Should this content become a separate SharePoint site?
• Should this content become a separate library?
• Should this content be protected with a different group?
• Should this content be archived instead of migrated?
• Is this exception caused by a real business requirement or old permission drift?

A migration is a good opportunity to reduce folder depth and simplify permission boundaries.

Do not waste that opportunity by recreating every exception without review.

4. Sensitive and regulated content

Not all files have the same risk.

A folder containing lunch menus, project notes, or general templates does not require the same controls as folders containing contracts, HR records, financial data, client information, legal documents, or regulated data.

What to review

Before migration, identify where sensitive content lives.

Examples include:

• HR files
• Payroll files
• Legal documents
• Financial reports
• Client contracts
• Personally identifiable information
• Health-related information
• Merger and acquisition documents
• Board materials
• Executive compensation files
• Security or incident response documents
• Vendor contracts
• Confidential project files

Then review whether the current access model matches the sensitivity of the content.

Why it matters

Sensitive content that was hidden deep in a file share may become easier to find in SharePoint and Microsoft 365 search experiences if the user already has permission to it.

That is not a SharePoint failure.

That is a permissions and governance failure.

The business impact can include:

• Data exposure
• Audit findings
• Compliance issues
• Legal risk
• Reputational damage
• Loss of client trust
• Emergency cleanup after migration
• Delayed Copilot rollout

Practical recommendation

Create a sensitive content review step before migration.

At minimum, classify content into simple categories:

Category	Example	Recommended Action
Public/internal general	Published policies, templates	Migrate with standard read access
Department working content	Team working files	Migrate to department/team site with group-based access
Sensitive business content	Financial, HR, legal, client files	Review permissions before migration
Regulated or high-risk content	Data subject to legal/compliance requirements	Coordinate with compliance, Purview, retention, labels, and DLP
Archive/records	Closed projects, historical files	Consider archive site, retention, or records strategy

If your organization uses Microsoft Purview, review whether sensitivity labels, retention labels, DLP policies, and audit requirements should be part of the migration design.

5. External sharing and guest access

External sharing is one of the biggest differences between a traditional internal file share and SharePoint Online.

A file share may have been mostly internal. SharePoint can support secure external collaboration, but that capability needs to be governed intentionally.

What to review

Before migration, identify:

• Which content should never be shared externally
• Which content can be shared with clients or vendors
• Which users are allowed to share externally
• Whether sharing should use specific people links only
• Whether anonymous or “Anyone” links are allowed
• Whether external users should expire after a period of time
• Who reviews guest access
• Whether guest access should be managed at the tenant, site, or group level
• How access should be removed when a project or engagement ends

Why it matters

External sharing can be extremely useful for client and partner collaboration.

But unmanaged external sharing creates risk.

If old file share permissions are copied into SharePoint without an external sharing model, users may start sharing from a structure that was never designed for external collaboration.

That can lead to:

• Files shared from the wrong site
• Client data shared with the wrong audience
• Guests remaining active after work ends
• Unclear ownership of external access
• Confusing sharing links
• Audit concerns
• Emergency access cleanup later

Practical recommendation

Define external sharing rules before migration.

For example:

• Finance and HR sites: external sharing disabled
• Client project sites: external sharing allowed only with specific people links
• Vendor collaboration sites: external sharing allowed with expiration and owner review
• Published intranet content: no external sharing
• Archive sites: no external sharing unless approved

Also train users on the difference between site access, group membership, direct access, and sharing links.

Many permission issues happen because users do not understand what kind of access they are granting.

6. ROT content, archival, and retention

ROT stands for redundant, obsolete, and trivial content.

Every file share migration has it.

The question is whether you identify it before migration or pay to move and govern it afterward.

What to review

Look for content that is:

• Duplicated across folders
• No longer used
• Owned by inactive teams
• Related to closed projects
• Past its business value
• Unclear in purpose
• Outside retention requirements
• Better suited for archive storage
• Not appropriate for SharePoint collaboration

Also review file age, last modified date, owner, path, size, file type, and business value.

Why it matters

Migrating ROT content increases cost and complexity.

It can also increase risk.

Old files may contain sensitive data, outdated business decisions, expired contracts, or information that users should not rely on anymore. If those files are moved into SharePoint without review, they may become easier to find and reuse.

From a business perspective, ROT cleanup supports:

• Lower migration volume
• Faster migration waves
• Cleaner search results
• Lower storage growth
• Better user adoption
• Better compliance posture
• Cleaner Copilot responses
• Less clutter for site owners

Practical recommendation

Do not make ROT cleanup an afterthought.

Create clear migration actions:

Action	Meaning
Migrate	Content is active and should move to SharePoint
Archive	Content must be retained but is not active collaboration content
Delete	Content is approved for deletion based on policy and business review
Review	Ownership, sensitivity, or retention is unclear
Split	Content needs a separate site, library, or security boundary

Even a simple ROT process can reduce migration risk significantly. For more on choosing the right destination across OneDrive, Teams, and SharePoint, see Network Drive Migration: OneDrive, Teams, and SharePoint Strategy.

7. Copilot readiness and search discoverability

Copilot readiness is not only about licensing users.

It is also about whether your Microsoft 365 content is governed well enough to be safely discovered, summarized, and reused by the people who already have access.

This is why permissions cleanup matters.

Microsoft 365 Copilot and related SharePoint experiences are designed to respect existing permissions. That is good from a security trimming perspective, but it does not answer the more important governance question:

Should the user have that access in the first place?

If the answer is no, then Copilot may surface a problem that already existed in the permission model.

What to review

Before copying permissions into SharePoint, review:

• Sites or folders with broad access
• Sensitive content under broad permissions
• Old groups with unclear membership
• Direct user access
• Sharing links
• Guest users
• Ownerless content
• Broken inheritance
• Files that should be archived or labeled
• Sites that should not appear broadly in search
• Areas that need restricted access or restricted discovery controls

Why it matters

Copilot can make permission issues more visible because users can ask questions across content they are allowed to access.

That creates a business impact beyond IT:

• Executives may lose confidence in the rollout
• Compliance teams may delay adoption
• Users may find sensitive content they did not know existed
• IT may be forced into urgent cleanup instead of planned governance
• The organization may blame Copilot when the real issue is oversharing

Practical recommendation

Treat Copilot readiness as part of migration readiness.

Before migration, identify high-risk content areas and decide whether they need:

• Permission cleanup
• Separate SharePoint sites
• Restricted access policies
• Restricted discovery controls
• Sensitivity labels
• Retention labels
• DLP policies
• Site access reviews
• Sharing link reviews
• Owner confirmation

The best time to address Copilot readiness is before moving years of content into SharePoint. For the tenant-level controls that support this, see SharePoint Advanced Management: What to Review Before Copilot Expands Access.

Business impact

Permission cleanup is not just a technical task.

It affects the business in several practical ways.

Risk reduction

Clean permissions reduce the chance that sensitive content is available to the wrong users.

This matters for client data, HR records, legal documents, finance files, regulated data, and executive content.

Better governance

A clear permission model makes it easier to answer basic governance questions:

• Who owns this site?
• Who can approve access?
• Who can share externally?
• Which content is sensitive?
• Which content is archived?
• Which permissions are exceptions?
• When was access last reviewed?

Lower support cost

A messy permission model creates recurring support tickets.

Users cannot access what they need. Others can access too much. Site owners do not know which group to update. Admins spend time troubleshooting inheritance, sharing links, and direct access.

A cleaner model reduces that support load. The downstream cost of skipping this step is covered in The Hidden Cost of Messy SharePoint Permissions Before and After Migration.

Better adoption

Users are more likely to adopt SharePoint when the structure makes sense.

If users are dropped into a migrated file share with confusing folders and inconsistent access, they may avoid SharePoint or recreate old habits elsewhere.

Stronger Copilot readiness

Copilot is more useful when the underlying content is trustworthy, current, properly permissioned, and governed.

Permissions cleanup helps improve the quality and safety of what users can discover.

Recommendations

Here is a practical approach I recommend before copying file share permissions into SharePoint.

1. Inventory the current permissions

Run a permission inventory across the source file share.

Capture:

• Folder path
• Inheritance status
• Assigned users
• Assigned groups
• Permission level
• Nested group membership where possible
• Last modified date
• Folder size
• File count
• Owner or department
• Sensitivity indicators

The goal is to make the current state visible before making migration decisions.

2. Identify high-risk areas first

Do not try to solve every folder at the same depth right away.

Start with high-risk areas:

• HR
• Finance
• Legal
• Executive folders
• Client folders
• Regulated data
• External collaboration folders
• Folders with broad access
• Folders with many unique permissions
• Folders with no owner

This creates a risk-based migration plan instead of a purely storage-based migration plan.

3. Translate permissions into a SharePoint model

Avoid recreating the file share exactly.

Translate permissions into:

• Sites
• Libraries
• SharePoint groups
• Microsoft 365 groups
• Microsoft Entra security groups
• Sensitivity and retention controls
• External sharing policies
• Access review processes

This is where migration planning becomes information architecture.

4. Keep the model simple where possible

Simple is not the same as weak.

A simple permission model is often more secure because people can understand and maintain it.

Use clear patterns:

• Owners manage the site
• Members contribute content
• Visitors read content
• Sensitive libraries use approved security groups
• External sharing is limited to defined collaboration areas
• Archive content is read-only or restricted

5. Pilot with one business area

Before migrating everything, test the model with one department, project area, or client structure.

Validate:

• Access
• Search behavior
• Sync behavior
• Sharing behavior
• Site ownership
• Support process
• User experience
• Reporting
• Post-migration permission review

A pilot helps identify issues before they are repeated across the entire migration.

6. Validate after migration

Post-migration validation should include more than file counts.

Validate:

• Who has access
• Which groups were used
• Whether inheritance is expected
• Whether external sharing is configured correctly
• Whether sensitive content is protected
• Whether users can find what they need
• Whether users cannot access what they should not access
• Whether site owners understand their role

Migration is not complete just because the files copied successfully.

Migration is complete when the content is usable, governed, and supportable.

7. Plan for ongoing access reviews

Permissions will drift again if no one reviews them.

Create a recurring access review process for:

• Site owners
• Sensitive sites
• External guests
• Sharing links
• Inactive sites
• Broad access groups
• Ownerless content
• Archived content

Governance is not a one-time migration task.

It is an operating model.

Mistakes to avoid

Mistake 1: Copying every ACL without review

This may feel safe, but it often preserves old access risk.

Review before copying.

Mistake 2: Using direct user permissions everywhere

Direct user permissions are harder to maintain than group-based access.

Use groups wherever possible.

Mistake 3: Treating broken inheritance as normal

Broken inheritance may be necessary in some cases, but it should be intentional and documented.

Mistake 4: Ignoring external sharing

A file share and SharePoint Online have different sharing capabilities.

External sharing needs policy, training, and review.

Mistake 5: Waiting until after migration to clean up permissions

Post-migration cleanup is sometimes needed, but it should not be the entire strategy.

The best time to reduce risk is before content moves.

Mistake 6: Assuming Copilot fixes governance issues

Copilot respects permissions, but it does not decide whether those permissions are appropriate.

That decision belongs to the organization.

Mistake 7: Migrating archive content into active collaboration spaces

Old records and active working files should not always live in the same place.

Consider archive sites, retention policies, and read-only access where appropriate.

Mistake 8: Designing around the old folder structure only

A migration is a chance to improve information architecture.

Do not let the old folder tree make every SharePoint design decision.

Final thoughts

Copying file share permissions into SharePoint may look like the fastest migration path.

Sometimes it is.

But fast is not always safe, and safe is not always the same as copying what already exists.

If the current permission model is clean, documented, owned, and aligned with the business, then reusing parts of it may make sense.

But if the current model contains years of exceptions, stale access, broad groups, broken inheritance, and unclear ownership, copying it into SharePoint simply moves the problem into Microsoft 365.

A better migration approach is to pause, review the access model, and translate old permissions into a SharePoint structure that is easier to govern.

That means fewer surprises after go-live, fewer support tickets, better security, stronger compliance posture, cleaner search results, and better readiness for Microsoft 365 Copilot.

If you are planning a file share to SharePoint migration, permissions cleanup should be part of the readiness plan, not a cleanup project that starts after users find the problem.

Planning a migration and not sure whether your existing file share permissions are safe to copy? I help organizations review file share permissions, identify oversharing risk, simplify access models, and design practical governance before migration — that is exactly what a SharePoint permissions cleanup engagement covers. Learn more about my SharePoint migration consulting and Microsoft 365 governance services.

Useful Microsoft resources

• Sharing and permissions in the SharePoint modern experience
• Enable content to be searchable in SharePoint
• Restricted SharePoint Search
• Get ready for Microsoft 365 Copilot with SharePoint Advanced Management
• Restrict discovery of SharePoint sites and content