Forum Discussion

JakeGolden's avatar
JakeGolden
Copper Contributor
Apr 20, 2026

SharePoint List Migration to new Tenant

Hi All,

I am preparing for a tenant-to-tenant migration of 60+ SharePoint lists that function as the back-end for various PowerApps. Since we are doing a staggered cutover, I need to perform an initial migration now and then run 'Delta' syncs over the next few weeks to catch new records, updates, and deletes.

 

My primary challenge is that SharePoint's native ID column is not preserved during manual migrations (PowerShell/CSV), which will break our App logic and Lookups. How have others handled cross-tenant list synchronization at this scale? Specifically:

 

  • How do you maintain record relationships and deep links when the system IDs change?
  • What is the most efficient way to handle deltas across 60 lists without buying expensive 3rd-party migration tools?

 

thanks,

Jake

App
developer
Lists
powershell
SharePoint Online

1 Reply

  • Radzik_PL's avatar
    Radzik_PL
    Brass Contributor
    Apr 20, 2026

    We went through a very similar migration scenario (many lists), and from experience I can say that trying to preserve native SharePoint IDs in a tenant‑to‑tenant setup quickly turns into a dead end. The IDs are generated at write time by SharePoint Online, they are local to a specific list and tenant, and there is no supported way to set them or fully control the order in which commits happen.

    We even tried a “record‑by‑record” approach. We wrote a PowerShell script that would take a single item from the source list, write it to the target tenant, and then deliberately wait for confirmation that the item was saved, specifically to avoid any parallel writes. Technically this allowed us to read the newly assigned ID, but the delay required to safely confirm each write was so large that for bigger lists the process became unacceptably slow. Once you add delta sync and retries on top of that, the whole approach also stops being predictable.

    What ultimately worked was stepping away from system IDs entirely. We introduced our own identifier (GUID), based all lookups and Power Apps logic on it, and handled delta sync using modified date plus soft deletes. Accepting that SharePoint IDs are not stable or controllable actually simplified the migration a lot, although it did require some upfront refactoring.

    I’m not sure whether there are third‑party tools today that handle this better, but from our side this approach was the only one that scaled cleanly.