Migration and cut-over

A team has decided that a SharePoint list should become a database table, usually because an app has outgrown it. The first copy is rarely what goes wrong. The risk sits on the day you switch, when every report and app that reads the list has to point somewhere new without losing an edit someone made that morning.

Replication makes that day smaller. SPSync copies the lists into the target database and keeps copying on a schedule while people carry on editing in SharePoint, so the database is never more than one sync cycle behind. Lookup and person columns arrive as join keys and multi-value columns as child tables, which means whatever you move across finds the data in a relational shape from the start. Each report or app can then move on its own timetable.

Before each switch, check the copy against the list. Compare row counts, sample a few items by sp_item_id, and run spsync reconcile, which compares both sides in full and gives the people who own the data a check they can sign off. When the last consumer has moved, freeze edits on the list, let a final delta run and stop the replication. The list can stay in SharePoint, read-only, as the archive.

Know the limits before you plan. SPSync copies current field values; SharePoint's version history is not replicated, though a deleted item keeps its row with sp_deleted_at set. It reads SharePoint Online only, so an on-premises farm needs another route for now. SPSync never writes to SharePoint either. During the move the new app writes to its own tables, and the list stays the place people edit until the cut.

Moves between tenants follow the same pattern. After a merger, replicate each tenant through its own connection into one database with a table prefix per site, and a copy taken before the migration stays as a record of what each list held, whatever the migration tool does to the source.