Choose SPSync when a pipeline exists only to copy SharePoint lists and you want lookups, people and deletes handled for you; choose Azure Data Factory when the lists are one step in a wider Azure pipeline.
Documentation reviewed
Where Azure Data Factory fits
- Part of the Azure data platform, with many other connectors and sinks
- copies lists into SQL or the lake
- service principal authentication with a certificate
- pipelines, triggers and monitoring in one place
Where it breaks
- The list connector is documented as a Copy activity source and Lookup activity, not as a replication product
- attachments and managed metadata are listed as not supported in the connector's type mapping
- lookup and person columns arrive as integer IDs in the documented type mapping
- the list connector copies lists, not files; files need a Web activity plus an HTTP source
- service principal setup, including a certificate and admin consent, is yours to maintain
- delete handling and schema changes are not documented for the list connector
Feature by feature
| Feature | SPSync | Azure Data Factory and Synapse pipelines with the SharePoint Online List connector |
|---|---|---|
| SharePoint Online support | Core product | Yes: the SharePoint Online List connector (Copy activity source, Lookup activity) |
| On-prem SharePoint support | On the roadmap | Not documented |
| Destinations | Relational, warehouse, lake and search/vector destinations: 20 destination engines (30+ named targets such as Azure SQL, MariaDB and Supabase), including SQL Server, Postgres, BigQuery, Databricks, ClickHouse, Parquet, Iceberg, pgvector and Azure AI Search; see /destinations/ | Any Copy activity sink supported by Azure Data Factory or Synapse pipelines |
| Lookup normalisation | Lookups become joinable key columns | Lookup and person columns arrive as integer IDs in the documented type mapping; resolving them is up to the pipeline |
| Multi-value columns | Child tables | The documentation notes only one choice data type can be selected for the list source; splitting into child tables is up to the pipeline |
| Deletes | Soft delete by default, hard delete with the command-line tool | Not documented for the list connector; the Copy activity reads rows through an OData query |
| Delta sync | Every few minutes by default, plus a reconcile, weekly by default | A custom OData query option can filter what each run reads; scheduling is a pipeline trigger you configure |
| Schema evolution | New columns appear automatically; on SQL Server, PostgreSQL, MySQL, ClickHouse, Oracle, SQLite and DuckDB retyped columns get a _v2 column | Mappings are defined in the pipeline; see Microsoft's documentation for schema drift handling |
| Hosted option | SPSync in your Azure | Runs in Azure |
| Desktop app | macOS and Windows | Not a desktop application; authoring is in the Azure portal |
| CLI / CI | Built-in CLI | PowerShell, SDKs, REST API and ARM templates |
| Per-site least-privilege permissions | Delegated sign-in or app-only with Sites.Selected, bring-your-own-app | Service principal with a certificate or key; the documented setup grants Sites.Read.All |
| Pricing model | Licensed per installation and per target family, on annual terms, with Standard Support included; no public price list, quoted after a call | Billed through Azure by pipeline activity and integration runtime usage; see the Azure Data Factory pricing page |
Most teams that copy SharePoint lists with Azure Data Factory already have pipelines for other sources, and the list connector slots into that estate. It is documented as a Copy activity source and a Lookup activity, authenticates with a service principal and reads through OData, so a list can join an existing schedule and be monitored with everything else. Microsoft also points new projects at Data Factory in Microsoft Fabric as the next generation of the service.
A building block, by design
The connector moves data; replication is something you assemble around it. Microsoft’s type mapping shows lookup and person columns arriving as integer IDs, and lists attachments and managed metadata as unsupported. Which rows each run reads, how deletes are tracked and what happens when a column changes are all designed into the pipeline. The service principal, its certificate and its consent also need looking after.
When copying lists is the only job
SPSync replicates each list into a normalised schema and keeps it current every few
minutes. Lookups become key columns you can join on, multi-value columns become child
tables, people resolve into a shared sp_users table, deletes are tracked (soft by
default) and SharePoint schema changes appear on their own. Reads are paged and indexed
around SharePoint’s 5,000-item list view threshold from the start.
Teams usually switch when a pipeline exists only to copy SharePoint lists. Keeping a service principal and a set of mappings for a handful of lists is then more than the job needs.
Replacing the Copy activities
- Record which lists and columns your Copy activities read, including any OData query that filters each run.
- Connect SPSync to SharePoint and tick the lists those activities copy.
- Choose a destination database; the first full load and the delta runs after it take over from the Copy activity’s read logic.
- Compare the new tables with the pipeline’s output, looking hardest at lookup, person and multi-value columns.
- Disable the pipeline trigger once the numbers agree, and keep Data Factory for the other sources it serves.
To weigh Data Factory, Fabric, Power Automate and a replica one question at a time, use the decision guide.
SPSync as an Azure Data Factory alternative for SharePoint lists
Replacing the list connector with SPSync removes the parts of the pipeline you built around it: the incremental filter, the delete handling and the mapping for lookup and person columns. Data Factory keeps every other source it serves, and SPSync writes the SharePoint tables into the same database.
Other alternatives
- Fabric Dataflow Gen2: the Fabric side of the same connector, where Copy job reads a list as a full load on every run.
- KingswaySoft: SSIS components that read list items and write lookup and taxonomy fields, for an integration estate built on SSIS packages.
- ZappySys: an SSIS and ODBC connector for SharePoint Online sites, lists and libraries, used from packages you already schedule.
- Power Automate: event-driven flows per item, sensible for approvals and slow for copying whole lists.
Frequently asked questions
How does Azure Data Factory map SharePoint lookup and person columns?
Microsoft's type mapping for the SharePoint Online List connector shows Lookup and Person or Group columns arriving as Int32 IDs, and lists Attachment, Task Outcome, External Data and Managed Metadata as not supported (checked 2026-10-22). SPSync turns a lookup into a joinable key and resolves people into a shared sp_users table. It skips managed metadata and attachments too, and reports each skipped column on every run.
Does the Data Factory connector copy only changed list items?
The connector reads whatever its OData query returns, so copying only changed items means writing that filter yourself, usually on the Modified column, and storing the last run time between runs. A deleted item never matches that filter. SPSync reads changes through Microsoft Graph delta queries, which report deletions as well.
Can SPSync and Data Factory write to the same Azure SQL database?
Yes. SPSync creates and updates its own tables and leaves the rest of the database alone, so pipelines loading other sources keep running. A separate table prefix makes the side-by-side check easy before you retire the Copy activities.
Desktop, Azure or command line
All three editions run the same engine, write the same tables and use the same licence key, so the choice comes down to who looks after the sync.
Desktop app
For macOS and Windows. Sign in with Microsoft, tick the lists, choose a database and sync from your own machine on the schedule you set. Delegated sign-in needs no admin unless your tenant requires admin consent for apps.
In your Azure
SPSync in your Azure, a managed application for your own subscription, is deployed with you on a call while the Marketplace listing is prepared. Once deployed it is always on, so the sync keeps running with every laptop closed.
Command line
Every replication is a YAML file you can review and commit. Run it from a server, a container or a CI pipeline, and re-run it safely any time.