Migrate SharePoint lists and content types between sites
What the REST and CSOM APIs can carry for site columns, content types, lists, items, views, pages and navigation, and the gaps such as item version history.
Document libraries get the attention in a SharePoint migration because they hold the bytes, but the structure around them is what makes a site usable: site columns, content types, the lists that hold contacts, tasks, issues and events, the views people rely on, the pages and the navigation. Microsoft's Migration API is built for files and folders. To migrate SharePoint lists and content types between sites or tenants, a tool has to use the REST and CSOM APIs item by item, and those APIs can carry a great deal but not everything.
This article sets out what carries, in the order it has to be created, the gaps that no REST-based tool can close, and how to run a structure migration alongside the library migration so the two agree. Everything here was validated against SharePoint Online in September 2026.
Why lists need a different path from libraries
The SharePoint Import Migration API takes a package of files, a manifest of list items and their metadata, and imports it asynchronously with identifiers, timestamps and version history preserved. It is the right tool for document libraries and it is how ShareShift migrates them. It is not a tool for creating site columns, content types, list definitions, views, pages or navigation. Those are schema, not content, and SharePoint exposes them through REST and CSOM.
The practical consequence is that a complete site migration is two runs that must agree: a structure run that creates the schema, lists and list items through REST, and a library run that imports documents through the Migration API into libraries the structure run has already created. Neither Microsoft's SPMT nor Migration Manager accepts SharePoint Online as a source, so restructuring inside a tenant or moving sites between tenants without an Enterprise Agreement is third-party territory whichever tool you choose.
What carries, in creation order
Order matters because each layer references the one below it. Columns before content types, content types before lists, lists before items, items before pages that link to them, and pages before navigation that points at them.
| Layer | What is created | Notes |
|---|---|---|
| Site columns | Custom columns with the same internal name and the same GUID as the source | Keeping the GUID means content types and lookups keep working after the move |
| Content types | Same content type id, field links in the same order | REST ignores a requested content type id, so content types are created through one CSOM ProcessQuery call instead |
| Lists | Standard templates 100 (generic list), 103 (links), 104 (announcements), 105 (contacts), 106 (calendar), 107 (tasks), 120 (custom grid) and 171 (tasks with timeline), with settings, content types, columns and views | Document libraries are created and then reported for the library migration |
| Folders and items | Every item with all column types, and Created, Modified, Author and Editor preserved | Users are mapped and verified at the destination; unresolved users fall back and are reported |
| Attachments | Copied per item | |
| Modern pages | Client-side pages with URLs rewritten to the destination; Created, Author and FirstPublishedDate kept | Modified and Editor show the migration, because publishing stamps them and restoring them afterwards would leave a minor draft |
| Navigation | Quick launch and top navigation with links rewritten | |
| Subsites | Recursively, each with its own columns, content types, lists, pages and navigation |
A JSON state file keyed by source id records every destination object as soon as SharePoint returns it, so a re-run resumes where it stopped and never creates a duplicate list or item. That same file makes a structure migration incremental: items already migrated are skipped unless they changed.
The gaps REST cannot close
These are the limits every REST-based structure migration shares. A tool that lists them is being straight with you.
| Gap | Why | What happens |
|---|---|---|
| List item version history | REST can set the current values of an item and its timestamps, but cannot recreate prior versions. The SharePoint Import Migration API can, and ShareShift uses it | The item is written by REST, then its history is laid back over it: every version with its own values, timestamp and editor. A person, lookup or managed metadata column shows the item's current value in every version, and the run says so |
| Managed metadata columns | A taxonomy column stores the term's identifier, not its name, so the term set has to exist at the destination with the same identifiers | The term group behind the column is copied first, identifiers kept, or shareshift terms copies the taxonomy on its own. Nothing already at the destination is changed |
| Classic wiki and web part pages | Only modern client-side pages can be created through the page API | Skipped with a warning. Microsoft's own web part serializer for the Migration API is the future route for classic web parts |
| Web parts pointing at source assets | A web part configured with a source list id or a source-only asset has nothing to point at | Kept as-is and flagged for manual attention |
| Discussion boards (108) | Threaded discussions do not round-trip through REST | Skipped |
| Recurring calendar events | The recurrence expansion is not exposed as items | Copied as their single-item representation |
| Modified and Editor on pages | Publishing stamps them | Show the migration; Created, Author and FirstPublishedDate are kept |
How this compares with other tools
ShareGate documents that its Insane mode, which uses the Migration API through Azure storage, is not supported for managed metadata columns, document sets or ASPX pages and falls back to Normal mode automatically, and that list version numbering "will always start at 1.0, regardless of the original version number" on that path. ShareShift keeps the original numbering, because the Migration API manifest carries a version collection under a list item as well as under a file. Microsoft's SPMT carries managed metadata and term store, navigation, site features and web parts from SharePoint Server sources, and is worth using for those sources when no restructuring is needed; the roundup of tools sets out when.
Where tools differ is in what they tell you. Ask any vendor three questions: does the content type keep its id, does the site column keep its GUID, and what happens to list item version history. The answers determine whether lookups, content type inheritance and audit expectations survive.
Running a structure migration
- Inventory the source site. List custom site columns, content types, lists by template, page count by type (modern versus classic), and navigation. Note any managed metadata columns and confirm whether the term sets exist at the destination.
- Decide the destination. Same tenant or cross tenant, a fresh site or an existing one. On an existing site, same-named lists and columns are matched rather than duplicated.
- Run the structure migration first. Columns, content types, lists, items, attachments, pages, navigation, subsites. Review the warnings: skipped classic pages, managed metadata columns without term sets, unresolved users.
- Run the library migration second. Point it at the libraries the structure run created, so documents land in libraries whose content types and columns already exist and their metadata resolves.
- Fix the flagged web parts and re-run the structure migration; the state file means only new or changed items are touched.
- Reconcile. Compare list item counts per list and library counts per library, then check the versions put back against the versions at the source so nobody is surprised later.
shareshift site --source-site https://contoso.sharepoint.com/sites/old \ --site https://contoso.sharepoint.com/sites/new --tenant-id <tenant> --client-id <app> --pfx ./app.pfx \ --fallback-user admin@contoso.com --state ./shareshift-site.json
The structure command needs the same app registration as the library migration: SharePoint Sites.FullControl.All as an application permission with a certificate credential, and for cross-tenant work a second registration in the source tenant. The tenant to tenant guide walks through both, and the checklist has the inventory items to capture before you start.
Structure migration is included on every ShareShift plan with no workload gating, so a restructure inside a tenant costs the same as a file server retirement. Plans and the 30-day trial are on the pricing page, and the ShareGate comparison covers the differences in this area specifically.
Frequently asked questions
Can SharePoint list version history be migrated?
Yes. REST cannot do it, but the SharePoint Import Migration API can: its package format carries a version collection under a list item as well as under a file. ShareShift writes the item through REST, then lays its history back over it, so each version keeps its own values, timestamp and editor. A person, lookup or managed metadata column cannot be carried separately per version and shows the item's current value throughout; the run names those columns.
Do content types keep their ids when migrated?
They can, if the tool creates them through CSOM. REST ignores a requested content type id, so ShareShift creates content types with one CSOM ProcessQuery call to preserve the id and the field link order. Site columns are created with the same internal name and GUID.
Which list templates can be migrated?
The standard templates: generic list (100), links (103), announcements (104), contacts (105), calendar (106), tasks (107), custom grid (120) and tasks with timeline (171), with settings, columns, content types, views, folders, items and attachments. Discussion boards (108) are skipped. Document libraries go through the Migration API.
Are modern pages migrated with their dates?
Created, Author and FirstPublishedDate are kept and URLs are rewritten. Modified and Editor show the migration because publishing stamps them. Classic wiki and web part pages are skipped with a warning.
What about managed metadata columns?
The term group behind the column is copied to the destination term store first, with every term group, term set and term keeping the identifier it had at the source, so the values on migrated items still resolve. You can also copy the taxonomy on its own with shareshift terms, before any content moves. Nothing already in the destination term store is changed.
Run your first migration on a 30-day free trial
Every workload, unlimited data, three workers, pause and resume built in. Worker-only, so your content never passes through our servers. The trial key is issued from the portal and works with the same app you would buy.