A migration can finish copying data while leaving employees unable to do their jobs. The plan needs to describe how people will use the new system, what will change, and what evidence will establish that the move is complete. Start with the business requirements before choosing a tool or a cutover date.
Decision walkthrough: a nonprofit SharePoint migration
In one prior engagement, approximately 80 nonprofit staff used about 4 TB of files on local storage with inconsistent inherited permissions. The objective was to retire the active on-premises environment while giving departments a more manageable access model.
The project lead and IT director reviewed ownership and access before migration. The chosen design used more than ten Teams-connected SharePoint sites with department-level owners, members, and visitors. The decision addressed how the organization would manage access after the move, rather than reproducing the old folder exceptions.
The eight-week rollout generally moved one department per week. At each cutover, source folders became read-only before the final transfer, then staff moved to the new location the next workday. This controlled where active edits could occur.
Validation included reviewing departmental access with the IT director and confirming that users could reach their assigned files. Approximately 30–40 empty files or items with incompatible paths or names were excluded after review. Legacy storage remained a restricted archive under the IT director’s control.
For your own migration, identify the decision owner, agree on target access, define where edits stop at cutover, and record accepted exceptions. These are planning questions to adapt to your environment, not a recommendation that every organization use the same platform or schedule.
List the workloads and their owners
Treat email, calendars, contacts, shared mailboxes, files, permissions, and connected applications as individual scope items. Decide who can approve the destination and verify the result for each. Include shared work that may be owned by a former employee or an external provider.
Microsoft documents several email migration methods, and Google documents differences in the information supported by individual migration tools. Do not assume that moving messages will also move files, sharing permissions, or every calendar setting. Confirm those requirements against the chosen method.
- Source and destination for each workload
- Approximate users, data volume, and age of required records
- Administrative access and domain ownership
- Shared resources, external collaborators, and application connections
- Required information that will remain in the original system
Make a pilot representative of real work
Choose examples that exercise important differences: a user with delegated access, a shared resource, an employee working remotely, or a folder with restricted permissions. A single straightforward mailbox may miss the dependencies that matter elsewhere.
Write down the expected behavior and the actual result. A good pilot checks opening information, finding it, editing where appropriate, and sharing it with the intended people. Resolve exceptions or give them an explicit owner before deciding the approach is ready.
Give the cutover a decision point
Name the person who can approve proceeding, the deadline for that decision, and the conditions that would cause a pause. Staff should know which system to use, when it changes, and how to report a problem. Suppliers handling DNS, identity, or business applications need aligned responsibilities.
A recovery plan should explain what can be restored or kept available, the access needed, and how new information created during the transition would be handled. Simply saying 'we can roll back' leaves important questions unanswered.
Define acceptance before the migration starts
Agree which checks demonstrate a working destination and who performs them. Keep tool reports alongside user validation, and record items that were excluded or could not be moved. If the scope changes during discovery, update the acceptance criteria before continuing.
- Users can sign in using the agreed authentication method
- Representative incoming and outgoing mail works
- Required shared mailboxes, calendars, and files are accessible
- Permissions match the agreed business requirements
- Critical connected workflows have been checked
- Exceptions and follow-up actions have named owners
Retire the source as a separate task
Confirm that old services are no longer needed for retained records, integrations, recovery, or a contractual obligation before closing them. Assign an owner and a review date to temporary access or subscriptions that remain.
The handover should contain the final scope, validation evidence, current administrative ownership, and outstanding tasks. That record gives the business a usable starting point for support after the migration team has finished.
Related case studies
Continue reading
Sources and further reading
These references support the technical details or service terms above. Check the current documentation when planning a change.