File Server Migration Assessment for MSPs
Assess file server permissions, SMB dependencies and user workflows. Build a representative pilot and define cutover criteria before migrating client data.
File Server Migration Assessment for MSPs: Permissions, Dependencies and Pilot Testing
A client file server may hold department folders, an accounting application's data, linked spreadsheets and a scanner's destination folder. Moving the documents can be straightforward while the other workflows need a different platform or changes to their configuration.
Before choosing a replacement, an MSP needs to know what uses the server, which access rules matter and what the new environment must support. This assessment provides the evidence for selecting a destination, planning the migration and deciding whether the pilot is ready for production.
Quick answer: what a file server migration assessment should include
A file server migration assessment must document the data, users, permissions, applications and working practices attached to the server before a destination is selected. It should produce an inventory, an approved access map, a dependency register, a destination decision for each workload and a pilot test plan. Production cutover should follow only when agreed acceptance criteria have been met and the final transfer, validation and rollback procedures are ready.
If the project is driven by an approaching support deadline, our Windows Server 2016 end-of-support article explains the replacement decision. This guide covers the technical checks needed to carry it out.
Start with the server inventory
Create one assessment record for each customer environment. Record every server involved, including any additional roles running alongside the file shares.
The inventory should cover:
Server version and roles: Operating system, physical or virtual deployment, file services, identity, print services, applications and scheduled tasks.
Storage capacity and growth: Used and available space, growth trends, active data and material retained for archive or legal purposes.
File count and sizes: Total files, size distribution, largest files and folders containing large numbers of small files.
Shares and folder structure: Share names, source paths, mapped drives, folder depth and naming conventions.
File types: Office documents, PDFs, images, CAD files, databases, application data and formats requiring specialist software.
Backup and recovery: What is protected, retention periods, restore procedures, the last tested restore and the customer's recovery requirements.
Remote access: VPN, remote desktop, direct SMB access, offline copies and any alternative access methods users already rely on.
Record the business owner for each significant share. That person should confirm which folders are active, who needs them and which workflows cannot be interrupted.
Use destination-specific assessment tools once a platform is shortlisted. For example, Microsoft's Migration Manager scan reports file counts, data sizes and migration-readiness issues for file-share migrations to Microsoft 365. A scan can expose transfer problems, but application dependencies and working practices still require investigation.
Use the File Server Exit Plan 2027 Workbook
Use the Workbook to record the environment inventory, access requirements, dependencies and migration blockers in one place. Continue with the same assessment as you compare destinations and define the pilot.
Use the File Server Exit Plan 2027 Workbook
Audit users, groups and permissions
Permission assessment needs to establish both the current configuration and the access the customer actually requires. Years of staff changes, temporary exceptions and nested groups can make those two things differ.
Separate share permissions from NTFS permissions
Share permissions govern access through a Windows network share. NTFS permissions apply to files and folders on the underlying file system. Network access must satisfy both layers, so reviewing only the share or only the folder's Security tab leaves part of the access model unexplained.
Record users, security groups and group membership, including nested groups and local accounts. Identify inherited permissions, explicit entries, blocked inheritance and deny entries. Microsoft's access-control documentation explains how Windows permissions and inheritance work.
Look specifically for:
- Accounts belonging to former employees or contractors.
- Unresolved security identifiers and groups with unclear ownership.
- Direct user permissions that bypass the normal group structure.
- Restricted subfolders inside otherwise accessible departments.
- Service accounts used by applications, scripts or devices.
- Access that allows reading but intentionally prevents editing or deletion.
Preserve a record of the source configuration before making changes. Windows tools such as icacls can display and export discretionary access control lists. An export documents the source; it does not establish that another platform can reproduce every rule.
Map the required access to the destination
Build an access map showing the source folder, approved users or groups, required actions, destination location and any exception requiring redesign. Have the relevant business owner approve changes to access.
For a RushFiles migration, map these requirements to users, groups, Shares and the available access levels. Individual users can have Read, Write or Owner rights to a Share; groups can have Read or Write rights. RushFiles documents these distinctions in its user and group administration guidance.
RushFiles does not automatically migrate NTFS ACLs. Windows Full Control, Modify, explicit deny rules and inheritance should not be treated as direct equivalents of RushFiles access levels. Document the required outcome, configure the appropriate access model and test it with representative accounts.
For example, a Finance folder might need editing access for the finance team, read access for an auditor and no access for other employees. Test all three cases, including attempts to reach the folder directly. A user being able to open the right file proves only part of the permission requirement.
Find SMB and UNC dependencies
SMB is the protocol used by traditional Windows network file shares. A UNC path identifies a network location, such as \\SERVER01\Accounts. Mapped drives can point to these locations while hiding the server name from users.
A file server dependency audit should find anything that expects those paths or relies on traditional file-system behaviour. Check:
- Applications that open or save through mapped drives.
- Hard-coded UNC paths in application settings, scripts and configuration files.
- Scheduled tasks and services running under dedicated accounts.
- Scanners and multifunction printers using scan-to-folder.
- Office templates, macros and documents linked to other files.
- Databases and applications storing live data on a share.
- Accounting, legal, CAD and other specialist applications.
Combine configuration review with observation. Inspect drive mappings, Group Policy, task definitions, service settings and device address books. Ask application owners to demonstrate their normal workflows, including reporting and month-end processes.
On a Windows SMB server, Get-SmbSession shows current client sessions, while Get-SmbOpenFile shows files currently opened by SMB clients. These provide useful evidence of active use, but a snapshot will miss a scanner that is idle or a task that runs once a month.
For each dependency, record the application or device, path, account, frequency, business owner and consequence of failure. Assign an action: retain a compatible destination, reconfigure the workflow or replace it with a supported alternative.
Document how users work
Ask users to demonstrate complete tasks rather than simply confirm that they can browse a folder. Record the devices, access methods and file behaviour each task needs.
Include Windows and macOS where used, remote locations, offline work, large files, simultaneous editing and external sharing. Establish whether users need Office co-authoring, application-level locking or a controlled process where only one person edits at a time.
For offline workflows, identify which files must be available before disconnecting and what should happen when users reconnect after making changes. For large files, test opening, saving and reopening through the actual client and connection the user will use.
If external parties receive files, record whether they need a link, an account, upload access or ongoing collaboration. Include access expiry and revocation requirements in the assessment.
These findings become pilot test cases. For example: a remote designer opens a representative project, changes a referenced asset, saves it and confirms that a colleague can use the updated project without broken references
Classify each workload before selecting a destination
Use the assessment to split the environment into workloads with similar requirements. One customer may need several destinations.
These are shortlist directions. File type alone does not determine the destination: a spreadsheet used for team collaboration may suit Microsoft 365, while another spreadsheet depends on macros and fixed network paths.
Record why each destination was selected and any unresolved requirement. The file server replacement page provides the broader comparison and explains where RushFiles fits for MSP-managed shared-file workloads.
Build a representative migration pilot
Choose a manageable environment that includes the conditions likely to cause problems. A clean folder tested by an administrator gives little evidence about a customer’s restricted folders, remote users or specialist applications.
The pilot should include:
Users: An everyday user, a heavy user, a remote user and someone with restricted access.
Permissions: Read access, editing access, restricted folders, group membership and approved exceptions.
Devices: The Windows and macOS configurations actually in use, plus relevant scanners or other devices.
Files: Typical documents, large files, linked documents, long paths and representative specialist formats.
Workflows: Open, edit, save, rename, move, share, recover and reconnect after working offline, where required.
Dependencies: At least one business-critical or failure-prone process from the dependency register.
Where an application is staying on a separate server, test that its integration with the migrated files still works. Mixed destinations introduce boundaries that need their own validation.
Give each test an owner and record the expected result, actual result, evidence and corrective action. Retest failed cases after remediation. Keep the pilot aligned with the proposed production configuration, including client versions, identity, access and deployment.
Set acceptance criteria before testing
Agree the criteria with the customer's technical and business owners before the pilot begins. Define usable performance in measurable terms for the relevant task, file and connection, rather than relying on a general impression.
Record mandatory pass criteria separately from minor issues the customer can accept. Unexpected access to confidential data, an unresolved critical application failure or an untested recovery process should prevent cutover.
Review the pilot plan with RushFiles
If RushFiles is on the shortlist for the shared-file workloads, bring the inventory, access map and dependency register to a migration-planning call. Review the proposed scope and identify what the pilot still needs to prove.
Book a migration-planning call
Prepare cutover and rollback
Once the pilot passes, create a cutover runbook with named responsibilities and a go/no-go decision time. Confirm that production changes made since the assessment are reflected in the plan.
Define the data freeze. Specify when users, applications and devices must stop writing to the source. Include scheduled processes and offline devices, not just staff working in the office.
Complete the final transfer. Where the migration method supports an initial copy and a final delta transfer, verify how it handles edits, deletions and failures. Reconcile transfer logs, file counts and sizes, investigate exceptions and perform content or integrity checks appropriate to the workload.
Communicate the change. Tell users when access changes, what they must do with offline files, where the new files are and how to get help. Update relevant shortcuts, application settings and device destinations.
Validate before releasing access. Recheck permissions, critical workflows, recovery and migration errors. A completed transfer job does not establish that the customer can resume work.
Define the rollback decision and procedure. Specify the conditions that trigger rollback, who approves it and the latest point at which it remains practical. Once users have edited files in the destination, returning to the source requires reconciling those changes. Keeping the old server available does not resolve that problem by itself.
Retain the source in a controlled state for an agreed period, maintaining its security and backup arrangements. Monitor access failures, missing files, application errors, performance and support tickets after cutover. Decommission only after the customer has accepted the migration and retention requirements have been addressed.
Frequently asked questions
Are NTFS permissions migrated automatically?
It depends on the destination and migration method. Some Windows-based migrations can preserve ACLs when identities and tooling are configured correctly. Other platforms use different access models. RushFiles does not automatically migrate NTFS ACLs: required access must be mapped to users, groups and Shares, then tested. An exported ACL is evidence for the assessment, not proof of destination compatibility.
How do you find applications using UNC paths?
Review application settings, mapped drives, Group Policy, scripts, scheduled tasks, services and scanner configurations. Inspect linked documents and ask users to demonstrate periodic processes. SMB session and open-file information helps identify current activity, but observation should cover relevant operating cycles. Record every dependency with its owner and required remediation.
What should be included in a file server pilot?
Include representative users, permissions, devices, file types and complete working practices. Test remote access, offline work, simultaneous editing, external sharing and recovery where required. Include a workflow likely to fail, such as a linked spreadsheet, scan-to-folder process or specialist application. Record pass criteria and evidence for each test.
How long should a file server migration take?
There is no reliable duration based on storage volume alone. File count, available throughput, data changes, permission redesign, dependencies, pilot remediation and the permitted outage all affect the schedule. Measure transfer performance during the pilot and estimate discovery, remediation, initial transfer, final transfer and validation separately. Distinguish the full project duration from the user downtime at cutover.
Can different workloads go to different destinations?
Yes. A customer might use SharePoint for collaborative documents, managed file sharing for department folders and a supported server for an application. Document the ownership, access, recovery and integration requirements for each destination. Test workflows that cross those boundaries before production cutover.
What should prevent a production cutover?
Stop if a mandatory acceptance criterion fails or a critical requirement remains untested. Examples include incorrect permissions, missing or corrupt data, unsupported applications, failed device workflows, unacceptable performance, unproven recovery or an impractical rollback procedure. Assign each blocker an owner, remediate it and repeat the affected tests before approving cutover.
Turn the assessment into a migration plan
The completed assessment should give the MSP and customer an agreed destination for each workload, an approved access map, a resolved dependency register and evidence that the pilot meets the production requirements.
Use the File Server Exit Plan 2027 Workbook to document those decisions and carry them through to cutover and rollback planning.