Workstream 01
Inventory sources by collaboration purpose
Separate personal files, working team collections, regulated records, archives and temporary handoff folders. Count objects as well as gigabytes, identify file types and unusual naming patterns, and document source permissions where they can be exported. Ask each business owner which collections remain active, which can be archived, and which should not move at all.
For Google Drive sources, Microsoft's Migration Manager offers scan and assessment reports before transfer. These reports identify issues but do not necessarily discover orphaned Google files, so the source inventory needs its own validation. The same principle applies to file servers: scan the paths the migration tool will process and account for everything deliberately excluded.
| Source decision | Destination question | Proof after migration |
|---|---|---|
| Personal or team-owned | OneDrive or SharePoint team site? | Named owner and access test |
| External collaborations | Which guests or domains retain access? | Approved external account test |
| Google-native formats | What conversion or archive format is acceptable? | Representative document comparisons |
| Retention and archives | Which policies and exceptions apply? | Records-owner acceptance |
Workstream 02
Design the site and permission structure deliberately
SharePoint libraries and sites are not a direct substitute for an arbitrary maze of shared folders. Agree how teams search, collaborate and hand work to each other. Model site ownership and group membership, then test whether a user with the correct role can reach content while someone without that role cannot.
External collaboration needs its own decision. Microsoft supports tenant-level sharing policy with more restrictive site-level options; Teams and Microsoft 365 Groups can introduce additional guest-access conditions. The permitted outcome must be tested on the actual destination rather than inferred from a single configuration screenshot.
What to capture before the decision
- Name a destination owner for each site and library
- Agree folder, library and metadata mapping
- Test both allowed and denied access cases
- Identify Google-native files requiring conversion
- Document exceptions and business acceptance owners
Workstream 03
Acceptance is a comparison, not a green icon
Compare source and destination object counts, content samples, access groups and intentional exceptions. A migration task can display Completed even when unsupported items failed; Microsoft's own documentation describes this behaviour for Migration Manager. Read the detailed reports and separately retain evidence for every excluded or transformed item.
Include links and integrations in the review. Bookmarks, Teams tabs, workflows and third-party applications can still point to the source. Decommission only after owners approve the new destinations, data policy and business process. If the organisation cannot staff this review, it is a delivery dependency to budget for rather than a reason to skip it.
Workstream 04
Choose the destination architecture before importing files
A SharePoint migration can fail commercially while succeeding technically if a copied folder structure leaves staff without a usable ownership model. Decide which content belongs in a communication site, a team-connected site, a separate restricted library or an individual's OneDrive. Map Microsoft 365 groups, guests, sensitivity requirements and external sharing policies with the business owner. Neither the number of file copies nor a pristine folder tree proves that access governance works.
Test the most complex library first: nested folders, long paths, external sharing, custom metadata, workflows and locked or unsupported files. Document supported conversion behaviour using Microsoft's migration tooling reports and compare sample documents in their target applications. Where an old link is embedded in a business process, name the owner who will update it.
| Decision area | Example discovery question | Acceptance evidence |
|---|---|---|
| Business ownership | Who owns the site when the project sponsor leaves? | At least two appropriate site owners |
| Restricted content | Should guests or broad team groups see the library? | Approved account-based access test |
| Metadata and automation | Which views, columns and flows are essential? | Functional test of selected workflow |
| Legacy links and paths | Which systems link to the old location? | Link remediation and exception record |
Workstream 05
Make site-by-site handover measurable
Group migrations into waves around data owners, not just bytes. Each wave should produce a source/destination map, task report, unresolved exception list, file-conversion sample and permission acceptance. Assign a business owner to sign that evidence and a support contact for issues discovered after cutover.
A realistic quote should name site counts, file volumes, supported source connectors, permission remapping, manual workflow rebuilds and the time available for verification. SharePoint administration after migration is a separate recurring operating obligation, not automatically included in a one-time move.
What to capture before the decision
- Site owners confirm target structure before transfer
- Scanner exceptions triaged before scheduling cutover
- Business users test sharing and key documents
- Workflow and link remediation allocated to named owners
- Handover covers site ownership and aftercare exclusions
A successful SharePoint migration produces an inventory, a destination ownership map and a signed exception record. That evidence matters more than the headline number of copied gigabytes.
Source documents and limitations
These references establish current vendor behaviour; they do not verify an individual customer's configuration or imply Microsoft affiliation. Technical claims should be rechecked before execution.