Microsoft 365 cross-tenant SharePoint migration (tenant-to-tenant): the complete guide to move sites, permissions, and content without losing control

Quick summary: SharePoint tenant-to-tenant migration in 11 points

1. Define the real driver: merger/acquisition, carve-out, rebrand, consolidation, group/organization change, legal or sovereignty requirements.
2. Choose a strategy: Microsoft-native cross-tenant migration, a third-party tool, or a mixed approach with redesign (when it’s worth improving the model).
3. Do a serious inventory: sites, hubs, libraries, lists, customizations, SPFx, Power Automate flows, Power Apps, external sharing, and sensitive content.
4. Target architecture: hub model, sites per business area/process, libraries per document type, naming and ownership (avoid “one site for everything”).
5. Identity and mapping: prepare users and groups in the target tenant and build identity mapping so permissions work after the move.
6. Trust between tenants: establish the trust relationship and verify its status before launching large batches.
7. Site-by-site compatibility: validate compatibility and resolve warnings before moving (fixing issues early beats “dragging problems” into the target).
8. Wave-based plan: representative pilot → progressive waves → stabilization; communication and close support at key moments.
9. Realistic post-migration: validate navigation, search, permissions, related Teams usage, flows, and review external sharing.
10. Compliance: review Purview (sensitivity/retention/DLP) and recreate what doesn’t migrate automatically.
11. Orderly closure: remove trust when no longer needed, clean up redirects when appropriate, and leave an operating governance model so the environment doesn’t degrade over time.

When is a SharePoint tenant-to-tenant migration needed?

Not every organization needs a SharePoint Online cross-tenant migration. But when two or more tenants exist (due to history, legal structure, or acquisitions), there is often a point where running duplicated SharePoint environments creates cost, risk, and friction: content scattered across tenants, permissions that are hard to audit, and users who no longer know “where the official version lives.”

Typical scenarios

• Mergers and acquisitions (M&A): consolidating intranet, operational documentation, and project spaces into one environment.
• Carve-out / spin-off: separating part of the business and moving only specific sites and content into a new tenant.
• Tenant consolidation: multiple historical acquisitions created multiple SharePoint instances and centralized governance is now required.
• Rebranding or organizational change: unifying identity, navigation, and repositories.
• Compliance or regional requirements: internal policy changes, audits, or regulatory needs that make moving data to another tenant advisable.

The clearest signal that a formal project is needed

When the organization cannot easily answer basic questions such as: “Which site is the official one?”, “Who has access to contracts?”, “Where is the current approved procedure published?” or “What is shared with vendors?”, the problem is usually not technical—it is governance. A migration becomes an opportunity to put structure in place.

Transition summary: before discussing commands or tools, it is essential to clarify why the migration is happening and what “success” means (consolidation, separation, risk reduction, or governance improvement). With that objective clear, the introduction explains which SharePoint elements are affected and why “the day after” matters as much as the move itself.

Introduction: what actually moves in a SharePoint cross-tenant migration

The phrase SharePoint tenant-to-tenant migration often sounds like “moving sites.” In practice, what is moved (or what must be reviewed) is broader: content, permissions, shared links, navigation, search, and dependencies (Teams, Power Platform, integrations, and automation).

A site is not just a URL. A site typically includes: libraries with versioning, lists that support business processes, pages (communication/intranet), approvals, group-based permissions, external guests, and often a relationship with a Microsoft 365 Group (especially when the site is connected to Teams).

Why “unexpected” issues happen without a plan

• Permissions: moving to another tenant changes the identifiers for users and groups. Without the right mapping, content may migrate but access does not “line up.”
• Links: shared links and references in emails, wikis, or Teams tabs may continue pointing to the source if redirects are not handled properly or if URL/naming changes.
• Automation: Power Automate and Power Apps are often tied to connections and environments; moving tenants can require re-authentication and adjustments.
• Compliance: labels, retention, and DLP require deliberate handling to avoid losing consistency or creating gaps.

Transition summary: a SharePoint cross-tenant migration impacts content, identity, links, and processes. The next step is to define methodology: roles, waves, architecture decisions, and a way to validate with business stakeholders.

1. Project methodology: waves, roles, and decisions that prevent surprises

In practice: a SharePoint tenant-to-tenant migration succeeds when it is delivered in waves, with a real pilot and validation by business owners—not only IT.

In SharePoint, the main risk is rarely “a copy failing.” The real risk is that after the move the client ends up with: inconsistent permissions, sites with no clear owner, links still pointing to the old environment, or broken internal processes. To reduce that risk, a wave-based approach works well: representative pilot → progressive waves → stabilization.

1.1 Decisions to finalize at the beginning

• Lift-and-shift vs clean-up: if the source is messy, copying it simply transfers the problem into the target.
• URL structure continuity: changing URLs can be beneficial, but increases communication effort and reference review.
• What happens to legacy sites: define read-only, redirects, or retirement aligned to policy.
• What is “critical”: contracts, HR, finance, quality, active projects, vendor portals… to prioritize support and validation.

1.2 Recommended RACI (indicative)

1.3 How to validate a wave (beyond “it looks fine”)

• Role-based access: business owners confirm that editors/readers can work without ad-hoc “manual permissions.”
• Flows and processes: if approvals/automation exist, run a real scenario with test data.
• External sharing: if the site is shared externally, validate real access from an invited account.
• Search and navigation: typical documents are discoverable without requiring users to know the folder tree.

Transition summary: methodology and validation turn the project into a controlled change rather than a “copy job.” The next step is inventory: without a proper assessment it is easy to miss dependencies (flows, guests, hubs, customizations) that later become incidents.

2. Assessment and inventory: knowing what exists before moving a single site

In practice: assessment answers three questions: what exists, what depends on what, and what should not be touched without a clear validation plan.

SharePoint inventory is not just counting sites. It is understanding: which sites are active, who “owns” them, which libraries contain sensitive content, what is shared externally, and what automation depends on that content.

2.1 What to inventory (minimum useful set)

• Site and hub map: hub associations, intranet, communication sites, team sites (often connected to Teams).
• Volume and complexity: size, item counts, libraries with many versions, large lists, heavy-use content.
• Permissions: groups in use, broken inheritance, direct user permissions (if any), and libraries with special permissions.
• External sharing: guest count, sites shared with vendors/customers, link policy and expiration.
• Automation: Power Automate flows, forms, Power Apps, ERP/CRM integrations, connectors with credentials.
• Customization: SPFx, custom web parts, critical modern pages, templates, scripts, themes, customized navigation.
• Compliance: sensitivity/retention labels, DLP, eDiscovery, audit, regulatory requirements.

2.2 Typical assessment deliverables (to enable decision-making)

Transition summary: assessment turns “let’s move SharePoint” into a plan with priorities, dependencies, and validation. With that inventory, it becomes possible to select the right strategy: Microsoft-native, third-party, or a mixed approach (often the most realistic in complex environments).

3. SharePoint cross-tenant migration strategies: Microsoft-native vs third-party vs mixed

In practice: tools should be chosen based on objectives (consolidate, separate, improve governance), not trends. Sometimes “move” is best—and sometimes “rebuild” with selective migration is the right move.

3.1 Microsoft-native approach (cross-tenant SharePoint migration)

Microsoft provides a native method for cross-tenant SharePoint site migration using PowerShell and a trust relationship between tenants. It is a strong option when requirements and limits fit, and when the project prefers a Microsoft-supported capability rather than relying on a third party.

3.2 Third-party tools (when more flexibility is required)

For environments with significant customizations, advanced reporting needs, transformations (reorganizing information), or extended coexistence, it is common to use specialized tools. The advantages often include: complex mappings, transformations, granular retries, and tracking dashboards.

A frequent approach is to combine methods: move “standard” sites with the best-fitting approach, and handle special cases with a different path.

3.3 Mixed approach (very common in real organizations)

• Controlled lift & shift for simple, well-governed sites.
• Redesign for intranets or environments that were already disorganized (rebuild navigation and publish “clean” content).
• Selective migration of critical libraries while archiving the rest (avoid bringing obsolete content into the target).

3.4 Quick comparison (to decide with criteria)

Transition summary: once the strategy is selected, the next step is understanding the native method in detail (if used): requirements, licensing, and limits. Knowing these early prevents designing a plan that later forces a mid-project “lane change.”

4. Microsoft-native cross-tenant SharePoint migration: requirements, licensing, and limits

In practice: the native method performs very well when the scenario fits, but the limits should be reviewed carefully to avoid discovering them at the worst moment.

4.1 Licensing (often overlooked)

Microsoft-native cross-tenant SharePoint migration may require specific licensing for cross-tenant migration (depending on the client’s program and tenant setup). This impacts scheduling: if licensing is acquired late or left until the end, the project can stall when everything else is ready.

4.2 Typical limits and conditions (plain-language summary)

• Compatibility: prior to migration, the source-to-target compatibility status must be checked.
• Batching: migrations can be queued in batches (batch limits apply; multiple runs should be planned).
• Size and item counts: site size and item limits influence wave ordering.
• No continuous incremental sync: the method is intended for controlled migration (preflight + execution), not continuous synchronization.
• Encryption / Customer Key: advanced encryption scenarios may block native migration and require an alternative.
• Target and URL constraints: target URLs must meet requirements; in certain cases, the target must not already exist.

4.3 What happens during and after (what users notice)

• During migration, the source site may be placed into read-only to ensure consistency.
• After completion, redirects can be created so users entering the old URL are sent to the new target URL (depending on Microsoft’s native flow).
• Shared links for migrated content can be redirected to the new destination, but real scenarios should be validated (internal and external).

Transition summary: once requirements and limits are accepted, the target tenant must be prepared: architecture, hubs, baseline security, and governance. The target should not be “an empty container”; it must be ready to receive sites without becoming another ungoverned SharePoint.

5. Preparing the target tenant: architecture, baseline security, and governance

In practice: even the best migration fails if the target lacks ownership, naming, sharing rules, and a hub model that helps users navigate.

5.1 Recommended architecture (avoid “everything inside one site”)

• Hubs by area or function: Operations, Sales, Finance, HR, Quality, IT, Projects.
• Communication sites: intranet, policies, and official procedures (published content).
• Team sites: daily collaboration, in-progress documentation, projects (often connected to Teams).

5.2 Minimum viable governance (must be defined)

• Ownership: each site has a business owner and a technical owner.
• Naming: conventions for sites, libraries, and groups (support and scale depend on this).
• Permissions: group-based, least privilege, controlled inheritance.
• External sharing: policy by site type (internal vs external collaboration), with expiration and guest controls.
• Lifecycle: provision, operate, archive, retire (especially for projects).

5.3 Baseline security before opening access

Before receiving content, establish a security baseline: MFA and Conditional Access (aligned to client policy), external sharing review, and clear criteria for “third-party sites.” If the target allows uncontrolled sharing, migration can increase exposure rather than reduce it.

Transition summary: with the target prepared, the next critical factor is identity: users, groups, and roles must exist (and be mapped) so that source permissions make sense in the target.

6. Identity and permissions: preparing users, groups, and roles (without falling into manual permissions)

In practice: if content migrates but groups are not prepared properly, the result is a flood of “I don’t have access” tickets and endless manual fixes.

6.1 Identity decisions to finalize before migration

• UPN and domains: how users will be represented in the target tenant (keeping addresses where possible reduces friction).
• Groups: which groups are recreated (or newly created) in the target tenant and based on what model (area, role, process).
• Owners: who will own each site in the target tenant (few and clear).
• External guests: approach for existing guests: keep, recreate, or clean up by project/case.

6.2 Permission principles that survive migration best

• Role-based groups (owners/editors/readers) and avoid individual permissions except for justified exceptions.
• Inheritance by default; break it only when necessary (and documented).
• Access recertification for sensitive libraries (e.g., contracts and finance).

6.3 Microsoft 365 Group-connected sites (and Teams): why they need special attention

When a site is connected to a Microsoft 365 Group, the group’s owners and members drive much of the access model. Therefore, migrating these sites requires preparation for how groups are created in the target tenant and how they are aligned (aliases, owners, membership).

Transition summary: with identity decisions made, the next technical prerequisite of the native method is trust between tenants. Trust enables the move and is required before executing migrations and before identity mapping can work reliably.

7. Establishing trust between tenants for SharePoint migration (cross-tenant trust)

In practice: trust is the “bridge” between tenants. Without verified trust, native migration does not start reliably.

In Microsoft’s native approach, a trust relationship is configured between the source tenant and the target tenant. This is not a minor detail: planning must define who executes it, with which roles, and how to validate it is correctly in place.

7.1 Connect to SharePoint Online (source and target)

# Source
Connect-SPOService -Url https://SOURCETENANT-admin.sharepoint.com

# Target (in another session or by switching credentials)
Connect-SPOService -Url https://TARGETTENANT-admin.sharepoint.com

7.2 Establish trust (concept and caution)

Trust is configured on both sides following Microsoft’s native flow. The key is: identifying the correct partner Cross-tenant host URL and running the command with the correct scenario parameters.

7.3 Verify trust is truly established

After configuration, trust status is checked to confirm both tenants “see” each other and the scenario is ready for migration. This verification must be part of the checklist; avoiding “assuming it’s done” saves many hours.

Transition summary: with trust in place, the next critical piece is identity mapping: the file that tells the migration which source user/group corresponds to which target user/group.

8. Identity mapping in a SharePoint tenant-to-tenant migration: the critical point for permissions to work

In practice: a well-built identity mapping prevents most post-migration access incidents.

In cross-tenant migrations, users and groups change their internal IDs. Even if a user “looks the same,” the underlying identifier is different in the target tenant. Identity mapping ensures owners and permissions are reassigned correctly.

8.1 Preparation: precreate users and groups in the target tenant

Before mapping, users and relevant groups must exist in the target tenant. The usual approach is: create critical users and groups first (owners, editor/reader/security groups, Microsoft 365 Groups connected to Teams).

8.2 Mapping format (practical view)

In practice, a CSV is prepared with source→target pairs. The key is not “filling a spreadsheet”—the key is ensuring the CSV reflects the real permission model.

SourceObjectId,TargetObjectId,ObjectType
11111111-1111-1111-1111-111111111111,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa,User
22222222-2222-2222-2222-222222222222,bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb,Group

8.3 Rules that help avoid mistakes

• Map owners and key groups before moving critical sites (otherwise content arrives “ownerless”).
• Reduce redundant groups during the project: if there are ten similar groups, the target becomes unmanageable.
• Document exceptions: libraries with broken inheritance, sensitive sites, temporary third-party access.

Transition summary: with identity mapping prepared, the next step is compatibility validation. Compatibility is the gate that indicates whether a site can migrate as-is, will raise warnings, or requires an alternative strategy.

9. Compatibility and preflight: validate before executing a SharePoint cross-tenant migration

In practice: a “Warning” status does not always block migration, but it does require review. Ignoring warnings often becomes post-migration incidents.

Before starting the move, compatibility status must be checked from source toward target. This identifies blockers and warnings early.

# Run from the source tenant (pointing to the target cross-tenant host URL)
Get-SPOCrossTenantCompatibilityStatus -PartnerCrossTenantHostURL https://TARGETTENANT-my.sharepoint.com/

9.1 How to act on the results

• Compatible: plan the site in a standard wave.
• Warning: review the cause; decide whether to accept or fix before moving.
• Not compatible: remove from the native lane and apply an alternative strategy.

9.2 Compatibility best practices

• Prioritize critical sites in the pilot for early compatibility checks.
• Separate “clean sites” and “warning sites” into different waves.
• Avoid letting the calendar decide everything: order should follow criticality and complexity.

Transition summary: once compatibility is reviewed, it is time to execute. In SharePoint, execution should be treated as a queued workload: batches, scheduling, monitoring, and validation at the end of each wave.

10. Execution: starting site moves and Microsoft 365 Group-connected migrations

In practice: execution is not “running a command.” Execution means controlling batches, scheduling windows, monitoring state, and validating with the business.

10.1 Migrating a SharePoint site (site-to-site)

To migrate a site, the source administrator starts the move specifying: source URL, target URL, and the target cross-tenant host URL.

Start-SPOCrossTenantSiteContentMove `
  -SourceSiteUrl  "https://SOURCETENANT.sharepoint.com/sites/ProjectX" `
  -TargetSiteUrl  "https://TARGETTENANT.sharepoint.com/sites/ProjectX" `
  -TargetCrossTenantHostUrl "https://TARGETTENANT-my.sharepoint.com/"

10.2 Migrating a Microsoft 365 Group-connected site (commonly Teams-connected)

When the site is connected to a Microsoft 365 Group, the move starts using the group alias. This is where proper group preparation (and matching aliases) in the target tenant reduces incidents.

Start-SPOCrossTenantGroupContentMove `
  -SourceGroupAlias "team-projectx" `
  -TargetGroupAlias "team-projectx" `
  -TargetCrossTenantHostUrl "https://TARGETTENANT-my.sharepoint.com/"

10.3 Scheduling migrations for a specific time

When controlled windows are needed (for example, outside business hours), migrations can be scheduled by specifying a preferred start/end in UTC. This helps coordinate large batches and aligns support coverage.

Start-SPOCrossTenantSiteContentMove `
  -SourceSiteUrl "https://SOURCETENANT.sharepoint.com/sites/Finance" `
  -TargetSiteUrl "https://TARGETTENANT.sharepoint.com/sites/Finance" `
  -TargetCrossTenantHostUrl "https://TARGETTENANT-my.sharepoint.com/" `
  -PreferredMoveBeginDate "2026-01-18T20:00:00Z"

Start-SPOCrossTenantGroupContentMove `
  -SourceGroupAlias "team-finance" `
  -TargetGroupAlias "team-finance" `
  -TargetCrossTenantHostUrl "https://TARGETTENANT-my.sharepoint.com/" `
  -PreferredMoveBeginDate "2026-01-18T20:00:00Z"

10.4 What to communicate to users during execution

• Whether there will be read-only periods on the source.
• How to access the new site in the target tenant (and which credentials apply).
• What to do if access fails (“I don’t have access”): support channel and expected resolution.
• What will happen to externally shared links during the transition.

Transition summary: once migrations are started, the work becomes monitoring and correction: state tracking, retries, cancellation when needed, and—most importantly—post validation to avoid accumulating “incident debt.”

11. Monitoring and control: states, cancellation, and error handling

In practice: monitoring is what makes migration predictable. Without it, the project turns into a list of surprises.

11.1 Checking migration state

Status can be checked from source or target by pointing to the partner host URL. A consistent internal convention (wave, batch, criticality) helps clarify what is being monitored and which support team should be on alert.

Get-SPOCrossTenantUserContentMoveState `
  -PartnerCrossTenantHostURL "https://TARGETTENANT-my.sharepoint.com/"

11.2 Typical states (to understand what’s happening)

• NotStarted / Scheduled: queued.
• ReadyToTrigger: preflight stage; migration will start shortly.
• InProgress: running (validation, backup, restore, cleanup).
• Success: completed.
• Rescheduled: requeued for another pass.
• Failed: failed; analyze cause and decide retry or change strategy.

11.3 Cancelling a migration (when appropriate)

Cancellation is sometimes needed—for example, if a target error is discovered (wrong URL, unprepared group, wrong window) before the process enters “InProgress.”

Stop-SPOCrossTenantSiteContentMove -SourceSiteURL "https://SOURCETENANT.sharepoint.com/sites/ProjectX"

Transition summary: after the technical move comes the most visible work: post-migration (redirects, links, cleanup, trust removal, functional validation, and stabilization). This phase determines whether the client experiences “order” or “new problems.”

12. Post-migration: redirects, shared links, cleanup, and stabilization

In practice: post-migration protects the user experience. A migration “ends” when daily work is normal again—not when the command returns Success.

12.1 Redirects: why they help (and why they must be managed)

In Microsoft’s native flow, after completion redirects can be created so users accessing the source site land on the new target site. This reduces questions and prevents users from continuing work “in the old place.”

Redirects must still be managed carefully: if later a site or user needs to move back, redirects can create URL conflicts if they are not removed properly.

12.2 Removing tenant trust (when no longer needed)

Once migration is completed and the environment is stable, it is recommended to remove trust to avoid keeping a bridge open longer than required. Licensing timelines associated with the migration scenario should also be considered.

12.3 Post-migration verification (minimum for each critical site)

• Access: owners, editors, readers, and external users (if applicable).
• Libraries: versioning, views, mandatory metadata.
• Shared links: real test with an internal user and (if applicable) a guest user.
• Navigation: hub association, menus, intranet entry points.
• Search: key documents show up with correct permissions.

Transition summary: after SharePoint stabilization, the next block is dependency review: Power Automate, Power Apps, forms, and connections often cause “silent” incidents (nobody notices until a business process fails).

13. Power Automate, Power Apps, and dependencies: what to review to prevent business breakage

In practice: a SharePoint cross-tenant migration can move content, but automated processes often require reconfiguration and functional validation.

13.1 Power Automate: common failure patterns

• Connections: a flow that used a tenant-specific account/connector may require re-authentication in the target tenant.
• References: flows pointing to old URLs or specific lists often require updates.
• Permissions: the flow owner in the target tenant must have equivalent permissions.

13.2 Power Apps and forms

If Power Apps are integrated with lists/libraries, validation should cover: data sources, roles, environments (if Dataverse is involved), and read/write permissions. A common issue is that the app opens but cannot save because the connector points to the old tenant or the user lacks permissions in the target.

13.3 Practical strategy

• Inventory flows/apps by criticality (not everything requires the same level of testing).
• Re-authenticate and review connectors in a controlled window.
• UAT with business owners (real scenarios, not superficial checks).

Transition summary: after dependencies, the next area is customizations: pages, lists, and components. Much may migrate well, but anticipating what needs adjustment prevents intranet or portal regressions.

14. Pages, lists, and customizations: what typically migrates vs what typically needs adjustments

In practice: content moves, but “experience” (navigation, web parts, integrations) may need tuning so users don’t perceive regression.

14.1 Modern pages and intranet

In intranets, the challenge is not only moving pages—it is ensuring: internal links point to the target, components remain available, and hub navigation remains consistent. If the project uses migration as an opportunity to reorganize the intranet, a common pattern is to migrate published content and rebuild navigation with clear criteria.

14.2 Lists and processes

Many organizations use lists as the backbone of business processes (requests, internal incidents, inventories, etc.). Even if content migrates, review is typically needed for: calculated columns, formatting, rules, views, special permissions, and connected automation.

14.3 SPFx and custom components

If SPFx web parts or API integrations exist, moving tenants often requires: reconfiguring permissions, re-registering apps, adjusting URLs, and validating authentication. These components must be included in inventory and UAT planning.

Transition summary: next is compliance: sensitivity labels, retention, and DLP. This is what makes the environment defensible under audit and reduces exposure risks.

15. Security and compliance in SharePoint cross-tenant migration: Purview, retention, and DLP

In practice: compliance is not an “extra.” In audited industries it is part of the success criteria. Even outside regulated sectors, it reduces exposure and organizes the information lifecycle.

15.1 Sensitivity labels (Purview)

Sensitivity labels classify and protect information (for example, Internal, Confidential, Highly Confidential). In cross-tenant migrations, recommended steps include: documenting the labels in the source, defining the target label catalog, and planning re-application where labels do not transfer automatically or where the process requires removing them prior to the move.

15.2 Retention and disposition

Retention defines how long information is kept and what happens afterward (review, deletion, archive). In migration projects, a recommended practice is: agreeing the target retention framework with legal/compliance teams and recreating policies/labels according to the client model, ensuring content does not end up “without rules” after the move.

15.3 DLP (Data Loss Prevention)

DLP helps detect and limit data leakage scenarios such as externally sharing documents containing personal or financial data. Implementation is typically gradual: start in audit mode, measure impact, and harden controls once the client confirms legitimate processes are not blocked.

Transition summary: with security and compliance aligned, the “day after” focuses on experience: links, navigation, search, and access. That’s where users feel whether the environment became “easier” or “more confusing.”

16. Links, navigation, search, and user experience: “the day after” a SharePoint tenant-to-tenant migration

In practice: when a user says “I can’t find anything,” it is almost always a blend of navigation, permissions, and expectations about what is official.

16.1 Internal and external links

• Internal: links in pages, wikis, news, Teams, and archived emails may require review if URLs change.
• External: vendor/customer collaboration requires real tests with guest accounts; review expiration, “specific people,” and target tenant policy.

16.2 Navigation and hubs

If the target uses hubs by function, after migrating each site it is recommended to: associate it to the right hub, review menus, and ensure users can arrive without knowing the URL. This reduces reliance on old bookmarks.

16.3 Search and results

Search performs best when there is: reasonable naming, minimal metadata, and consistent permissions. After migration, validate typical searches by area (contracts by customer, current procedures, invoices by year…), ensuring results respect permissions.

Transition summary: to close the project cleanly, use checklists and KPIs: what is reviewed before/during/after and how success is measured (fewer tickets, correct permissions, processes working).

17. Operational checklists (pre/during/post) and KPIs for SharePoint cross-tenant migration

17.1 Pre-migration checklist (per wave)

• Wave site inventory: owners, criticality, external sharing, dependencies.
• Target ready: architecture, hubs, and sharing policies applied.
• Users and groups precreated in target; identity mapping reviewed.
• Trust established and verified; compatibility checked.
• Wave communication and support plan.
• UAT validation plan (who validates and what scenarios).

17.2 During migration checklist

• Monitor states (Scheduled/InProgress/Success/Failed).
• Log incidents per site and decide actions (retry, adjust, alternative strategy).
• Confirm whether the source becomes read-only and communicate if it affects operations.
• Coordinate with service desk to handle access incidents in real time.

17.3 Post-migration checklist (per critical site)

• Role-based access (owners/editors/readers) validated.
• External sharing validated (if applicable).
• Navigation/hub reviewed; key internal links corrected.
• Dependent flows and apps tested (real scenario).
• Compliance review (sensitivity/retention/DLP aligned to the target model).

17.4 Practical KPIs (business-facing)

Transition summary: finally, it is useful to document common risks and mitigations. Not to alarm stakeholders, but to demonstrate a plan for frequent scenarios (permissions, links, special sites, compliance).

18. Common risks and mitigations in SharePoint cross-tenant migration

In practice: risk is reduced when it is identified early and a decision is made: fix, accept with a plan, or remove from the standard lane.

Transition summary: to close the guide body, the FAQ addresses common questions and official resources support deeper technical validation, followed by a conclusion with practical next steps.

19. FAQ: Microsoft 365 SharePoint tenant-to-tenant migration

20. Official resources and recommended links

• Cross-tenant SharePoint migration overview (Microsoft Learn)
• Step 1: Connect to the source and target tenants
• Step 2: Establish trust
• Step 3: Verify trust is established
• Step 4: Precreate users and groups
• Step 5: Prepare identity mapping
• Step 6: Start a cross-tenant SharePoint migration
• Step 7: Post migration steps
• Microsoft Purview: sensitivity labels
• Related MSAdvance services: Modern Workplace and SharePoint

21. Conclusion and next steps for a SharePoint cross-tenant migration

A Microsoft 365 SharePoint cross-tenant migration is a project about content, identity, and governance. It works when it is supported by: real inventory, an appropriate strategy (native/third-party/mixed), solid identity mapping, wave-based execution, and a post-migration phase focused on experience (permissions, links, navigation, and processes).

Typical next steps include:

• Run an assessment to identify critical sites, dependencies, and risks (external sharing, automation, compliance).
• Define the target architecture (hubs, sites, naming, ownership) before moving content.
• Design a wave plan with a representative pilot and role-based UAT validation.
• Prepare identity and execute with monitoring and stabilization (not only “move”).