When organisations move from traditional file shares to SharePoint Online, one of the most challenging areas is permissions. NTFS permissions often grow and change over many years as teams shift, people leave, and quick fixes are applied. This usually results in a structure that is inconsistent, difficult to understand, and hard to maintain.
SharePoint Online works best when permissions are simple, predictable, and supported by a structure that reflects how the organisation works today. Because of this, permissions cannot be copied directly from a file share. They need to be reviewed, understood, and redesigned as part of the migration.
This guide covers structure, permissions, and the governance needed to keep the environment clean after migration. The aim is to reduce complexity, improve clarity, and create an environment that is secure and easy to manage.
Why File Share Permissions Cannot Be Copied Directly
NTFS permissions often evolve without a clear plan. Over time, it is common to see deep folder structures, deny rules, legacy groups, and inconsistent inheritance. These patterns reflect how the file share grew, not how the organisation works today.
SharePoint Online uses a different model. Permissions are applied at the site or library level. Inheritance is used to keep access simple. Access is based on business needs rather than folder paths. Trying to copy NTFS permissions directly into SharePoint usually creates confusion and makes the environment difficult to govern.
This is why permissions must be redesigned rather than transferred as they are.
Understand the Content Before Designing Access
Effective permission design begins with understanding the content itself. Different types of information carry different levels of risk and therefore require different levels of control.
This stage is not about reading every file. It is about identifying:
- what type of content exists
- who uses it
- how sensitive it is
- which areas require restricted access
- which teams own which parts of the structure
This understanding sets the boundaries for both the SharePoint structure and the permission model.
Analyse Existing Source Permissions
Exporting source (NTFS) permissions often reveals how access has changed over time. You may find nested groups, deny rules, large group memberships, or sensitive folders with broad access.
The goal is not to recreate this model. It is to identify what is unnecessary, what no longer reflects how people work, and what needs to be redesigned.
Design the SharePoint Structure
Once you understand the content and the legacy access patterns, the next step is to design the SharePoint structure. This includes decisions about:
- which sites are needed
- how many libraries are required
- whether folders are necessary
- where metadata can replace folder depth
- which areas need restricted access
- how users will navigate the content
This structure becomes the foundation for the new permission model and the migration itself.
Design the Permission Model
The permission model should be simple and easy to maintain. Instead of recreating source groups, SharePoint groups should reflect how people work today.
A clear model usually includes:
- Owners who manage the site
- Members who contribute and collaborate
- Visitors who have read-only access
This model should be designed before migration so that content can be placed correctly from the start.
Validate the Design with Data Owners
Before migration begins, the proposed structure and permission model should be reviewed with data owners. They confirm that:
- the structure reflects how they work
- sensitive content is correctly identified
- access levels are appropriate
- restricted areas are correctly placed
This ensures the design is accurate and aligned with business needs.
Prepare SharePoint for Migration
Once the design is approved, the SharePoint environment can be prepared. This includes:
- creating sites and libraries
- creating folders where needed
- creating SharePoint groups
- keeping inheritance intact at first (leaving the default permissions unchanged until migration is complete)
- assigning the migration team the level of access required to run the migration tools safely and effectively
This prepares the environment for a clean and controlled migration.
Migrate Content Without Copying Source Permissions
During migration, content should be moved into the new structure without bringing source permissions across. This avoids importing years of complexity and inconsistency.
Content lands in the correct libraries and folders, ready for the new permission model.
Apply the New Permission Model
Once migration is complete, the new permission model is applied. This includes:
- breaking inheritance only where necessary
- assigning the new SharePoint groups
- securing restricted areas
- removing unnecessary access
- validating permissions with data owners
This ensures the environment is secure and aligned with the organisation’s needs.
A Practical Example: Operations / Projects Department Migration
The Operations department has been using a shared drive for more than a decade. Over time, the structure has grown organically, with each project manager creating their own folders and access rules. This has resulted in a structure that is difficult to navigate and even harder to manage.
Source environment issues
- A large “Projects” folder with hundreds of subfolders with no naming standards (e.g., “ProjA”, “Project 2020”, “NewProj”, “Archive2”)
- Old and active projects mixed together
- Sensitive documents stored alongside general working files
- NTFS groups created for individual projects, then abandoned
- Some project folders accessible to the entire department
- No clear ownership of who manages access
What the analysis reveals
- Active projects need collaboration across multiple teams
- Closed projects need to be archived but still accessible for reference
- Some projects contain sensitive or confidential information
- Many legacy folders are no longer needed
- Project managers want a simpler, clearer structure
The redesigned SharePoint structure
Instead of copying the entire folder tree, the structure is simplified:
Active Projects (main library)
- Project A
- Project B
- Project C
Closed Projects (separate library)
- Archived 2020
- Archived 2021
- Archived 2022
Restricted – Sensitive Documents (restricted library)
- Confidential project files
- Supplier or partner information
- Internal notes
Templates & Standards (open library)
- SOPs
- Forms
- Templates
The new permission model
- Operations Owners
- Operations Members
- Operations Visitors
- Restricted – Sensitive Documents
Only the restricted libraries break inheritance. Active projects inherit from the site unless a project requires special access.
Outcome after migration
- Active projects are easy to navigate
- Closed projects are archived cleanly
- Sensitive content is isolated and properly secured
- No nested NTFS groups
- No deny rules
- No deep folder structures
- Project managers understand where to store content
- Governance becomes manageable
This example shows how a messy, legacy structure can be transformed into a clean, secure, and easy‑to‑manage SharePoint environment.
Governance After Migration
Migration is not the end of the process. A sustainable permission model requires ongoing governance. Regular access reviews, clear ownership of groups, and monitoring for permission drift help keep the environment secure and consistent.
Permission Maturity Perspective
Level 1 – Intentional Design (Post‑Migration Baseline)
- SharePoint groups used consistently
- Inheritance intact with minimal unique permissions
- Sensitive content stored in restricted libraries
Level 2 – Operational Drift
- Temporary access and quick fixes introduce exceptions
- Inheritance broken for convenience
- Direct permissions added to individuals
Level 3 – Permission Sprawl
- Many unique permissions across folders and libraries
- Sensitive content mixed with general content
- SharePoint groups bypassed, causing confusion
Level 4 – Re‑stabilisation Through Redesign
- Triggered by audits, restructures, or security concerns
- Inheritance restored and restricted areas re‑segregated
- Groups simplified and ownership re‑established
Preventing Regression Through Ongoing Governance
To avoid repeating this cycle, organisations need at least lightweight but consistent governance practices:
- Use SharePoint groups as the primary access mechanism
- Minimise direct user assignments
- Break inheritance only when there is a clear business need
- Store sensitive content in dedicated restricted libraries
- Review access periodically, even at low frequency
- Ensure ownership and approval responsibilities are clearly documented
These simple habits help maintain a stable permission baseline and reduce the need for disruptive redesigns in the future.
Conclusion
Designing structure and permissions in a SharePoint migration is an opportunity to create a clean and intentional model. Instead of carrying forward years of inherited complexity, organisations can build a structure that reflects how they work today.
A well‑designed model reduces risk, improves clarity, and supports collaboration long after the migration is complete. A SharePoint migration is not a lift‑and‑shift exercise; it is an opportunity to redesign structure and permissions so they work for the organisation today.