Quick answer: To migrate business data without losing or accidentally broadening access, inventory repositories and owners, map source identities and groups to the target, approve the target permission model, pilot with actual role-based accounts, reconcile both files and rights, and only then cut over. Keep the source recoverable until data owners accept the result. Copying files or running a migration tool does not automatically preserve every ACL, sharing link and file-level exception.
This is a migration-project guide, not a generic monthly backup checklist. Still choosing a target? Compare NAS, file server and SharePoint. If ownership and role access are unclear, establish a departmental access matrix before moving content.
Three failures that appear after a rushed migration
Files first, permissions later: the source may contain individual grants, departed users or public links. Preserving everything carries excess access forward; discarding everything stops work.
File count only: bytes may match while documents do not open, metadata or versions are missing, or applications still point at the old path. Reconciliation must test important data and business workflows.
Source retired too early: users keep editing there, the final delta has not finished, or no freeze and rollback exist. Two competing ‘master copies’ then become difficult to reconcile.
Phase 1: inventory and classify
List shares/sites, paths, volume, file counts, large files, problematic names, dependent applications, owners, groups and external users. Identify retention obligations and stale or duplicate data, but remove nothing without owner approval. Record the authoritative copy, sensitive areas, write window and recovery requirements.
A useful inventory includes source, proposed destination, owner, read/edit groups, identity-mapping status, pilot wave and approver. Separate personal drafts from shared business records.
Phase 2: map identities and permissions
Map AD, local and guest users to target accounts and approved business groups. Decide inheritance, permitted exceptions, external sharing and service accounts that depend on the old path. Microsoft documents that SharePoint Migration Tool permission outcomes depend on user mapping and permission type; unmapped content can inherit destination defaults. Migration Manager exposes separate file/folder and delta behavior. Read the behavior of the exact tool/version, test representative files and validate effective rights with real users.
Technical administrators implement rights; business data owners approve them. Retain a source-permissions export and a signed target matrix as evidence.
Phase 3: pilot against explicit acceptance criteria
Choose a common folder, sensitive area, large and awkwardly named files, important versions/metadata, a read-only user, an editor and a user who must be denied. Move the sample; open it in the real application; check search/sync where relevant, sharing links and final rights. Classify defects as naming, mapping, permission or application issues before the main wave.
Agree measurable project-specific criteria: which datasets must be complete, how counts and sizes are compared, which errors are tolerable and who decides. Do not promise a generic success percentage without knowing the source.
Phase 4: freeze, delta and cutover
Tell users when edits will stop, where the new location is and how to request support. Run the initial migration and a delta where supported. Microsoft’s Migration Manager documentation warns that permission changes in a delta may only migrate when the corresponding file is transferred; never assume every source-rights change automatically reaches the destination. Retest groups and links after the final wave.
Update applications, shortcuts and mapped drives under a cutover plan. Keep the old source read-only during stabilization if feasible; do not allow two editable masters without designed synchronization and conflict handling. Staff the first support window.
Phase 5: reconcile and decide whether to roll back
Compare each share/site and critical samples: failed files, counts, sizes, required versions/metadata, rights for three account types and dependent workflows. Keep migration logs and owner test records. Acceptance requires key users to complete routine tasks and owners to accept any remaining exceptions.
A rollback plan specifies triggers, authoritative-copy timestamp, how destination writes are stopped, how paths and applications revert, the decision maker and maximum recovery window. Once new work exists at the destination, rollback also requires controlled reconciliation of that work.
Migration is not backup
Migration changes the working location; backup provides a recovery path for deletion, corruption or attack. Synchronization may propagate a mistake, and temporarily retaining an old source is not a backup design. After cutover, verify target backup/restore, retention, version history and backup-copy rights against the approved policy.
Frequently asked questions
Does a file copy preserve every permission? Never assume so; source, target, tooling, settings and identity mapping all matter. Pilot and test actual accounts.
Can staff edit during migration? A delta-supported plan may permit initial work, but a clear freeze/cutover is still needed to prevent two masters.
Will old SharePoint or file links still work? Test paths and sharing links separately, including application dependencies.
When can the old server be decommissioned? After owner acceptance, tested target recovery, a disposition for open defects and an approved source-retention period.
Technical references
Microsoft Learn: SPMT file and folder permissions; Microsoft Learn: Migration Manager permission settings; Microsoft Learn: migration settings and user mapping.
