What teams copy SharePoint lists out for
Every page below starts from one team's problem and shows what the replicated tables change. The AI and agent group covers Copilot Studio, agents with SQL tools, text-to-SQL chat, retrieval with embeddings and the document catalogue. Those pages are also gathered by reader on AI and agents on SharePoint data.
Reporting and analytics
- Excel and Access refreshing from SQL, not from lists
Point Excel workbooks and Access databases at SQL copies of SharePoint lists, so Refresh All takes seconds again.
- Fast, reliable Power BI on SharePoint data
Move Power BI off the SharePoint List connector onto SQL tables, so refreshes finish and DirectQuery becomes an option.
- Joining lists on lookups the way SharePoint cannot
Join related SharePoint lists in SQL: SPSync turns every lookup into a key column pointing at the replicated table it refers to.
- Operational dashboards that stay current within a few minutes
Run wall dashboards and KPI boards from SQL copies of SharePoint lists, refreshed every few minutes, with Graph polled by one job only.
- Reporting and analytics on SharePoint list data
Report on SharePoint lists from SQL tables in Power BI, Excel, Tableau or SSRS, with lookups already joinable and Graph out of the refresh.
- Reporting past the 5,000-item threshold
Keep reporting on SharePoint lists past 5,000 items: SPSync reads through Graph paging, never a view, into SQL tables.
- SSRS, Crystal Reports and paginated reports
Give SSRS and Crystal Reports a SQL data source again: SharePoint lists replicated into SQL Server, Azure SQL, Oracle or Postgres.
- Tableau, Looker, Metabase and Grafana on SharePoint data
Connect Tableau, Looker, Metabase or Grafana to SharePoint list data through a SQL database or warehouse copy, with no CSV exports.
AI and agents
- An agent data layer for SharePoint, with one SQL copy every agent reads
Give every AI agent one replicated SQL copy of your SharePoint lists, four database tools and a database login, and keep Graph traffic with SPSync.
- Grounding Copilot Studio and custom agents on clean tables, not raw lists
Ground Copilot Studio or a custom agent on typed SQL tables replicated from SharePoint, so lookups and tags answer as names and counts.
- Giving agents SQL tools over SharePoint data safely, with read-only replicas and row-level rules
Hand an AI agent a SQL tool over a read-only copy of SharePoint lists, with no Graph permissions for it to misuse or overload.
- Natural-language questions over SharePoint data through text-to-SQL, without giving the model SharePoint access
Let people ask SharePoint data questions in plain English: a text-to-SQL tool queries a replicated SQL copy, never SharePoint itself.
- Retrieval-augmented generation over list data with pgvector or Azure AI Search
Retrieval-augmented generation over SharePoint lists, with SPSync writing the embeddings into pgvector or Azure AI Search on every sync.
- Embeddings and semantic search over free-text columns
Search the free text in SharePoint lists by meaning, with SPSync embedding the columns you choose into Postgres and pgvector.
- Library metadata as the catalogue that tells an AI which documents matter
Keep document-library metadata in SQL so an AI system can filter, rank and cite SharePoint documents without listing the library on each question.
- Enterprise search over list data with Azure AI Search, Elasticsearch or OpenSearch, with facets and filters on resolved values
Build a search page over SharePoint lists on Azure AI Search, Elasticsearch or OpenSearch, with facets on resolved values and delta updates.
- Clean, typed, deduplicated training and evaluation sets from SharePoint-held records
Build training and evaluation sets from typed SharePoint tables, with no Graph export to clean and retype before every model project.
Data platform
- dbt models over replicated SharePoint tables
Declare SharePoint lists in dbt's sources.yml: SPSync replicates them into your warehouse with a schema that changes predictably.
- Feeding ERP and CRM integrations from SharePoint-held records
One SQL copy of a SharePoint list for every ERP and CRM integration to read, so none of them calls Graph or parses lookup IDs.
- Parquet, Iceberg and Delta in the lake, ready for Spark and DuckDB
Put SharePoint lists in the lake as Parquet, Iceberg or Delta tables that Spark, Trino and DuckDB read with no loading step.
- Reference and master data teams keep in lists, served to every system
Serve cost centres, product codes and approved vendors from SharePoint lists to every system that needs them, through one SQL copy.
- Replacing Data Factory pipelines and scheduled flows that read SharePoint
Retire the Data Factory copy activity or Power Automate flow that moves SharePoint lists into a database, and keep the rest of the pipeline.
- SharePoint as a governed warehouse source
Bring SharePoint lists into the warehouse as a governed source, with a stable schema, predictable drift and lineage like any other feed.
Applications
- A read replica for internal apps, APIs and integrations
Give internal apps and integrations a stable SQL copy of SharePoint lists to read, and take Graph out of every request.
- Building web and mobile apps on data the business keeps in SharePoint
Build a web or mobile app on data the business keeps in SharePoint, with Supabase or Postgres tables that SPSync keeps current.
- Power Apps reading SQL for large lists, with SharePoint still where people edit
Fix Power Apps delegation on large lists: galleries read a SQL copy of the list, and edits still go to SharePoint.
- SharePoint and PostgreSQL two-way sync, what works today
Most requests for SharePoint and Postgres two-way sync are a heavy read and a light write. SPSync handles the read today; write-back is designed.
Governance and migration
- Continuous backup and history of lists
A queryable copy of each SharePoint list outside SharePoint, refreshed every few minutes, with deleted items kept on record.
- Keeping a copy through tenant migrations and mergers
Keep an independent SQL copy of SharePoint lists through a tenant-to-tenant migration or merger, then prove the move row by row.
- Migrating list data off SharePoint into a database
Move list data off SharePoint without a frozen export: replicate into the target database, keep it current, then cut the application over.
- Planning the exit from on-premises SharePoint
SharePoint Server 2016 and 2019 support ended on 14 July 2026. Migrate the lists to SharePoint Online, then replicate them into a database with SPSync.
- Point-in-time archive with soft deletes for audit
Keep an audit record of SharePoint lists in a database you control, where deleted items stay on file with the time they were removed.
- Scriptable migrations: config in git, reviewed in PRs, run from CI, batched across many sites, re-runnable
Script SharePoint replications as YAML in git: reviewed in pull requests, run from CI, batched across many sites and safe to re-run.
- The same list on many sites into one table
One SQL table set for a list template copied across many sites, with a table prefix per site and one batch file to configure them all.