PLATFORM · SHAREPOINT SITE MIGRATION

SharePoint Site Migration — the whole site, not just its files.

The SharePoint platform page is about moving file libraries. This page is about moving a full SharePoint site — libraries, lists, content types, views, version history, site pages, web parts, and cross-tenant permissions — as a single coordinated job with the right phase ordering and the right honest trade-offs around what the Graph API can and cannot preserve.

If you are consolidating tenants, spinning out a division, cleaning up after an acquisition, or just moving off a legacy SharePoint into a fresh tenant with proper Copilot governance, Site Migration is the path. It is the coordinated, schema-first workflow that underlies every full SharePoint site job we run.

What Gets Migrated

Document libraries

Every document library on the source site is recreated on the destination with the same internal name, the same custom columns, the same content type bindings, and the same folder structure. Files are transferred with full binary fidelity, and custom metadata columns survive the move. Folder-level unique permissions are captured and replayed during the permissions phase.

Custom lists and list items

Custom lists migrate with their full schema: column definitions, content type bindings, indexing, and default values. Every list item carries its field values across — people fields (resolved via UPN mapping), lookup fields, managed metadata, hyperlink, picture, and calculated column values. Items that fail on an individual read-only or system field are retried with progressive field stripping rather than failing the whole item.

Content types and site columns

Custom content types at the site scope are enumerated via Graph and recreated on the destination before any list or item is written. Site columns they depend on come first, then the content types themselves, then lists bound to those content types. This is the standard schema-first sequencing and it is enforced by the migration engine — you cannot accidentally get it wrong.

List views

Every custom view on every list is recreated on the destination with its column order, sort order, filter CAML, row limit, grouping, and default-view flag preserved. Standard, calendar, and gantt views are supported. Views are created after items exist so the filter CAML evaluates against a populated list.

Site pages and web parts

Modern site pages are migrated through the Graph pages API as structured canvas layouts, not as copy-paste HTML. Sections, columns, and web parts are preserved. Text, image, Highlighted Content, list-viewer, Quick Links, People, Events, and Banner web parts all come across with their property configurations intact. List-viewer references are rewritten to point at the destination list IDs. Third-party SPFx web parts migrate by reference — the destination tenant needs the same .sppkg installed for the web part to render, and the pre-flight report tells you which packages are missing. Read the full writeup in Migrating SharePoint Site Pages.

Version history — native or sidecar, your choice

MigrationFox ships two version-history paths and you pick per job:

• True History Mode (native) — the destination list keeps the original Author, Editor, Created, Modified, and full version-stack timestamps exactly as they were on the source. Implemented through Microsoft’s native SharePoint Migration API (SPMT / PRIME) with manifest packaging, Azure Blob staging, snapshot-backed content blobs, and integer-ID user mapping. Tick the toggle in the wizard; requires same-tenant SharePoint source + destination and an Azure Blob staging account (or let us provision one for you).
• Version-history sidecar (default) — a JSON snapshot per item written to a dedicated MigratedVersionHistory multi-line column. Records version number, modified-by UPN, modified timestamp, field values at each version, and version byte size. Works across any tenant pair and any auth mode. The native version stack on newly created items starts at 1.0 (a Graph limit, not a tool limit); the sidecar is the audit trail when True History Mode is not available.

Cross-tenant permissions

Permissions are replayed as the last phase, against a CSV user-map and group-map you upload. Unmapped principals land on an exceptions list with three choices per principal: drop, map inline, or invite as B2B guest. See the full writeup in Cross-tenant SharePoint permissions without user-mapping hell.

Phase Ordering (enforced)

Schema first, items next, pages, then permissions. The engine runs the phases in this order and the next phase does not begin until the previous phase is clean:

1. Schema phase. Site columns → content types → lists → list columns → content type bindings.
2. Item phase. List items + document library files, in parallel where possible.
3. View phase. List views, after items exist so filter CAML evaluates cleanly.
4. Pages phase. Site pages with web parts, after lists exist so list-viewer references rewrite correctly.
5. Permissions phase. Cross-tenant principal resolution + role replay, last, with exception list surfaced before any write.

Phase ordering is the thing most migrations get wrong. Moving files before the content types exist means the files land with the wrong schema. Writing pages before lists exist means the Highlighted Content web parts are empty. Applying permissions before items exist means there is nothing to lock down. Get the order right or redo the weekend.

What you get

Typical Workflow

1. Connect both tenants. Azure AD app registration on each side. Graph scopes Sites.FullControl.All, Sites.Manage.All, plus delegated scopes for user/group resolution.
2. Upload mapping CSVs. user-map.csv and group-map.csv. Unmapped principals surface before the replay runs.
3. Pre-flight. The engine enumerates content types, lists, views, pages, and permissions on the source, produces a dry-run report, and flags: missing SPFx packages on the destination, unmapped principals, and any list schemas the destination tenant policy will reject.
4. Schema phase. Columns, content types, lists, bindings.
5. Item phase. Items and files, with bounded parallelism and 429 back-off.
6. View phase. List views against the populated lists.
7. Pages phase. Site pages, canvas layout, web parts, promoted state.
8. Permissions phase. Role replay against mapped principals; exceptions handled per your pre-flight decisions.
9. Report. JSON/HTML/CSV migration report: what moved, what was skipped, what hit the exceptions list, block-level verification for files.

Speed

The site migration path shipped an 18-fix performance pass in April 2026. On the tenants we have measured, mid-size SharePoint site migrations now complete in roughly half the wall-clock time they used to take. The detail is in the speed-fixes blog post, but the short version: Graph $batch for metadata, bounded p-limit parallelism with 429 back-off, undici keep-alive with HTTP/2 multiplexing, and request deduplication on the governance path.

Two auth paths, one wizard

Pick the path that matches the job:

• Graph path (default). Service-account or user-OAuth through Microsoft Graph. Works across any tenant pair, fast, scriptable, great for bulk content moves. Top-level Author and Modified columns on newly created list items reflect the migration account; original values live in the version-history sidecar column.
• True History Mode. Runs the site through Microsoft’s native SharePoint Migration API. Original Author / Editor / Created / Modified and the full version stack are preserved on the destination exactly as they were on the source. Same-tenant SharePoint only, delegated OAuth sign-in required, and an Azure Blob staging account (we can provision one). Toggle it on the Options step.

Both paths share the same scanner, the same phase ordering, the same pre-flight, and the same report. You switch paths by ticking a toggle — you do not learn a second tool.

Pricing

SharePoint site migrations are billed per GB transferred, same as the rest of our platforms. A free workspace includes enough capacity to dry-run a site and migrate a small pilot without payment. See the pricing page for current rates and bundle options.

Related

• Full SharePoint Site Migration — the complete site + permissions + True History workflow
• SharePoint platform overview — libraries-only source/destination
• SharePoint migration best practices: 2026 edition
• Migrating SharePoint Site Pages: why canvas layout matters
• Cross-tenant SharePoint permissions without user-mapping hell
• How MigrationFox cut SharePoint migration time by ~50%