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 — native or sidecar

Two paths, pick per job in the wizard:

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, delegated OAuth sign-in, Azure Blob staging (we can provision it). Tick the toggle on the Options step.
Version-history sidecar (default). A JSON snapshot per item in a dedicated MigratedVersionHistory multi-line column. Records version number, modified-by UPN, modified timestamp, field values, and byte size per version. Works across any tenant pair and any auth mode; auditable even when True History Mode is not available.

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.

Two auth paths, one wizard

Pick the path that matches the job:

Graph path. Service account or user-OAuth through Microsoft Graph. Works across any tenant pair — same-tenant, cross-tenant, GCC, GCC High. Fast, scriptable, ideal for bulk content moves and automation. 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 full version-stack timestamps preserved on the destination. Same-tenant SharePoint only, delegated OAuth sign-in required, and an Azure Blob staging account (which we can provision for you).

Both paths share the same scanner, the same phase ordering, the same pre-flight report, and the same post-run report. Switching between them is a toggle in the wizard — not a second tool to learn.

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 version history — with original authors and timestamps when True History Mode is enabled, and in the sidecar column when it isn’t.

Typical Workflow

Connect both tenants. Azure AD app registration on each side with Graph Sites.FullControl.All. Admin consent is required to write site schemas.
Upload mapping CSVs. User and group UPN maps. Unmapped principals are surfaced before the job starts, not after.
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.
Schema first. Content types, site columns, lists, and views are created on the destination site before any item moves.
Items and files. List items, document library files, and page content migrate in parallel with verified writes.
Permissions replay. Every role assignment is applied last, against the mapped destination principals.
Report. One JSON/HTML/CSV report per run: what moved, what was skipped, what hit the exceptions list.

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