SPSync vs SSIS for SharePoint Online lists

Choose SPSync when an SSIS package exists only to keep SharePoint lists current in SQL Server; choose SSIS when the lists are one input to a larger package, or when you write back to SharePoint.

Documentation reviewed 23 October 2026

Where Integration Services fits

• Already installed and understood wherever SQL Server is the warehouse
• SQL Server Agent schedules packages next to the other jobs a DBA already runs
• one package can join SharePoint data with every other SSIS source and transform
• third-party components from KingswaySoft, CozyRoc and ZappySys document OAuth sign-in to SharePoint Online, and all four add-ons named here, CData included, can write back to lists
• runs on premises or in the Azure-SSIS Integration Runtime in Data Factory

Where it breaks

• The built-in OData source reads ListData.svc, the SharePoint 2010 REST interface, and Microsoft documents that it does not support multiple-choice items
• Microsoft's OData connection manager page says modern authentication is not supported and accounts configured for multi-factor authentication cannot be used
• a deleted list item simply stops appearing, so a package has to compare full loads or read the recycle bin to notice it
• a new or retyped SharePoint column means refreshing package metadata and redeploying
• throttling, paging past the list view threshold and retries depend on the component you buy or the script task you write

Feature by feature

The package was built years ago, when the list lived on a SharePoint server down the corridor. It reads the Projects list, joins it to the finance tables and writes a reporting table that the month-end pack depends on. Then the site moved to SharePoint Online, the account it signed in with started asking for a second factor, and the job that used to run unnoticed at 2am now fails most nights with a sign-in error. The person who knows the package best spends the morning trying to work out what changed.

Can SSIS still read a SharePoint Online list?

Yes, but rarely with the parts that come in the box. The OData source in SSIS supports SharePoint lists through /_vti_bin/ListData.svc, the REST interface that dates from SharePoint 2010 according to Microsoft’s OData source page. That page also says the source does not support complex types such as multiple-choice items. Microsoft’s OData connection manager page lists the sign-in options and states that modern authentication is not supported and that an option configured for multi-factor authentication cannot be used. When a tenant turns on Entra ID security defaults, Microsoft blocks every sign-in made with an older protocol, so the built-in route stops working at the tenant’s front door.

That is why most SSIS teams reading SharePoint Online use a third-party component. Four come up again and again, and each describes itself fairly on its own pages:

• KingswaySoft’s SharePoint components are now part of its SSIS Integration Toolkit. They read and write lists and libraries over REST or SOAP, sign in with OAuth, filter with CAML, write lookup and taxonomy fields, and describe incremental loading that tracks changes since the last extraction.
• CozyRoc ships SharePoint source and destination components in its SSIS+ suite and now recommends a Microsoft Graph connection for SharePoint Online, with OAuth and multi-factor authentication support.
• ZappySys sells a SharePoint Online connector in SSIS PowerPack that calls Microsoft Graph, signs in as a user or as an application with a secret or a certificate, and retries throttled requests.
• CData’s SharePoint SSIS Components add a source and a destination with create, read, update and delete support.

KingswaySoft, CozyRoc and ZappySys each document OAuth sign-in for SharePoint Online, which gets a package past the sign-in problem. The CData page we could read describes SharePoint data and create, read, update and delete support without naming a sign-in method, so check its documentation for your tenant. All four can write to SharePoint through a destination component or write actions, which SPSync never does.

The delta and delete problem in a package

Signing in is the first problem. Keeping a SQL Server table in step with a list is the second, and it is the same whichever component reads the list.

A package that reads the whole list every night is simple and slow, and it gets slower as the list grows past SharePoint’s 5,000-item list view threshold. So the package gets a filter on the Modified column and a watermark table that remembers the last run. That reads less, but a deleted item never matches a filter on Modified. It just stops appearing, and the row in SQL Server stays there, so the month’s totals still count a project that no longer exists.

The usual fixes are a weekly full load compared against the table with a merge or a lookup transform, or a second read of the site’s recycle bin. Both work. Both are logic that lives in the package, and the package also has to handle a column someone adds to the list next Tuesday, which means refreshing the metadata and redeploying.

Scheduling in SQL Server Agent

Here SSIS is hard to beat for a DBA. A SQL Server Agent job step of type SQL Server Integration Services Package runs the package on a schedule, with the alerts, history and operators your other jobs already use. If the SharePoint load is one step in a chain that ends with a cube refresh, that chain is worth keeping.

SPSync does not ask you to give that up. Its command-line tool runs from any scheduler that reads exit codes, so an Agent job step can call it before the package that builds the reporting tables.

When is SSIS still the right answer?

Keep the package when the SharePoint list is one input to a bigger transform, when you write data back into SharePoint, or when the site is still on SharePoint Server on premises, which SPSync does not support today. A team that already owns a SharePoint component and has its delete handling working has little reason to change.

Look at SPSync when the package exists only to keep a copy of the lists current, and the time goes on sign-in failures, missing deletes and column changes. SPSync reads lists through Microsoft Graph with modern sign-in, uses Graph delta queries so each run reads only what changed, including deletions, and keeps a deleted item’s row with its deletion time. Lookups arrive as key columns you can join on and multi-value columns as child tables.

Moving the read out of the package

1. List what the package reads today: the lists, the columns and how it decides what changed or was deleted.
2. Connect SPSync to the same site, tick the same lists and choose your SQL Server database as the destination.
3. Let the first full load finish, then compare the tables with the package’s output, looking hardest at lookup, person and multi-value columns.
4. Point the package’s source at the SPSync tables instead of SharePoint, and remove the watermark and delete logic it no longer needs.
5. Schedule SPSync’s command-line tool as an Agent job step ahead of the package, or let the desktop app run on its own interval.

SPSync as an Integration Services alternative for SharePoint lists

SPSync takes the SharePoint read out of the package. It signs in with modern authentication, reads only what changed through Microsoft Graph, keeps a row for every deleted item and adds new columns by itself. Your SSIS packages keep doing the transforms and then read the SPSync tables in SQL Server like any other source.

Other alternatives

• KingswaySoft: SharePoint source and destination components in the SSIS Integration Toolkit, the closest fit for teams staying on SSIS packages.
• ZappySys: an SSIS PowerPack connector that reads and writes SharePoint Online lists through Microsoft Graph, with ODBC access as well.
• Azure Data Factory: the managed successor to many SSIS estates, with a SharePoint Online List connector for its Copy activity.
• PnP PowerShell: a script on a timer, for teams who would sooner own code than a package and its components.