SharePoint Online List Migration: Tenant-to-Tenant Guide 

Moving SharePoint lists between Microsoft 365 tenants? This guide covers everything your IT team needs, supported list templates, column and view transfer, lookup column handling, and a step-by-step process, so your data, structure, and relationships arrive intact in the target tenant. 

Understanding Your Tool Options for SPO-to-SPO Migration 

When planning a SharePoint Online tenant-to-tenant migration, one of the first questions IT teams ask is: which SharePoint migration tool should we use? It’s worth understanding what’s available, and what each tool is actually designed for. 

Microsoft’s SharePoint Migration Tool (SPMT) is a solid tool for its intended purpose – migrating content from SharePoint Server (on-premises) or local file shares into SharePoint Online. However, it is not designed for SharePoint Online to SharePoint Online tenant-to-tenant migrations. If your source is already in SharePoint Online and you need to move to a different M365 tenant, SPMT is outside its scope for this scenario. 

Microsoft also offers a Cross-Tenant SharePoint Migration feature via PowerShell cmdlets. This can work but comes with notable prerequisites: both tenants need a pre-established trust relationship, Azure Active Directory synchronization must be configured, and the process requires substantial manual setup by administrators experienced with advanced PowerShell. For organizations going through mergers, acquisitions, or tenant consolidations, this level of complexity often makes it impractical for production list migrations. 

The practical reality is widely confirmed by the Microsoft community: Reddit’s r/sharepoint, Microsoft Tech Community threads, and SharePoint MVPs all consistently confirm that organizations performing SPO-to-SPO tenant migrations must turn to third-party tools. Apps4.Pro Migration Manager is purpose-built for exactly this use case. 

What SharePoint Online List Migration Actually Involves 

A SharePoint list migration between tenants is not simply copying a spreadsheet. It means transferring the full list structure and its data from one tenant’s SharePoint environment to another’s while preserving: 

• The list schema: every column, its data type, settings, and display formatting 

• All list items and their field values 

• Named views with their sort, filter, and column visibility rules 

• Item-level and list-level permissions (mapped to the new tenant’s users) 

• Metadata such as created date, modified date, and author attribution 

• Version history of list items (where enabled) 

• Lookup column relationships between lists 

• Managed Metadata term bindings (requires coordinated term store migration) 

Miss any of these, and you’ve migrated data, but broken the processes and workflows that depend on it. 

Supported List Template Types 

SharePoint uses numbered template IDs to classify every list type. Not all templates migrate equally, understanding which are fully supported versus which need special handling is essential for scoping your project. 

SharePoint list template types and migration support between SPO tenants 

Template ID	List Type	Common Use	SPO→SPO Support
100	Custom List	General-purpose structured data	✓ Full
101	Document Library	File storage + metadata	✓ Full
102	Survey	Form-based data collection	✓ Full
103	Links	URL collections	✓ Full
104	Announcements	News & notices	✓ Full
105	Contacts	People / org directories	✓ Full
106	Calendar / Events	Event scheduling	✓ Full
107	Tasks	Task management	✓ Full
108	Discussion Board	Team conversations	Not supported
109	Picture Library	Image collections	Not supported
150	Project Tasks (Gantt)	Project tracking	✓ Full
851	Asset Library	Rich media	Not supported
1100	Issue Tracking	Bug / issue management	✓ Full
119	Wiki Page Library	Knowledge base pages	Not supported
140	Workflow History	Workflow logs	Not supported
200–212	Meeting Workspace Lists	Legacy meeting content	Not supported

Column and View Transfer 

Apps4.Pro Migration Manager migrates the complete list schema, not just the rows of data. Here’s what transfers and what deserves a closer look. 

What Transfers Automatically 

• Standard columns: Single line of text, multiple lines, number, currency, date & time, yes/no, choice dropdowns, hyperlink, calculated columns 

• Column settings: Required/optional, default values, max character limits, date format preferences, choice options 

• All named views: Custom views with their column order, sort rules, and filter criteria 

• All list items with field values, attachments, and version history 

• Item & list-level permissions (subject to user/group mapping, see below) 

• File metadata: Created date, modified date, and author attribution 

What Needs Extra Attention 

Several column types introduce complexity that requires planning: 

• Person or Group columns: Require a source-to-target user mapping file. Without accurate mapping, person fields will be blank or incorrect in the target tenant. 

• Managed Metadata columns: Apps4.Pro Migration Manager handles this end-to-end, it migrates global and site level Term Groups from the source tenant’s Term Store to the target tenant as part of the same migration task, ensuring that Managed Metadata column values and bindings are fully preserved without any separate prerequisite steps. 

• Calculated columns: Formulas that reference other columns transfer but should be validated post-migration to confirm column references resolve correctly in the target context. 

• Lookup columns: The most complex scenario, covered in full detail in the next section. 

• Column formatting (JSON): Custom JSON column formatting migrates at the data level but should be spot-checked in the target, as some formatting may reference source-tenant-specific URLs. 

💡 View Validation Checklist 

After migration, open each named view in the target and verify: (1) all expected columns appear, (2) sort/filter rules are intact, (3) views referencing lookup or managed metadata columns still resolve, and (4) no view has more than 12 lookup column references – SharePoint throttles views that exceed this limit. 

Why Lookups Break in Tenant-to-Tenant Migration 

The problem is structural. A lookup column stores a reference to the internal GUID of its source list, not the list’s display name. When you migrate a list to a new tenant, SharePoint assigns a new GUID to every list. The migrated lookup column is now pointing to a GUID that doesn’t exist in the target tenant. The result: blank fields, broken views, and broken workflows. 

This is one of the core reasons why Microsoft’s cross-tenant PowerShell approach is fragile for complex list migrations, it doesn’t automatically resolve these GUID re-mappings. Apps4.Pro Migration Manager handles lookup re-mapping automatically by migrating referenced lists first and recording the new GUIDs, then updating the lookup column references accordingly in the target. 

The Dependency Ordering Problem 

Consider this chain: List A has a lookup to List B, and List B has a lookup to List C. If you migrate List A first, its lookup breaks because List B isn’t in the target yet. The correct migration order must be: List C → List B → List A. In real environments with dozens of interconnected lists, manually determining this dependency graph is error-prone, which is why tooling that handles it automatically matters. 

1. Map all lookup dependencies in the source tenant 

Before migration, document every lookup column: which list it exists in, which list it points to, and which field it retrieves. Apps4.Pro’s pre-migration inventory report surfaces this automatically. 

2. Migrate referenced lists first 

Always migrate the source (looked-up) lists before the lists that contain lookup columns. In Apps4.Pro, you can sequence migration batches to enforce this order. 

3. Let Apps4.Pro auto-remap GUID references 

Apps4.Pro tracks the new list GUIDs assigned in the target tenant and automatically updates lookup column references to point to the correct migrated lists – no manual PowerShell required. 

4. Check for the 12-lookup-column view throttle 

SharePoint throttles list views that reference more than 12 lookup columns. Identify and remediate any views exceeding this limit before or immediately after migration to keep them accessible. 

5. Validate lookup column data in target 

After migration, spot-check lookup column values across multiple list items to confirm that the data resolves correctly and the relationship is intact. 

SharePoint Lists vs. Microsoft Lists: The Migration Distinction 

If your organization uses Microsoft Lists (the standalone Microsoft 365 app), you may wonder whether it migrates differently from standard SharePoint Lists. The short answer: at the data layer, they are the same thing. 

SharePoint Lists 

Site-embedded lists 

• Lives inside a SharePoint site collection 

• Accessed via SharePoint site navigation 

• Full site column & content type integration 

• Deep site permission inheritance 

• Classic and modern UI supported 

Microsoft Lists 

M365 standalone app 

• Stored on SharePoint infrastructure internally 

• Accessed via M365 launcher, Teams, mobile app 

• Modern templates & rule-based notifications 

• Native Teams tab integration 

• Personal lists stored in user’s SPO site 

Microsoft Lists is SharePoint under the hood. Every Microsoft List is stored as a SharePoint list within a SharePoint site, either a group-connected site or the user’s personal My Site. For migration tooling, both types are handled identically at the data and schema layer. 

Post-Migration Considerations for Microsoft Lists 

While the data migrates identically, the Microsoft Lists experience requires some post-migration steps in the target tenant: 

• Teams tabs: Any Teams channel tab pointing to a Microsoft List in the source tenant will break after migration. Users must re-add the List tab in the target tenant’s Teams environment. 

• App re-pinning: Users who accessed lists via the Microsoft Lists app will need to re-pin their lists from the new tenant’s SharePoint sites in the Lists app. 

• Sharing links: All sharing links pointing to the source tenant’s lists break after migration. New sharing links must be generated from the target tenant. 

• Power Automate flows: Any flows triggered by list events in the source tenant will need to be reconfigured or re-migrated in the target tenant. 

How to Migrate SharePoint Online Lists Between Tenants 

Here is a complete, tested process for migrating SharePoint Online lists from one M365 tenant to another using Apps4.Pro Migration Manager. 

1. Run a pre-migration inventory 

Connect your source tenant to Apps4.Pro and generate the free inventory report. This provides a complete view of all lists, their template types, item counts, column configurations, permission levels, and lookup dependencies, your migration blueprint. 

2. Build user and group mapping 

Create a user mapping file pairing source tenant UPNs (user@sourcedomain.com) to target tenant UPNs (user@targetdomain.com). This ensures People/Group columns and permissions carry over correctly. Apps4.Pro supports CSV-based mapping upload. 

3. Connect source and target tenants in Apps4.Pro 

Provide Microsoft 365 Global Admin credentials (or app-only registration with required permissions) for both Tenant A and Tenant B. Apps4.Pro validates connectivity before any data moves. 

4. Select lists and set migration options 

Choose specific lists or full sites. Configure options: include version history, preserve permissions, include subsites. Set lookup dependency order,migrate referenced lists in the first batch. 

5. Run a pilot migration 

Migrate a representative sample: one list with lookup columns, one with managed metadata, one with complex views. Validate item counts, column schemas, view integrity, and lookup resolution before the full run. 

6. Execute the full migration and download the report 

Run the complete migration batch. Apps4.Pro provides real-time progress monitoring and a detailed post-migration report showing migrated counts, errors, skipped items, and permission accuracy, downloadable as proof of migration. 

7. Run incremental migration before cutover 

Apps4.Pro supports incremental migration, re-running the job will transfer only new or modified list items since the last run. Use this to sync changes made in the source during the migration window, then cut over at the scheduled time. 

Continue Your Migration Journey 

SharePoint list migration sits within a broader tenant-to-tenant project. Understanding how it connects to other workstreams keeps your migration coordinated:  

• SharePoint Migration Guide - Complete strategy and planning overview for SharePoint Online tenant-to-tenant migration. 

• Document Library Migration – Migrating libraries with versioning, metadata, and permissions between SPO tenants. 

• Metadata Migration - Migrating term stores and managed metadata columns across tenants. 

• Content Type Migration – Preserving content types and site columns in tenant-to-tenant migrations. 

Frequently Asked Questions