Cross-tenant SharePoint Online migration with Quest On Demand: a practical, end-to-end guide [2025]

Introduction

SharePoint Online powers the document backbone of your organization: libraries, departmental/project sites, modern pages, automations, and metadata that feed search, compliance, and reporting. In a merger or carve-out, migrating SharePoint across tenants is far more than moving files: you must bring over permissions, content types, taxonomy (Term Store), modern pages and their web parts, and the ties to Microsoft Teams—while minimizing impact on users and your security posture.

This guide lays out a proven path with Quest On Demand Migration (ODM), including wave design, pre-staging, coexistence and security controls (Sites.Selected). You’ll also find limits & performance practices, incrementals, KPIs, risks, and operational runbooks so “the day after” is predictable.

1. What is Quest On Demand Migration (ODM) for SharePoint

ODM is an Azure-hosted SaaS platform that centralizes tenant-to-tenant migration for SharePoint Online (alongside OneDrive, Teams, and Exchange). It provides discovery, mapping, wave-based migration, telemetry, automatic retries, and coexistence options via other modules (Directory Sync and Domain/Email Rewrite). For SharePoint, ODM supports migrating sites, lists & libraries, permissions, versions, and metadata (including Enterprise Keywords and Term Store when configured), plus modern pages where API-compatible.

2. Requirements, permissions & security (Sites.Selected)

Before moving a byte, register the source and target tenants in ODM and grant the required application consents for SharePoint/OneDrive (Graph and/or SharePoint APIs). To harden security, implement the Sites.Selected pattern to restrict the app’s access only to approved sites—reducing exposure without slowing the migration. Ensure the right admin roles (SharePoint/Entra), MFA, and Conditional Access that won’t block tooling.

Minimum recommended permissions

• Graph: Sites.Selected (application) + explicit site-level grants; Directory.Read.All for identity lookups.
• SharePoint: app-level permissions to read/write target sites; ODM provides per-workload consent templates.
• Term Store: Term Store Administrator role in both tenants if you’re migrating taxonomy.

Tip: enforce least privilege with Sites.Selected, keep a per-wave allowlist of sites, and automate grant/revoke as waves progress.

3. Project methodology & governance

A wave-based approach reduces risk and drives fast learning: pilot → non-critical areas → critical areas → stabilization. Define a RACI (IT, security, business, partner), review dependencies (Teams, Power Platform, Purview), and agree business change windows. Pair success criteria across technical metrics (errors, throughput, batch time) and user experience (valid links, access times, satisfaction).

4. Discovery, inventory & architecture signals

Run ODM discovery to list sites, owners, content size, item counts per library, version usage, content types, and managed metadata (MMD). Identify hub sites, sites with external sharing, automations (Power Automate) and customizations (SPFx).

Critical volumetrics

• Per site: total size (GB), # of libraries, projected long paths.
• Per library: item count, average & max versions.
• Permissions: # of unique permission scopes and broken inheritance.
• Taxonomy: use of Enterprise Keywords and MMD columns.
• Teams: sites connected to key teams/channels.

5. ODM preparation: project, tenants, matching & scoping

1. Create the project in ODM and select the SharePoint workload.
2. Connect tenants (source/target) and grant consents (including Sites.Selected).
3. Identity matching (UPN→UPN or CSV) for owners and groups.
4. Scope: sites per wave, ordering, and off-peak windows.
5. Lab test: a small site featuring versions, unique permissions, and a modern page.

If you run hybrid identities, document ImmutableID/mS-DS-ConsistencyGuid to prevent mismatches.

6. Content & metadata: libraries, versions, columns & MMD

Decide your versioning strategy: latest only, last n (2, 5, 10, 30, 60, 90, 365) or all versions with size caps. Heavy version histories lengthen the window; offset with pre-staging and dedicated waves. For Managed Metadata, migrate the Term Store first (or in parallel) to preserve Enterprise Keywords and MMD columns.

Good practices

• Normalize names/paths to avoid blocks (illegal characters, full path ≤ 400 characters).
• Clean versions with little business value if files have hundreds of versions.
• Enterprise Keywords: ensure the feature is enabled at site collection level and map the Term Store.
• Content types: freeze schema changes during the wave.

7. Permissions, external sharing & key limits

ODM preserves most site, library, folder, and item-level permissions where APIs allow. Review owners/members/visitors, SharePoint groups, external invitations, and broken inheritance. Plan a post-wave recertification (owners validate who still needs access).

8. Modern pages, web parts & SPFx

Modern pages migrate when API-compatible. Some web parts require re-anchoring/re-configuration (e.g., Power BI, Viva, list web parts filtered by path). Review third-party SPFx and re-deploy packages in the target tenant.

• OneNote: validate permissions and links post-migration.
• Classic wikis: move to modern pages or OneNote.
• SPFx: inventory solutions, dependencies, and scope (tenant/site).

9. Teams-connected sites & channel relationships

Files in standard channels live in the team’s SharePoint site (the “Documents” library). Private/shared channels have their own, separate SharePoint sites; plan their treatment (migrate separately and re-configure tabs). If the Team migrates in a different wave, freeze new channel creation temporarily to avoid forks.

10. Executing the migration with ODM (step by step)

1. Select sites for the wave (size/criticality/external sharing).
2. Set options: versions (latest / n / all), conflict resolution, list comments, auto-retries.
3. Migrate Term Store if applicable (multi-geo: per region).
4. Launch the batch in an off-peak window and monitor telemetry (migrated items, errors, retries).
5. Validate with owners: access, views, modern pages, external links.
6. Run a delta before go-live and freeze changes in the source during cutover.

Tip: split very large or high-version libraries into sub-batches to maximize throughput and isolate retries.

11. Throughput, limits & throttling

Microsoft enforces quotas and throttling for SharePoint/Graph. Right-size concurrency per wave, honor back-off, and schedule off-peak. Avoid views that breach the 5,000-item threshold; use indexes, filters, and folders as needed. Always respect 400-character path and 250 GB file limits in planning.

• Concurrency: distribute by site/library, not only by site count.
• Retries: leverage ODM’s automatic retries and pre-go-live catch-up.
• Long paths: remediate before moving to prevent blocks.

12. Incrementals, retries & delta windows

Keep data drift small by scheduling incrementals frequently. ODM uses SharePoint change tracking to compute deltas; run regular deltas so tokens remain valid. Enable automatic re-run at list level to pick up missing items.

13. Functional validation (UAT) & acceptance

• Access: correct owners/members/visitors; key guests working.
• Content: library item counts; versions surfaced per policy.
• Metadata: MMD columns resolved; Enterprise Keywords present.
• Pages: web parts load (OneNote/Power BI/List); links updated.
• Performance: views below threshold; search returns expected results.

14. Operational checklists (pre, during, post)

Before

• Tenants connected; consents (Graph + Sites.Selected + SPO).
• Identity matching (UPN/CSV); target licenses assigned.
• Inventory with volumes, permissions, MMD and critical pages.
• Waves and windows defined; role-based comms plan.
• Term Store mapped (if applicable) and pilot complete.

During

• Monitor tasks; remediate errors and retries.
• Pre-go-live delta; freeze sensitive changes in source.
• Validate with owners (access, views, pages, links).

After

• Recertify permissions and external sharing.
• Re-index/search if needed; verify analytics.
• Role-based training and week-1 hypercare.

15. Success KPIs

16. Common risks & mitigations

17. Snippets, CSV & PowerShell helpers

SourceSiteUrl,TargetSiteUrl,OwnerUPN,Hub
https://source.sharepoint.com/sites/Marketing,https://target.sharepoint.com/sites/Marketing,ana.perez@target.com,Comms-Hub
https://source.sharepoint.com/sites/Projects,https://target.sharepoint.com/sites/Projects,diego.ruiz@target.com,PMO-Hub

# Requires Microsoft Graph PowerShell and an app registration with Sites.Selected
Connect-MgGraph -TenantId "<TenantId>" -ClientId "<AppId>" -CertificateThumbprint "<Thumbprint>"
$app = Get-MgServicePrincipal -Filter "appId eq '<AppId>'"
$site = Get-MgSite -SiteId "<SiteId>"
# Grant WRITE to the app on this site
New-MgSitePermission -SiteId $site.Id -Roles @("write") -GrantedToIdentities @{ application=@{ id=$app.Id; displayName=$app.DisplayName } }

Latest | n versions (2..365) | All (with per-version size limit)

18. Frequently asked questions

19. Official resources

• Microsoft — Overview of large lists & libraries
• Microsoft — SharePoint Online limits
• Microsoft — OneDrive/SharePoint restrictions & limitations
• Microsoft Graph — Selected permissions (Sites.Selected)
• Microsoft — Avoid throttling in SharePoint Online
• Quest — On Demand Migration (User Guide)
• Quest — ODM Permissions Reference (incl. Sites.Selected)
• Microsoft — Cross-tenant SharePoint migration (preview)
• Microsoft — Teams & SharePoint integration

20. Conclusion & next steps

Migrating SharePoint across tenants with Quest On Demand is straightforward when you nail the basics: consents and Sites.Selected, taxonomy first, waves with pre-staging, clear limits & thresholds, and owner-led UAT. Add measured incrementals and honest comms, and your go-live becomes predictable.