A SharePoint list moves in two parts, the structure and the rows. Plain columns travel easily in any SharePoint list. Lookup, Person or Group and calculated columns do not, because they store IDs and formulas that point at things in the old site. Move parent lists first, keep an Old ID column and rebuild the pointers last.
What changes when you migrate a SharePoint list?
A SharePoint list is a structure plus rows, and many of those rows are not data at all. They are pointers.
Text, number, date and choice columns carry their value with them. Everything else stores a reference. A lookup column stores the source list and the ID of the item it points at. A Person or Group column stores a user ID. A managed metadata column stores a term GUID. A calculated column stores a formula over other columns. Copy the list to a new site or a new tenant and every one of those references still names something in the old place.
That is why a migrated SharePoint list looks perfect on the first screen. The item count matches, the titles are right, the dates are right. Then somebody opens a record and the Customer field is blank, or the Owner field shows nobody. The rows arrived. The pointers inside them did not.
Nobody complains that a date column moved. They complain about the one field that told them who owns the record. Plan for the pointers and the rest of the list takes care of itself.
Jamie Kaler Marketing Head and Content Strategist, RecoveryTools
Which SharePoint list columns break after migration?
Group the columns of every SharePoint list by what they store, because that decides what survives. Most SharePoint list projects only need the middle rows of this table checked.
| Column type | What it stores | After a migration |
|---|---|---|
| Text, number, date, choice, yes or no | The value itself | Moves cleanly |
| Lookup | Source list GUID and item ID | Empty or unresolved until rebuilt |
| Person or Group | A user ID resolved by login name | Fails when the user is missing in the target |
| Managed metadata | A term GUID from the term store | Blank, or a raw GUID, without matching terms |
| Calculated | A formula over other columns | Breaks when a referenced column is missing or renamed |
| Created By and Modified By | User references | Show the migrating account unless authorship is preserved |
| Hyperlink | A plain URL | Still points at the old tenant |
Managed metadata has its own trap, because the term store lives at tenant level and has to exist in the target first. The full order of operations is in how to migrate SharePoint document libraries with metadata, and the same rules apply to a list column.
Why do lookup columns come back empty?
Because a lookup column cannot reach outside its own site. Microsoft's own answer to this problem says a lookup column can only be created within one site, and the linked lists must sit in that same site. Move a SharePoint list to a new site and its lookup has no source to resolve against.
Uploading the source lists first does not fix it on its own. The lookup stores the GUID of the old source list, and the item IDs inside it belong to that old list. SharePoint accepts the write without complaint and never resolves the value, which is why the failure is silent.
Item IDs make it worse. Standard SharePoint APIs assign IDs automatically, so the item that was number 42 in the source gets whatever number is next in the target. A deleted ID is never reused either, so a gap in the source cannot be reproduced by copying. Only the SharePoint Migration API can set IDs, and only tools built on it can keep them.
The workable answer is dull and reliable. Add a single line of text column called Old ID to every source list before the move and copy the ID into it. After the items land, that column is your map from old pointer to new item, and a short pass rewrites the lookups against it. Parent lists go first, because a child list cannot point at an item that does not exist yet.
How do Person or Group columns survive a tenant move?
Only when the user already exists in the target and can be found by login name. SharePoint resolves people by login name, not by email, so a tenant move or a domain change breaks the match even when the email address is identical.
The fix is a lookup table built before any item moves. List every person named in a Person or Group column, find their account in the target tenant by email, and keep that pairing for the copy. People who left the company need a decision. Either map them to a placeholder account or accept that the field will be empty.
Group scoped columns have a second problem. When a Person or Group column is limited to one SharePoint group, a template export keeps the group's name but not the link to it, because groups belong to site permissions and cannot be exported or imported between sites. After import, the column quietly accepts all users. The fix in Microsoft's Q&A is to create the group in the target first, read its ID and put that ID into the column's UserSelectionScope setting.
The built in Excel route is no help here at all. Create list from Excel offers no Person or Group column type, so those columns are never created. Microsoft's suggested workaround for moving Person or Group data between lists is Power Automate.
Which methods move a SharePoint list to another tenant?
There are five, and none of them carries every column type without help. Choose by what your SharePoint list actually contains.
| Method | What it carries | Where it falls short |
|---|---|---|
| Save list as template | Column definitions, and rows when you include content | Lookup and Person or Group values did not transfer in Microsoft's own Q&A test |
| Export to Excel and import | Plain values only | No Person or Group column type on import |
| PnP provisioning | Structure and rows, scriptable | Group scope on Person or Group columns is lost between sites |
| Power Automate | Items copied one by one, including Person or Group values | Slow on large lists and exposed to throttling |
| Migration software | Bulk lists and items with mapping | Lookup and calculated columns still need a rebuild pass |
The PnP route uses three cmdlets in order. Get-PnPSiteTemplate exports the structure, Add-PnPDataRowsToSiteTemplate adds the rows for every named list and Invoke-PnPSiteTemplate applies both to the target. It suits small lists and teams comfortable with scripts, and it needs the user and group handling described above added by hand.
Microsoft's own SharePoint Migration Tool is not on this list, because it reads on premises sources only. The reasons are laid out in SharePoint Migration Tool limitations you hit in week one. For an overview of the wider site level move, see how to migrate a SharePoint site to another tenant.
Move the lists in bulk, then rebuild the pointers once
RecoveryTools SharePoint Migrator moves generic lists and list items between two Microsoft 365 accounts with permissions, versions and metadata. Lookup and calculated columns stay behind, so the rebuild steps below are part of the plan.
No credit card, no sign-up. Works on Windows 11, 10 and Windows Server.
How do you migrate a SharePoint list step by step?
Follow this order. Steps one, two and four are the ones teams skip, and they are the ones that cause the second attempt.
- Map the lookup dependencies. List every SharePoint list in scope and note which lookup column points at which list. The lists with no lookups are your parents and they move first.
- Match the users. Pair every person named in a Person or Group column with an account in the target tenant by email. Decide what happens to people who have left.
- Build the shared structure. Recreate the term store, site columns and content types in the target before any list arrives, with matching internal names and field types.
- Add an Old ID column. Create a single line of text column on every source list and copy the item ID into it before the move.
- Create the lists in dependency order. Parent lists first, then the lists that look them up. Keep the same internal column names.
- Pilot one list with every column type. Choose a real SharePoint list with a lookup, a Person or Group column, a calculated column and a managed metadata column. Time it and read the result field by field.
- Move the items in waves. Large lists go in batches outside working hours. The throttling rules that govern those batches are in SharePoint migration throttling errors and how to avoid them.
- Rebuild the pointers. Recreate the lookup and calculated columns, rewrite the lookup values from the Old ID map and rebuild the views and column order.
Permissions on list items follow their own track, described in how to migrate SharePoint permissions to another tenant. Timing for the waves is calculated in how long does a SharePoint migration take, and the wider sequence sits in the Microsoft 365 migration planning checklist.
Which list limits matter during migration?
These are platform ceilings, so no tool removes them. The list view threshold is about 5,000 items and cannot be changed in SharePoint Online. Lists above 3,000 items start showing a warning on the settings page, which is the signal to index the columns people sort on.
A single list holds up to 30 million items, so storage is rarely the issue. Queries are. A view that uses more than 8 lookup, Person or Group or workflow status columns is blocked, and the list view lookup threshold stops at 12 joins. A migrated SharePoint list with eight lookups in its default view can arrive intact and still refuse to open. Trim the view before you move it, not after somebody reports it.
How do you verify a migrated SharePoint list?
Counting items proves the SharePoint list copy finished. It says nothing about the pointers, so check those directly.
Sort and filter by every lookup column. If it sorts, the binding is real. If it shows blanks or raw IDs, the Old ID rewrite has not happened yet. Open five records and read the Person or Group field on every one, including one owned by somebody who left. Change one input in a calculated column and watch the result update. Open every custom view, because views are rebuilt rather than carried and a view that lost a column looks like missing data to the person using it.
Compare version counts on a record you know well. Version history is its own question, answered in does SharePoint version history migrate between tenants. Links people saved to list items point at the old tenant, a problem covered in what happens to SharePoint sharing links after migration. Flows that read the list are a separate rebuild, described in how to migrate Power Automate flows with SharePoint. Teams without spare hands for the verification pass hand it to our cloud migration service.
Frequently asked questions
Can you migrate a SharePoint list to another tenant?
Yes. Plain columns move with their values. Lookup, Person or Group and calculated columns need extra work, because they store IDs and formulas that point at the old site. Move parent lists first, keep an Old ID column and rebuild the pointers after the items land.
Why do lookup columns break when you migrate a SharePoint list?
A lookup column can only reach lists inside its own site, and it stores the GUID of the source list plus item IDs that belong to it. Copy the list elsewhere and the new item IDs differ, so the value never resolves. SharePoint accepts the write without an error.
Are SharePoint list item IDs preserved during migration?
Usually not. Standard SharePoint APIs assign IDs automatically, and a deleted ID is never reused. Only the SharePoint Migration API can set them, so only tools built on it can keep them. Store the source ID in an Old ID column to be safe.
How do you migrate Person or Group columns?
Build an email to account map for the target tenant before any item moves, since SharePoint resolves people by login name. Group scoped columns lose their group on template import, so create the group in the target and set the column's UserSelectionScope to its ID.
Can you move a SharePoint list with Export to Excel?
Only for plain values. Create list from Excel offers no Person or Group column type, so those columns are never created, and lookups, calculated columns and views have to be rebuilt by hand. It suits a small flat list and nothing else.
Do views and calculated columns move with a SharePoint list?
Treat them as rebuild work. Views and column order are the usual casualty of a copy, and a calculated column breaks when any column in its formula is missing or renamed. Create every referenced column first, then the formula, then the view.
Where to start this week
Draw the lookups of every SharePoint list. Not the migration plan, the lookups, one line per column, from child list to parent list.
That sketch takes an hour and it shows you the full job. The lists at the bottom with no arrows leaving them move first. The ones at the top with arrows into three other lists move last, and they are where the rebuild effort will sit.
Most teams find this out backwards, after the items are in the new tenant and the Customer column is blank. Draw it first, add the Old ID column and the SharePoint list becomes the easy part it should have been.
Jamie blends strategic marketing insight with technical writing, turning migration and recovery topics into guidance that works for technical and general readers alike.
Published 12 October 2026. Lookup and Person or Group behaviour comes from Microsoft Q&A threads on migrating a list with lookups and persons and exporting and importing a site with Get-PnPSiteTemplate. List limits come from list view threshold for large lists and libraries.