SharePoint Site Pages
Modern SharePoint pages are canvas layouts with typed web parts, not HTML documents. MigrationFox copies them as structured pages through Microsoft’s page APIs, so the destination gets the same sections, columns and web parts. This page covers what copies, what needs review afterwards, and how to fix the common cases.
What this feature does
For every modern page in the source Site Pages library, MigrationFox reads the page (title, description, layout, banner and canvas), creates it at the destination, and publishes it. News posts stay news posts. Web parts Microsoft Graph refuses to create (such as Hero) are put back afterwards through SharePoint’s own page API. Site pages copy as part of Full site copy, or in Content only when you pick the Site Pages library.
What a modern page is (and why it matters)
In classic SharePoint, a page was essentially an HTML document stored in a library. Modern pages are different. They are structured canvas layouts backed by JSON. A page has:
- Sections, each with a column layout (one, two or three columns, a vertical section, or a flexible layout).
- Columns inside each section.
- Web parts inside each column, each with a type ID and a JSON property bag.
- Page-level details: title, description, banner (title area), page layout and whether it is a news post.
SharePoint renders the page from that JSON. That is why copying the .aspx file into another library doesn’t produce a working page, and why MigrationFox copies pages through the page APIs instead.
What copies
| Element | Copied | Notes |
|---|---|---|
| Sections, columns and their order | Yes | Flexible sections are copied as one column, because Graph can’t create flexible layouts. The migration log names each page where this happened. |
| Web parts and their settings | Yes | Each web part’s type and property bag are carried across. |
| Web parts Graph refuses (for example Hero) | Yes | Restored after the page is created, from the source page’s full canvas, through SharePoint’s page API. Site, web and list IDs and links to the source site inside that canvas are pointed at the destination. |
| Title, description, page layout, banner | Yes | |
| News post state | Yes | Set when the page is created. |
| Published state | Yes | Each page is published after it is created. If publishing fails, the page stays as a draft you can publish by hand. |
| Page author and editor | Best-effort | MigrationFox sets the original author and editor after the page is created (using your user mapping across tenants). The page’s created and modified dates may show the migration time. |
What needs review after the migration
| Element | Copied | Notes |
|---|---|---|
| Web parts that point at the source site (lists, documents, images, news sources) | As configured | The settings copy exactly, so a web part can still point at the source site. Check these pages and repoint them. Updating links to the source site automatically is in early access. |
| Third-party or custom SPFx web parts | Reference only | The web part only renders if its package is installed in the destination tenant’s app catalog. Until then it shows an error tile. A tenant admin installs the .sppkg. |
| Page version history | No | Only the current page is created at the destination. |
| Unpublished drafts | No | The current page content is copied; a pending draft’s state is not. |
| Page comments and likes | No | |
| Page-level unique permissions | No | |
| Classic pages (wiki and web part pages) | No | The page step reads modern pages only. |
Links to the source site
Page content often contains links back to the source site: a text web part linking to a document, a Quick Links web part, a Highlighted Content web part reading a source library, or an image stored in the source site’s Site Assets library. After a migration these still point at the source.
- Restored web parts: on pages where MigrationFox had to restore web parts through SharePoint’s page API, IDs and links to the source site are pointed at the destination as part of the restore.
- Everything else: links and references stay as they were. Automatic updating of links to the old site is in early access and switching on for every account soon.
- Plan to review: after cutover, open the important pages (home page, news, landing pages) and repoint web parts and links to the destination.
Copy lists and libraries in the same run
Web parts like Highlighted Content, List and Document library refer to a list or library. Include those lists and libraries (and Site Assets, which holds page images) in the same site migration so they exist at the destination; then the web part can be pointed at the destination copy. A Full site copy runs pages after libraries and lists for this reason.
Pages that already exist
Pages follow the wizard’s If a file or page already exists at the destination choice:
- Skip existing: the destination page is left alone.
- Copy and replace: the destination page is replaced with the source page.
- Keep both: the page is copied with a suffix, for example
Home-2.aspx. - Incremental: the page is replaced only if the source page is newer.
How MigrationFox copies a page
For each page in the source Site Pages library:
1. Read the page and its canvas (sections, columns, web parts) through Microsoft Graph 2. Create the page at the destination (flexible sections become one column; a web part Graph rejects is set aside for step 4) 3. Publish the page 4. If a web part was set aside, save the source page's full canvas onto the destination page through SharePoint's page API, with site, web and list IDs and source-site links pointed at the destination, then publish again 5. Set the original author and editor
Every adjustment (flattened sections, restored web parts, failures) is written to the migration log with the page name.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| A page arrived but shows as a flat file with no sections or web parts | The page was copied as a file (for example by a plain file migration of the Site Pages folder) instead of through the page step. | Run a site migration (Full site copy, or Content only with the Site Pages library picked) so pages go through the page step. |
| Web part shows as an error tile on the destination | It is a third-party or custom SPFx web part that isn’t installed in the destination tenant. | A tenant admin uploads the .sppkg to the destination app catalog and adds it to the site. The web part renders on the next page load. |
| Highlighted Content or a list web part is empty or shows source content | The web part still points at the source list or library, or that list wasn’t part of the migration. | Include the list in the migration, then edit the web part on the destination to point at the destination copy. |
| Links in text web parts still go to the source site | Links are copied as they are. | Edit the text web part to update the link. |
| Images are broken on the destination page | The image still points at the source site’s Site Assets, which the reader can’t open. | Include Site Assets in the migration and repoint the image web part, or re-add the image on the destination. |
| A section shows as one column instead of a flexible layout | Graph can’t create flexible sections, so they are copied as one column. | Rearrange the section in the page editor on the destination. |
| A page is still a draft | Publishing failed after the page was created. | Open the page on the destination and click Publish. |
| Page version history is empty on the destination | Expected. Only the current page is copied. | If the page history must be kept for records, export it from the source before the migration. |
Related
- SharePoint site migration: Full site copy and Content only
- SharePoint provisioning: creating destination sites
- Blocked file types: the tenant policy that can affect embedded content
- Skip junk files: scan-time filtering that keeps OS debris out of the Site Assets library