Your team needs to find, trust and use its information after the move. Plan the content, permissions and changeover together. Matt combines Microsoft 365 migration experience with AI-assisted tooling for sources that need more than a standard import.
See the migration sources
File shares, Google Drive, Dropbox and notes represent different starting points. Inventory the content and understand the source before choosing how to move it.
The source affects what can be preserved and how it maps to the destination. Bring those differences into the migration plan.
Plan the destination structure and access before the move. When sites and libraries should be created depends on the source and migration method.
Confirm the mappings before running the import. They describe where the information should go and how people should use it.
The SharePoint site and document library receive the prepared content. Teams files and group access connect the result to the people who need it.
Validate both the information and its access after import. A destination is useful when the intended team can work with what arrived.
Source understanding, preparation and import form one migration plan. The destination combines the content structure with the access needed to use it.
Confirm preservation against the actual source and selected tooling. The question is what your team needs to keep working after the move.
File shares, Google Drive, Dropbox and notes represent different starting points. Inventory the content and understand the source before choosing how to move it.
The source affects what can be preserved and how it maps to the destination. Bring those differences into the migration plan.
Plan the destination structure and access before the move. When sites and libraries should be created depends on the source and migration method.
Confirm the mappings before running the import. They describe where the information should go and how people should use it.
The SharePoint site and document library receive the prepared content. Teams files and group access connect the result to the people who need it.
Validate both the information and its access after import. A destination is useful when the intended team can work with what arrived.
Source understanding, preparation and import form one migration plan. The destination combines the content structure with the access needed to use it.
Confirm preservation against the actual source and selected tooling. The question is what your team needs to keep working after the move.
Find out what each source holds and what the migration path can preserve: files, versions, sharing links and permissions behave differently. Design the destination and access model early, and test before the full move. Delivered: a 3 TB file-share migration into SharePoint Online for a foundation.
Source content carries meaning beyond the document itself. Metadata, versions and links can affect how people understand and use it.
Decide which of those properties the destination needs. Include the mapping work in the migration plan before moving the file.
Metadata, versions and links each need a deliberate mapping. Confirm what the chosen source and tooling can preserve.
Validate the result against the intended use. A property appearing in the plan is not evidence that it survived the move.
Source identities need to connect to destination groups and permissions. Decide how people should reach the migrated information in their new workspace.
Review that mapping alongside the document mapping. Correct content in the wrong access scope still needs attention.
The SharePoint library receives the structured document, with connected Teams files providing a place to use it. Validate the mapped content and its access together.
Use the required properties and roles as the basis for acceptance. Record any preservation limits that need a decision.
Document properties and identity mapping describe different parts of the same move. Together they connect the source information to its intended destination use.
The selected source and tools determine what can be preserved. Make that visible early, then check the actual result.
Source content carries meaning beyond the document itself. Metadata, versions and links can affect how people understand and use it.
Decide which of those properties the destination needs. Include the mapping work in the migration plan before moving the file.
Metadata, versions and links each need a deliberate mapping. Confirm what the chosen source and tooling can preserve.
Validate the result against the intended use. A property appearing in the plan is not evidence that it survived the move.
Source identities need to connect to destination groups and permissions. Decide how people should reach the migrated information in their new workspace.
Review that mapping alongside the document mapping. Correct content in the wrong access scope still needs attention.
The SharePoint library receives the structured document, with connected Teams files providing a place to use it. Validate the mapped content and its access together.
Use the required properties and roles as the basis for acceptance. Record any preservation limits that need a decision.
Document properties and identity mapping describe different parts of the same move. Together they connect the source information to its intended destination use.
The selected source and tools determine what can be preserved. Make that visible early, then check the actual result.
Business fields, versions, links and access carry meaning that a simple file copy misses. Agree what must survive and how it maps, then test representative content, including exceptions the tool cannot handle. Delivered: a tenant consolidation that preserved site structure and permission mapping.
Source access includes people, groups, applications and existing permissions. Understand those relationships before deciding what the destination should allow.
An application identity is part of that inventory. Its access needs review alongside the people who use the content.
Identity mapping connects the source access model to Microsoft Entra ID. Use it to make the destination responsibilities and identities explicit.
Review the intended access rather than assuming the old arrangement is right. Migration is a point at which those decisions need to be confirmed.
Group membership connects people to Teams and SharePoint. Configure it around the roles that need to use the migrated information.
Validate the destination as the intended team members and guests. The access decision needs to hold in the experience they will actually have.
App registrations, service principals and grants define application access. Keep that configuration distinct from the membership used by people.
Test the selected applications with their intended identity. A successful human sign-in does not establish that the application has the right access.
Source inventory and identity mapping lead to destination group and application access. Both paths need review before the migrated system is released.
Check who can reach Teams, SharePoint and the selected applications. The move is ready when its access matches the work, as well as its data.
Source access includes people, groups, applications and existing permissions. Understand those relationships before deciding what the destination should allow.
An application identity is part of that inventory. Its access needs review alongside the people who use the content.
Identity mapping connects the source access model to Microsoft Entra ID. Use it to make the destination responsibilities and identities explicit.
Review the intended access rather than assuming the old arrangement is right. Migration is a point at which those decisions need to be confirmed.
Group membership connects people to Teams and SharePoint. Configure it around the roles that need to use the migrated information.
Validate the destination as the intended team members and guests. The access decision needs to hold in the experience they will actually have.
App registrations, service principals and grants define application access. Keep that configuration distinct from the membership used by people.
Test the selected applications with their intended identity. A successful human sign-in does not establish that the application has the right access.
Source inventory and identity mapping lead to destination group and application access. Both paths need review before the migrated system is released.
Check who can reach Teams, SharePoint and the selected applications. The move is ready when its access matches the work, as well as its data.
Review access rather than carry old sharing decisions into the move. Map the groups and app permissions the destination needs, and test that the wrong people cannot open sensitive content. Delivered: an Entra ID model of role-based and dynamic groups, and app registrations, for 6,000 internal and external users.
This scenario starts with user-selected PST archives. Associate the source mail with the intended destination mailbox or archive.
Make that destination decision explicit before import. The selection establishes what the job should bring into Exchange Online.
Azure Storage provides the upload staging area in this pattern. It holds the selected archives for the configured import process.
Keep staging separate from the import decision. The files still need an import job with the right mailbox mapping.
The import job maps the staged archives to their target. Review that mapping before the mail enters Exchange Online.
Use the intended mailbox or archive as the basis for the check. A completed upload does not confirm the final destination.
Exchange Online receives the imported mail in the selected mailbox or archive. Check the result against the source and destination mapping.
Review imported mail and target archives before closing the work. The receiving person needs the intended content in the intended place.
Selected PST archives pass through staging and a configured import job to Exchange Online. Each part has a distinct purpose.
Keep the mapping and validation with the import record. This PST archive workflow needs to be assessed separately from other ways of migrating mail.
This scenario starts with user-selected PST archives. Associate the source mail with the intended destination mailbox or archive.
Make that destination decision explicit before import. The selection establishes what the job should bring into Exchange Online.
Azure Storage provides the upload staging area in this pattern. It holds the selected archives for the configured import process.
Keep staging separate from the import decision. The files still need an import job with the right mailbox mapping.
The import job maps the staged archives to their target. Review that mapping before the mail enters Exchange Online.
Use the intended mailbox or archive as the basis for the check. A completed upload does not confirm the final destination.
Exchange Online receives the imported mail in the selected mailbox or archive. Check the result against the source and destination mapping.
Review imported mail and target archives before closing the work. The receiving person needs the intended content in the intended place.
Selected PST archives pass through staging and a configured import job to Exchange Online. Each part has a distinct purpose.
Keep the mapping and validation with the import record. This PST archive workflow needs to be assessed separately from other ways of migrating mail.
Mailbox moves and archive imports need their own plan: the source, the destination mailbox and checks that prove the content arrived. Delivered: a self-service PST upload to Azure Storage with automated import into Exchange Online, handed over to internal IT.
Product tools may cover the move; custom scripts handle the extraction or mapping they do not. Matt builds scripts and tests with AI assistance and reviews them before production; for a national insurer, that included reverse-engineering a legacy content system to build its migration and automated tests.
Reviewed scripts, Microsoft tooling and third-party tools offer different ways to run a migration. Select them around the source needs and the intended destination.
Claude and Codex can assist in authoring scripts. Review the implementation before allowing it to perform the migration.
The controlled migration run uses a plan and mappings. Script review and a pilot give the team a chance to check the approach before the approved execution.
Keep those checks connected to the real source rules. Automation repeats the instructions it receives, including mistakes that review misses.
The approved run targets a prepared Microsoft 365 destination. The content needs a clear place to arrive and a structure the team can use.
Validate the destination against the plan. Successful execution still needs evidence about the information and access it produced.
Results and exceptions describe what the run actually did. Use them to identify skipped work, failures and items that need a decision.
Assign the next action instead of losing exceptions in a completed batch. The report is part of the migration result.
Tool selection, explicit mappings, controlled execution and validation support repeatable migration. The destination and exception report show what that execution produced.
Use automation where its rules can be understood and checked. The value is a controlled way to carry out the plan.
Reviewed scripts, Microsoft tooling and third-party tools offer different ways to run a migration. Select them around the source needs and the intended destination.
Claude and Codex can assist in authoring scripts. Review the implementation before allowing it to perform the migration.
The controlled migration run uses a plan and mappings. Script review and a pilot give the team a chance to check the approach before the approved execution.
Keep those checks connected to the real source rules. Automation repeats the instructions it receives, including mistakes that review misses.
The approved run targets a prepared Microsoft 365 destination. The content needs a clear place to arrive and a structure the team can use.
Validate the destination against the plan. Successful execution still needs evidence about the information and access it produced.
Results and exceptions describe what the run actually did. Use them to identify skipped work, failures and items that need a decision.
Assign the next action instead of losing exceptions in a completed batch. The report is part of the migration result.
Tool selection, explicit mappings, controlled execution and validation support repeatable migration. The destination and exception report show what that execution produced.
Use automation where its rules can be understood and checked. The value is a controlled way to carry out the plan.
Agree when people stop changing the source and start using the destination. Where incremental copying is supported, an early transfer shrinks the cutover window.
Confirm what the tool can rerun and recover before setting the date; a rollback cannot be assumed for every path. Delivered: tenant consolidations moved with minimal disruption to users.
Where the source and tooling support an incremental migration, transfer the bulk while people continue working. Use a pilot to establish the checks, owners and recovery approach before scheduling cutover.
Confirm that this approach fits the selected migration path. If it does not support incremental catch-up, plan the interruption and recovery around the method it does support.
An agreed change freeze defines the point for the final increment. It gives the team a clear boundary for what remains to migrate.
Coordinate that boundary with the people using the source. The final increment needs to reflect the changes made after the bulk transfer.
Validation checks the destination before release. The go/no-go review decides whether the result is ready for users.
Keep the agreed recovery approach ready for a no-go decision. A scheduled window does not remove the need to respond to failed checks.
Release redirects users to the checked destination. It follows the final increment and the go/no-go decision.
Keep ownership clear as users begin their work. The release decision connects the migration result to its use by the business.
For an incremental migration, complete bulk movement before the agreed cutover window. Reserve that window for the final changes, validation and release decision.
Agree the checks and recovery approach in advance. The team should know what evidence allows release and what happens if it is not ready.
Where the source and tooling support an incremental migration, transfer the bulk while people continue working. Use a pilot to establish the checks, owners and recovery approach before scheduling cutover.
Confirm that this approach fits the selected migration path. If it does not support incremental catch-up, plan the interruption and recovery around the method it does support.
An agreed change freeze defines the point for the final increment. It gives the team a clear boundary for what remains to migrate.
Coordinate that boundary with the people using the source. The final increment needs to reflect the changes made after the bulk transfer.
Validation checks the destination before release. The go/no-go review decides whether the result is ready for users.
Keep the agreed recovery approach ready for a no-go decision. A scheduled window does not remove the need to respond to failed checks.
Release redirects users to the checked destination. It follows the final increment and the go/no-go decision.
Keep ownership clear as users begin their work. The release decision connects the migration result to its use by the business.
For an incremental migration, complete bulk movement before the agreed cutover window. Reserve that window for the final changes, validation and release decision.
Agree the checks and recovery approach in advance. The team should know what evidence allows release and what happens if it is not ready.
A file count does not prove the migration is complete. Compare expected content with the result and give every exception an owner.
Give the sponsor a view of progress and the decisions still needed. Delivered: Power BI dashboards for migration oversight on a national insurer engagement.
Before the run, record the source location, item count, size and accountable owner. That inventory gives the migration a defined starting point.
Keep the source and owner connected to the record. Planning and exception decisions need someone who understands the information.
Mapping records the destination, metadata, identity and access for the work. The target and batch show what the execution is meant to accomplish.
Keep those intentions tied to the original inventory. The team needs to compare the result with the move that was actually planned.
Results distinguish migrated, skipped, failed and review-required items. Reconcile those outcomes with the source inventory and planned mappings.
Use exceptions to decide the next action. A summary count is useful only when the team can account for the work behind it.
Inventory, mappings and outcomes belong to the same migration record. They explain what existed, what was intended and what needs attention.
Use that record to explain the migration to the people accepting it. They need to see what arrived, what did not and who will resolve each exception.
Before the run, record the source location, item count, size and accountable owner. That inventory gives the migration a defined starting point.
Keep the source and owner connected to the record. Planning and exception decisions need someone who understands the information.
Mapping records the destination, metadata, identity and access for the work. The target and batch show what the execution is meant to accomplish.
Keep those intentions tied to the original inventory. The team needs to compare the result with the move that was actually planned.
Results distinguish migrated, skipped, failed and review-required items. Reconcile those outcomes with the source inventory and planned mappings.
Use exceptions to decide the next action. A summary count is useful only when the team can account for the work behind it.
Inventory, mappings and outcomes belong to the same migration record. They explain what existed, what was intended and what needs attention.
Use that record to explain the migration to the people accepting it. They need to see what arrived, what did not and who will resolve each exception.
Source systems in Matt's delivered migration work. The destination and the treatment of content depend on the project.
Choose a source and destination to explore migrations Matt helped deliver, with his role and the work involved.
All 9 documented projects.
Bring what needs to move, the deadline and what the business cannot afford to lose. We identify what needs investigating before the work is scoped.
Inventory the source, decide what moves and what stays, map identities and permissions, and set the waves and cutover.
Run the pilot and the waves with product tools or reviewed scripts, then report what arrived and resolve the exceptions.
Content your team can find and trust on the first day.
Matt's migration work spans discovery, architecture, tooling and technical escalation. At enterprise scale he plans and shadows while a larger firm implements. Remote first, with visits across Toronto, Mississauga and the Golden Horseshoe.
Tell Matt what needs to move, and by when.