SharePoint List Migration to new Tenant

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.