Server migration failures often begin with information that nobody realized was missing. Administrators know how much data sits on the server, but they may not know which scheduled task runs every night, which application uses a hidden share, or which service account depends on the old server name. A migration inventory is therefore more than a hardware list. It is a map of how the server fits into the business.
Start With Basic Server Identity
Document hostname, fully qualified domain name, IP addresses, DNS entries, domain membership, operating system version, and hardware or virtual machine configuration. Record CPU, memory, storage volumes, network adapters, and important virtual infrastructure settings.
This information creates the foundation for comparing the source and destination environment.
Record Every Storage Volume
A server may contain system volumes, data drives, temporary storage, application disks, and backup locations. Document total capacity, used space, free space, file system, mount points, and growth trends.
During migrating server planning, teams should also identify unusually large folders and file types. A small number of massive files can affect transfer time differently from millions of tiny files.
Inventory Shares
List every SMB share, its local path, share name, description, share permissions, and whether users actively depend on it. Hidden administrative shares should be distinguished from business shares.
Do not assume that an old looking share is unused. Verify with access data or business owners before removing anything.
Capture NTFS Permissions
Permissions are frequently one of the most sensitive parts of file server migration. Record folder access control lists and identify special permissions that break inheritance.
Groups should also be reviewed. If permissions reference deleted users, old domain groups, or temporary accounts, administrators need to decide whether those entries should be preserved, removed, or corrected before migration.
Review Scheduled Tasks
Scheduled tasks may copy files, generate reports, clean folders, run scripts, launch applications, or trigger backups. They can be easy to miss because users do not interact with them directly.
Document task names, schedules, run as accounts, scripts, paths, and dependencies. A successful data transfer followed by missing nightly automation can still create a business failure.
Identify Services and Applications
Review installed applications and running services. Note service accounts, startup type, executable paths, ports, configuration files, and data locations.
Some tools or utilities may have been installed years earlier and forgotten. Application owners can help determine whether they remain necessary.
Map Network Dependencies
Record firewall rules, listening ports, outbound connections, DNS aliases, mapped drives, DFS references, scripts, and integrations. The source server may depend on other systems, while other systems depend on it.
Using something such as microsoft storage migration service can assist with supported inventory and transfer scenarios, but administrators still need business context around applications and network dependencies that automated discovery may not fully explain.
Document Backup Configuration
Record backup products, schedules, destinations, retention policies, exclusions, and recent restore test results. The destination server will require backup protection after cutover.
Teams should also make sure the source has a recent recoverable backup before migration begins.
Record Antivirus and Security Configuration
Endpoint protection can affect file transfer performance or block migration tools unexpectedly. Document antivirus, EDR, firewall, encryption, auditing, and other security controls.
Any temporary exclusions created for migration should be approved, limited, and removed after the work is complete.
Understand User Access Patterns
Find out which departments access each share, which hours are busiest, and whether applications maintain open files for long periods.
This information helps schedule the cutover and identify which users should participate in validation.
Capture Existing Problems Separately
A migration should not automatically be blamed for problems that already existed. If a share already contains broken permissions, long path errors, duplicate files, or failed scheduled jobs, record those issues before transfer.
This creates a clean distinction between existing technical debt and migration defects.
Record Owners for Every Critical Dependency
A useful inventory does not merely list “Accounting Share.” It identifies who can confirm whether Accounting works after cutover.
Application owners, department contacts, and technical owners make validation much faster because the migration team knows who can provide a meaningful answer.
Turn the Inventory Into the Migration Checklist
The best migration inventory becomes the basis for testing. Every share, service, task, application, permission group, and network dependency should eventually produce a validation step.
That turns discovery into something practical. Instead of asking after cutover whether “the server seems fine,” administrators can verify each known function. A complete inventory therefore reduces uncertainty before the first transfer and gives the team a clear definition of what successful migration actually means.