Mirrored, copied, synced or replicated: what each word means for a SharePoint list

23 October 2026

Tags: Relational databasesDesktopCommand line

Someone in finance asks IT to “mirror the Contracts list to SQL so Power BI stops timing out”. IT replies that the sync app is blocked by policy, so syncing is off the table. A consultant on the call suggests copying the list with the migration tool. Twenty minutes later three people have agreed on a plan that none of them described, and the ticket still says “mirror”.

The four words people use for this (mirror, sync, copy, replicate) each have a specific meaning in Microsoft’s own documentation, and only some of them apply to the rows of a SharePoint list. This post takes each word in turn, says what Microsoft means by it on Learn as of October 2026, and says which one gets a list into a database you can query. It ends with a table you can paste into the ticket.

What does SharePoint sync mean?

When most people type “sharepoint sync” into a search box, they mean the OneDrive sync app. Microsoft’s Learn page Sync in SharePoint and OneDrive describes it plainly: users install the OneDrive sync app for Windows or Mac, sync the files on a team site, and work with them in File Explorer or Finder. If someone adds, changes or deletes a file on the site, the change applies on their computer, and the other way round. The same page recommends adding OneDrive shortcuts over pressing the Sync button, and shows the PowerShell setting an admin uses to hide that button.

Everything on that page is about files and folders in document libraries. A list item is a row with columns, and the sync app does nothing with it. If you arrived here because the sync app is stuck, showing red crosses or asking you to sign in again, this post is the wrong place: start from that Learn page and its “Fix OneDrive sync problems” link.

If you arrived because someone asked you to “sync a SharePoint list with SQL”, they almost always mean one of the other three words. Read on.

Mirroring a SharePoint list to SQL in Fabric

Mirroring is a Microsoft Fabric feature with a precise meaning. The Learn page Mirroring SharePoint List in Microsoft Fabric says mirroring lets you “continuously replicate your existing SharePoint data directly into Fabric’s OneLake”. The data is stored as Delta tables, and each mirrored database gets a SQL analytics endpoint you can query with T-SQL from SQL Server Management Studio or Power BI. That endpoint is, in Microsoft’s words, “a read-only copy”: you can add views and stored procedures, and you cannot change the rows.

Three facts from Learn shape whether mirroring suits you. The mirroring overview lists SharePoint List as a preview source. Mirroring needs a running Fabric capacity, and a paused capacity stops replication. Microsoft does not charge for the compute that replicates the data into OneLake, so if your organisation already runs a capacity the cost question is mostly about querying.

So when a Fabric team says “mirror the list”, they mean a continuously updated, read-only Delta copy in OneLake. If the request was for SQL Server, Azure SQL or Postgres, mirroring gets you a SQL endpoint over OneLake, which may or may not be what the requester pictured. Our comparison of SPSync with Fabric mirroring, Dataflow Gen2 and Copy jobs goes through what Learn documents for each route, including what it does not say about lookup columns and deleted items, so it is not repeated here.

What does copying a SharePoint list do?

A copy takes the list as it is at one moment and puts it somewhere else. It is correct at the instant it finishes, and from then on it drifts as people keep editing the list.

Fabric has a tool with the word in its name. The Copy job supports full copies, incremental copies and change data capture for sources that offer it. For a SharePoint list, though, the SharePoint Online List connector overview lists Copy job as a source for a full load only. Every run copies the whole list again.

Outside Fabric, “copy” covers a lot of everyday tools: exporting a list to Excel, a Power Automate flow that writes each item into a table, a PowerShell script run once before a project starts. Each gives you a snapshot. The snapshot is often enough for a one-off analysis. It stops being enough the day a report has to match what people entered this morning.

Migrating is a one-off move

“Migrate” is the word Microsoft uses for moving content into SharePoint. The SharePoint Migration Tool moves content from SharePoint Server 2010 to 2019, SharePoint Foundation and file shares into SharePoint, OneDrive and Teams. Its supported features page covers files, folders and lists, and a saved task can be rerun to move only new or updated files. Migration Manager, in the SharePoint admin centre, does the same job at larger scale for file shares and other cloud storage.

All of that points inward, towards Microsoft 365. Neither tool moves a list out of SharePoint into a database. When a consultant says “we’ll migrate the list to SQL”, they mean a project, with a cut-over date, after which the database is the record and the list is retired or frozen. Our SharePoint list to database migration planner covers that project from inventory to cut-over, so this post leaves it there.

What does SharePoint list replication mean?

Replication is the word we use for what SPSync does. It needs a narrow definition, because the other three words leak into it.

A replica is a database table per list, kept current from the list on a schedule. It runs one way. SharePoint stays the system of record: people go on editing the list in the browser, in Teams and in Power Apps, and the database follows. Nothing written in the database goes back to SharePoint. If an app or an analyst changes a replicated row, the next run that sees a newer version of that item in SharePoint overwrites it.

That makes replication different from each of the other words:

• It differs from the OneDrive sync app because it works on list rows and runs in one direction.
• It differs from a copy because it keeps going after the first load.
• It differs from a migration because the list stays live and stays in charge.
• It differs from Fabric mirroring in where the data goes: your own SQL Server, Azure SQL, Postgres or another database you choose, as ordinary tables you can write views and joins against.

In SPSync’s case, lookup and person columns become id columns you can join on, multi-value columns become child tables, and a deleted item keeps its row with a deletion timestamp, so the replica records what went. SPSync copies list items and library metadata. It does not copy file contents, and it does not carry SharePoint item permissions into the database.

Where Graph delta fits

Under the word “replication” sits a Microsoft Graph feature that Learn does not call replication. The delta query overview calls it change tracking, and says applications use it to “efficiently synchronize changes with a local data store”. For lists, listItem: delta returns the items created, updated or deleted since the last call, without a full read of the list.

SPSync’s first run reads the whole list. After that it keeps a delta token per list and asks Graph only for what changed. The same overview says a token can expire, and that a 410 Gone response means the application must start again with a full synchronisation, so a replicator has to handle both. Our walkthrough of a first replication shows what each run reads in practice.

So Microsoft’s own word for the mechanism is “synchronize”, and that is one reason “sync” gets used so loosely. When you read “sync” in Graph documentation, it means an app keeping its own store up to date, which has nothing to do with the OneDrive sync app.

How near real time can a SharePoint list to SQL copy be?

“Near real time” is a phrase people use for a few minutes behind, and that is what a scheduled replica gives you. The desktop app runs every five minutes by default. The command line does one round and exits, so cron, Windows Task Scheduler, launchd or a CI pipeline decides how often it runs; our post on running a SharePoint list to database sync from CI has the scheduler recipes, so they are not repeated here.

Because each run after the first reads only what changed, a short interval does not mean re-reading the list each time. A reconcile pass on a slower schedule, weekly by default, re-checks the replica against the list, as a quality check and to catch up after an outage or a missed run.

If someone needs a figure in a dashboard to change the second an item is saved, a scheduled replica will not do that, and neither will a mirror Microsoft describes as near real time. Most reporting does not need that. It needs this morning’s data, and a report that refreshes without timing out.

Keeping a SharePoint list in sync with SQL, one way

Here is the order of work when the ticket says “keep the list in sync with SQL”:

1. Ask which direction. If the answer is “both”, find out which fields the database side needs to write. Usually it is a status or an approval, and it can live in its own table joined to the replica on the item id.
2. Agree that SharePoint stays the record. The list keeps its forms, its permissions and its users.
3. Pick the database the readers already use. Power BI, Excel and most reporting tools read SQL Server, Azure SQL and Postgres directly.
4. Connect SPSync to the site with read-only permission, choose the lists, and preview the schema before anything runs.
5. Run the first load, then let the schedule take over. Point the report at the tables instead of the list connector.

If step one turns up a real need for two-way writes, say so early. SPSync does not write to SharePoint today.

SharePoint list sync vs copy vs mirror, side by side

Which word to use in the project brief

Write the word that matches the outcome you need, and add one sentence that pins it down. “Replicate the Contracts list into the reporting database every few minutes, one way; SharePoint stays the record” leaves nobody guessing. “Mirror the list into Fabric” is right when the team already works in Fabric and accepts a preview feature. “Migrate” is right only when the list is going to be switched off.

And if the brief says “sync”, ask the question that saves the twenty minutes: sync which way, and to what?