Schema-Aware Migration Coverage

What a schema-aware SharePoint migration actually preserves, which structures need the one-click toggles, and the per-web-part fix-up matrix for cross-tenant runs.

What migrates out of the box

Every SharePoint & OneDrive migration via the schema-aware wizard preserves the following with no additional configuration:

• Document libraries — including folder structure, file content, and all version history (current + prior versions, with the original Created / Modified dates per version).
• Generic lists — list definition (columns, types, default values), list items (all rows), and per-item metadata (Title, custom columns, lookups within the same site).
• List views — the default "All Items" view plus any custom views (sort, filter, column selection). Complex CAML view definitions copy on a best-effort basis — very intricate views may render slightly differently on the destination but the data the view filters is always intact.
• Native file version history — SharePoint's version chain (major + minor versions) is recreated at the destination via the SharePoint Migration API. Each version retains the original author and timestamp.
• File metadata — Created, Modified, Created By, Modified By, and any custom columns defined on the source library.

What needs the one-click toggles

Two categories are gated behind dedicated checkboxes in the wizard's Migration Scope section because they require extra permissions or have caveats worth surfacing at decision time:

Content types

Site-level content types are copied before list creation so dest lists can reference them by name. Off by default because the migration needs Sites.Manage.All Graph scope — one notch higher than the default Sites.ReadWrite.All. When you check "Migrate content types" in the wizard, the next OAuth consent prompt will request the additional scope; admin consent grants it tenant-wide so subsequent jobs don't re-prompt.

What unlocks: column inheritance (a custom "Project ID" column defined once at the site level and inherited by 12 lists migrates intact instead of being re-defined per-list). What doesn't change: lists without custom content types behave identically with or without this toggle.

Site pages with web parts

Modern site pages (the /SitePages/ library) and their canvas layouts copy when the toggle is on. The page structure (sections, columns, page properties, banner, layout) always copies cleanly. The caveats live one level down, on individual web parts.

Web part fix-up matrix

How each common web part behaves after migration. Use this to plan your post-migration checklist for cross-tenant runs.

Web part type	Same tenant	Cross tenant
List embed References source list by ID	✓ Honored automatically	Needs re-bind to the dest list (edit page → pick the migrated list from the destination's list picker).
Document embed References file by source URL	✓ Honored automatically	Needs re-link to the dest document (the source URL won't resolve on the destination tenant).
Image Uploaded to source SiteAssets	✓ Honored (image lives at same URL on dest site collection)	× Image broken — re-upload to the destination SiteAssets or use an externally-hosted URL.
People web part References source-tenant users	✓ Honored if the user exists on the destination tenant	Cross-tenant: users won't resolve unless they exist on the dest tenant as full members or B2B guests with the same UPN. Re-pick the people if not.
News web part References source-tenant news pages	✓ Honored if the source news pages migrated to the dest site	× Source news pages don't exist on the dest tenant. Re-create the news roll-up after migrating the news pages.
Quick links References source-tenant URLs	✓ Honored	Update any links pointing at source-tenant resources to the destination equivalents.
Hero web part Background image + tile links	✓ Honored (same site collection / tenant)	Background image broken (re-upload) + tile links need updating.
Text / Markdown / Embed	✓	✓ (content-only, no external references)
Power BI / Forms / custom SPFx	References by report ID / form ID — works only if the same Power BI workspace / Forms tenant is in scope.	× Cross-tenant: the embedded service binding doesn't transfer. Re-embed the report or form on the destination tenant.

True History Mode coverage

True History Mode (the default for SharePoint ↔ SharePoint and OneDrive ↔ SharePoint migrations within the same tenant) routes through the SharePoint Migration API instead of Graph. It preserves a stricter set of metadata than the cross-platform Graph path:

• Author (Created By) — the original creator, not the migration service account.
• Editor (Modified By) — the original last-modifier.
• Created — the original creation timestamp.
• Modified — the original last-modification timestamp.
• Version history — every prior version with its original author + timestamp.

Folder-level metadata is preserved via a two-pass post-migration patch (Author/Editor first, Modified/Created second) because the SharePoint Migration API silently discards user-field writes when system-field writes are in the same payload. If the system-field pass fails on a specific folder, the folder will still show the correct Author + Editor but the Modified date will show the migration timestamp instead of the source date. The job log reports the count under spmt.folder_metadata.complete with systemFieldsFailed: N — check that value if folder dates look off.

What does NOT migrate

Set expectations explicitly — these structures don't transfer through MigrationFox today and you'll want to handle them separately:

• SharePoint 2010 / 2013 declarative workflows — Microsoft removed the workflow API; even Microsoft's own SharePoint Migration Tool can't move legacy workflow XAML. Migrate the data; rebuild the workflow on the destination using Power Automate.
• Custom site features and solution packages (.wsp, .sppkg) — these are tenant-deployed customizations, not site content. Re-deploy on the destination tenant.
• InfoPath form templates (.xsn files) — InfoPath is retired by Microsoft in July 2026. Use the InfoPath PDF Archive tool to convert submitted form XML into searchable PDFs before retirement.
• Site-collection-level branding (classic master pages, alternate CSS) — classic UI is going away; modern theming uses tenant-level theme JSON which has to be re-applied on the destination.
• User profile properties (job title, department, custom user-profile columns) — these live in the tenant's User Profile Service, not in the site. Migrate via the tenant admin profile sync, not per-site.
• Search schema customizations — managed properties, refiners, crawl rules. Re-configure on the destination tenant's Search admin.

Scope requirements (Graph permissions)

The wizard requests the minimum scope needed for the toggles you've selected:

• Default scope — Sites.ReadWrite.All. Sufficient for: document libraries, lists, list views, file metadata, version history, site pages.
• Elevated scope — Sites.Manage.All. Required when "Migrate content types" is checked because the API call to copy site-level content types operates on the web's content-type collection, which is a site-management operation. Also required for some advanced permission-migration scenarios.

For admins who want to avoid per-job consent prompts: have your tenant admin grant Sites.Manage.All tenant-wide once via the Microsoft Entra admin center → Enterprise applications → MigrationFox → Permissions → "Grant admin consent". Subsequent jobs by anyone in the tenant won't re-prompt.

Not sure how a specific structure migrates?

If you have a SharePoint structure (custom web part, complex view, third-party content type, etc.) and want to know whether it'll survive a MigrationFox run, send the site URL plus a screenshot or description of the structure to support@migrationfox.com. We'll respond within one business day with: (a) confirmation it migrates as-is, (b) the fix-up needed post-migration, or (c) "this isn't supported today" with a workaround.