Run a Pilot Migration for One Department: Practical Checklist for SharePoint Owners

You need to move one department’s files to SharePoint but want to avoid disrupting daily work. A pilot migration lets you test the process with a small group before rolling out to the whole organization. This article explains what a pilot migration is and why it reduces risk. It also provides a step-by-step checklist for planning, executing, and validating a pilot migration for a single department. By following this checklist, you can identify issues early and build a repeatable process for larger migrations.

What a Pilot Migration Is and Why It Matters

A pilot migration moves a small, representative set of data from a source location such as a network file share or on-premises server to a SharePoint site. The purpose is to test the migration process, identify problems, and refine procedures before a full-scale rollout. For SharePoint owners, a pilot reduces the risk of data loss, permission errors, and user disruption.

The pilot should include real files, folders, and metadata that reflect the department’s actual working environment. Do not use test files that are too small or too simple. The goal is to surface issues such as file path length limits, unsupported file types, or permission mapping errors.

A successful pilot gives you a validated migration plan. It also provides training material for the department and a baseline for estimating the full migration timeline. Without a pilot, you risk running into blockers that affect all users at once.

Prerequisites for a Pilot Migration

Before starting, confirm that you have the following:

• SharePoint admin or site owner permissions on the target site where the pilot data will land.
• Access to the source data with read permissions for all files and folders you plan to move.
• A migration tool such as the SharePoint Migration Tool (SPMT) or a third-party tool like ShareGate or Metalogix.
• A dedicated test site that mirrors the production site structure but does not affect live users.
• Department approval from the department manager and a point of contact for user feedback.

Pilot Migration Checklist: Step by Step

Follow these steps to run a controlled pilot migration for one department. Each step includes specific actions and settings to check.

1. Define the pilot scope and select the department
   Choose one department with a moderate data size — between 50 GB and 200 GB. Avoid the largest department for the pilot. Meet with the department manager to explain the pilot goals, timeline, and expected downtime. Get written approval and identify a user liaison who will test the migrated data and report issues.
2. Audit the source data
   Run a scan on the source file share or local folder. Identify files with names longer than 400 characters, paths longer than 400 characters, or unsupported file types such as .lnk or .tmp. Create a log of files that exceed SharePoint limits. Fix or exclude those files before migration. Also document the current folder structure and permission groups.
3. Create the target SharePoint site
   Go to SharePoint admin center > Active sites > Create. Choose a communication site or team site depending on the department’s collaboration needs. Name the site clearly: for example, “Finance Pilot — Q1 2025.” Set the site privacy to Private if data is sensitive. Do not add users yet — you will grant access after migration validation.
4. Configure the migration tool settings
   Open your chosen migration tool. Set the source path to the department’s folder. Set the target to the pilot site’s document library. Enable metadata preservation if you need to keep modified dates or custom columns. Enable permission mapping: map source groups to SharePoint groups. Do not select “Copy all permissions” without mapping — this can break access.
5. Run the first migration pass
   Start the migration during a low-usage window such as a weekend or after business hours. Monitor the tool’s progress dashboard. Note any errors such as access denied, file locked, or path too long. Pause the migration if the error rate exceeds 5 percent. After completion, review the migration log for warnings and failures.
6. Validate the migrated data
   Open the pilot site and browse folders. Check that the folder structure matches the source. Open five to ten random files to confirm they open correctly. Verify that file versions are preserved if you enabled version migration. Test permissions: ask the department liaison to log in and confirm they can access their files but cannot access files from other departments.
7. Collect user feedback
   Send a short survey to the department users who accessed the pilot site. Ask three questions: Can you find your files? Can you open and edit them? Do you see any missing data? Collect responses within five business days. Document all complaints and fix them before the next migration pass.
8. Run a second migration pass for delta changes
   After the initial validation, run a delta migration to move any files that changed since the first pass. This step ensures that no data is left behind. Use the same tool with the same settings. Compare the file count between source and target to confirm they match. If counts differ, investigate the missing files.

Common Pilot Migration Issues and How to Avoid Them

File path length exceeds SharePoint limit

SharePoint supports file paths up to 400 characters. If the source has deeply nested folders or long file names, the migration tool will fail those files. Before migration, use the tool’s pre-scan feature to list files that exceed the limit. Shorten folder names or flatten the folder structure in the source before copying.

Permission mapping breaks user access

If you map source groups to SharePoint groups incorrectly, users may lose access to their files. Always test the mapping with a single folder first. Create a test user account that belongs to the source group and verify access after migration. Adjust group mappings before running the full pilot.

File version history is missing

The SharePoint Migration Tool preserves up to 100 versions per file by default. If you need more, adjust the version limit in the tool settings. After migration, check the version history of a document that had multiple versions in the source. If versions are missing, re-run the migration with a higher version limit.

Special characters in file names cause errors

SharePoint does not allow characters like # % & : < > ? / \ |. The migration tool may rename these files or skip them. Run a pre-scan to identify files with special characters. Rename the files in the source before migration or use the tool’s auto-rename feature.

Pilot Migration vs Full Migration: Key Differences

Item	Pilot Migration	Full Migration
Scope	One department or 50–200 GB	Entire organization or multiple terabytes
Timeline	1–2 weeks including validation	Several weeks to months with phased rollouts
Users affected	Small group (5–20 users)	All users in the organization
Risk level	Low — issues are contained	High — issues affect all users
Validation effort	Manual checks by pilot team	Automated validation scripts and user acceptance testing

A pilot migration gives you a low-risk environment to test your migration tool settings, permission mapping, and user communication plan. Use the lessons from the pilot to create a standard operating procedure for the full migration. Document every error and fix so that the full migration runs smoothly.

After the pilot, schedule a review meeting with the department manager and your IT team. Decide whether to expand the pilot to a second department or proceed with the full migration. Adjust the timeline based on the issues found during the pilot. For example, if permission mapping took longer than expected, allocate extra time for that step in the full plan.

One advanced tip: use the SharePoint Migration Assessment Tool (SMAT) before the pilot to scan the entire source environment. SMAT generates a report of file types, size distribution, and permission complexity. This report helps you choose the right pilot department and configure the migration tool accurately. Run SMAT at least two weeks before the pilot start date to allow time for analysis.