PLATFORM · SHAREPOINT FULL-SITE

SharePoint to SharePoint, with everything that matters.

Migrating a single document library is easy. Migrating a SharePoint site the way a business actually uses it — with its content types, list views, list items, pages and web parts, version history, and the cross-tenant permissions map that ties it all together — is where most tools fall apart or force you to pay five figures for “pro” features. Full Site Migration in MigrationFox handles the full shape of a site, honestly scoped, in one job.

What Gets Migrated

Content Types and Site Columns

Content types are the schema that makes a SharePoint site feel like a SharePoint site. We enumerate every site-scoped content type (custom ones, not the OOB Document or Item) via the Graph contentTypes collection, replay the site columns they depend on, then create the content types in the destination site before any list item or file is created. Lists are then bound to the correct content type so that custom columns survive the move.

Lists, Libraries, and Items

Every custom list and document library on the source site is recreated with the same internal name, the same column set, and the same content type bindings. List items are migrated with all their field values — including people/group fields (resolved against the destination tenant, see below), lookup fields, managed metadata, and hyperlink/picture fields. Document libraries bring across every file with full binary fidelity and the metadata columns you have attached.

List Views

The views users actually use — “My Items”, “By Project”, “Overdue” — are enumerated via the Graph views endpoint and recreated on the destination list. View type (standard/calendar/gantt), column order, sort order, filter CAML, row limit, and default-view flag are all preserved. Grouping and subtotals come across for the view types Graph exposes.

Site Pages with Web Parts

Modern site pages are migrated as pages, not as .aspx downloads. We use the Graph pages endpoint to read the canvas layout, enumerate every web part on the page, and recreate each one on the destination with its properties. Text web parts, image web parts, Highlighted Content, list/library viewers, Quick Links — all supported. Third-party SPFx web parts are migrated by reference (same package ID, same properties); if the package is not installed in the destination tenant, the page loads with a placeholder and the web part is flagged in the job report for you to install.

Version History

Version history is captured as a JSON snapshot attached to each item in the destination. For each source version we record the version number, modified-by display name, modified-by UPN, modified timestamp, and the version’s field values at that point. For document library items we also capture the version size in bytes. The snapshot lands as a sidecar JSON in a dedicated _VersionHistory document library on the destination site so auditors can see what changed and when, even though the native version stack on the new item starts at 1.0.

This is a deliberate trade-off. Read Graph limitations, honestly below for why.

Cross-Tenant Permissions Mapping

Permissions are the hardest part of any tenant-to-tenant move because UPNs usually change. MigrationFox lets you upload a user-mapping CSV (source_upn,dest_upn) and a group-mapping CSV (source_group,dest_group), and every permission assignment on the source site is rewritten against the destination directory as the permissions are applied. Unmapped principals land on an exceptions list instead of silently disappearing — you see exactly which accounts did not have a destination mapping before the site goes live.

Graph Limitations, Honestly

The Microsoft Graph and SharePoint REST APIs do not let a third-party tool preserve every property that ShareGate achieves through the SharePoint Migration Tool (SPMT) stream format. The two specific ones that matter to most customers:

• modifiedDateTime cannot be overridden on create. When we POST a new item to a destination list, Graph stamps it with the current server time. There is no supported request property to set it to the original value. The original timestamp is preserved in the version-history JSON sidecar so nothing is lost, but the top-level column will read today’s date.
• Original Author / Created By cannot be set to an arbitrary user. The item’s author is whichever service principal is running the migration. The original author is captured in the version-history JSON and we also write it to a custom column (OriginalAuthor) if the list schema allows, but the native Author column reflects our service principal.

The only way to fix both of these at the tenant level is to use SPMT’s proprietary migration packages, which bypass the normal create path. That path is on our roadmap — not shipped. If perfect top-level metadata parity is a hard requirement for your migration, talk to us before you start and we will be honest about whether Full Site Migration is the right fit today.

What you keep: every bit of content, every custom column, every list view, every page, every web part, every permission, and a full audit trail of history. What you lose: the top-level Modified and Created timestamps on newly recreated items. Choose with your eyes open.

Typical Workflow

1. Connect both tenants. Azure AD app registration on each side with Graph Sites.FullControl.All. Admin consent is required to write site schemas.
2. Upload mapping CSVs. User and group UPN maps. Unmapped principals are surfaced before the job starts, not after.
3. Pre-flight. MigrationFox enumerates content types, lists, views, and pages on the source and produces a dry-run report: what will be created, what will be skipped, what third-party SPFx packages are missing on the destination.
4. Schema first. Content types, site columns, lists, and views are created on the destination site before any item moves.
5. Items and files. List items, document library files, and page content migrate in parallel with verified writes.
6. Permissions replay. Every role assignment is applied last, against the mapped destination principals.
7. Report. One JSON/HTML/CSV report per run: what moved, what was skipped, what hit the exceptions list.

Related

• SharePoint migration best practices: 2026 edition — sequencing, audit, and cross-tenant UPN strategy
• SharePoint platform overview — general SharePoint source/destination
• Bulk mail migration with user mapping — same UPN-mapping pattern for mail