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 what Full Site Migration (our ShareGate-parity product) is built on.

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 (as a JSON sidecar)

Version history is captured as a JSON snapshot attached to each item, written to a dedicated _VersionHistory library on the destination site. For each source version we record the version number, modified-by UPN, modified timestamp, field values at that version, and (for files) the version size in bytes. The native version stack on a newly created item in Graph starts at version 1.0 — that is an API limit, not a tool limit — and the sidecar is the defensible audit trail.

If you need true native version-stack preservation (SPMT “Insane Mode” equivalent), that capability is on our roadmap but is not shipped today. We are telling you that so you can choose with your eyes open.

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.

Comparison: MigrationFox vs SPMT vs ShareGate

Honest, feature-level comparison against the two tools most customers evaluate next to us. We have flagged the places where SPMT or ShareGate genuinely does something we do not (yet).

Where the table says “Sidecar JSON (roadmap: native)” — that is the honest summary of where we are on version history. If true native version-stack preservation is a hard requirement for your regulatory position, SPMT is the tool today. We acknowledge it and will tell you out loud. We are building toward parity on that capability through a migration-package write path, but it is not shipped yet.

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.

Graph Limitations, Honestly

Two limits are worth stating clearly because they are Graph-level, not tool-level, and no REST-based migration can fix them today:

• modifiedDateTime cannot be overridden on create. New items get the current server time. Original timestamp is preserved in the version-history JSON sidecar but the top-level column reads today’s date.
• Original Author / Created By is the service principal running the job. Captured in the sidecar; can optionally be written to a custom OriginalAuthor column on the destination list. Native Author column reflects our service principal.

If top-level metadata parity is the deal-breaker on your migration, use SPMT. We will not pretend REST can do something it cannot.

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 ShareGate-parity product built on this path
• 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%