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.

Book a call

Book a call to talk through your use case, see further walkthroughs or demos, and set up a trial in your own environment.

Last updated

SharePoint 2016 or 2019 has reached end of support and the list data needs a home outside the farm before it is switched off.

“Our SharePoint 2019 farm is out of support and we still have list data on it.” That is how most of these projects start. The farm in the basement holds fifteen years of asset registers, contract trackers and old project logs. Support has run out, the security team wants the servers gone, and the hardware lease ends at the close of the financial year. Some of the content is moving to SharePoint Online, and some of it is wanted in a database for reporting or as an archive. Any list that exists only on that farm becomes unreachable the day it is switched off.

When did support for SharePoint Server 2016 and 2019 end?

Both versions follow Microsoft’s Fixed Lifecycle Policy, and both reached the end of extended support on the same day. The lifecycle page for SharePoint Server 2016 gives mainstream support ending on 13 July 2021 and extended support ending on 14 July 2026. The page for SharePoint Server 2019 gives mainstream support ending on 9 January 2024 and extended support ending on 14 July 2026. Microsoft shows these dates in Pacific Time.

Under the Fixed Lifecycle Policy, security updates after the extended end date come only through an Extended Security Update programme, where Microsoft offers one for the product. For most farms the practical position since July is no patches, so the switch-off date is no longer a planning choice. The on-premises version still in support is SharePoint Server Subscription Edition, which follows the Modern Lifecycle Policy.

What SPSync reads today, and what it does not

SPSync does not read on-premises SharePoint. It replicates SharePoint Online and Microsoft Lists through Microsoft Graph, and it has no connector for SharePoint Server 2016, 2019 or Subscription Edition. Moving the farm to Subscription Edition keeps the data on-premises, so it does not change that.

On-premises support is under consideration on our roadmap. If your decommission plan depends on reading straight from the farm, book a call and tell us. We would rather hear about it than have you plan around something that is not built.

Migrate to SharePoint Online, then replicate

The route that works today is to move the lists into SharePoint Online before the switch-off and replicate them from there. Microsoft’s SharePoint Migration Tool lists SharePoint Server 2010, 2013, 2016 and 2019 among its supported sources, and third-party migration products cover the same ground. SPSync takes no part in the migration itself. It starts once the migrated sites exist in SharePoint Online.

The order of work is short. Migrate the farm’s sites. Confirm the lists have arrived in SharePoint Online with their columns and item counts. Sign in to the Online tenant with SPSync, pick the migrated sites and lists, and choose the destination database. Run the first full load and compare the row counts with what the migration reported. A command-line config fits into a decommission runbook as one step.

From SharePoint Online to a database

Once the migrated copy is in SharePoint Online, SPSync replicates it the same way it replicates any Online site. Each list becomes a table with its lookup, choice and person columns; managed metadata columns are not replicated yet. Lookups are key columns and multi-value columns are child tables. SharePoint Online is the system of record from then on, and the database is a copy that stays current with it.

A record that holds up later

Deleted items keep their row with sp_deleted_at set. For a decommission project that matters: if someone tidies the migrated lists in the weeks after the move, the database still shows what existed at the point of migration.

Keep the replication on a schedule so the database follows SharePoint Online as people carry on using the lists, or stop it once you hold the snapshot you need. With nothing left running on-premises, SPSync in your own Azure subscription can host the ongoing sync.

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.

Set it up

Ready to run this against your own site? The setup guide takes you from install to a first replication, and the SharePoint connection guide covers signing in.

Script it

Everything you can click, you can script. The CLI, YAML config and automation below reproduce this scenario exactly. See the CLI reference.

spsync auth login --client-id 00000000-0000-0000-0000-000000000000
spsync export-config --output replication.yaml --pipeline-name decommission_sharepoint_on_prem --prefix decommission_sharepoint_on_prem --destination-kind mssql --connection-string-env SPSYNC_DB_CONNECTION --dataset-name decommission_sharepoint_on_prem --client-id 00000000-0000-0000-0000-000000000000 --site-url https://contoso.sharepoint.com/sites/example --all-lists
spsync doctor replication.yaml
spsync run replication.yaml
pipeline_name: decommission_sharepoint_on_prem
prefix: decommission_sharepoint_on_prem
auth:
  mode: delegated
  client_id: 00000000-0000-0000-0000-000000000000
  tenant_id: common
destination:
  kind: mssql
  connection_string_env: SPSYNC_DB_CONNECTION
  dataset_name: decommission_sharepoint_on_prem
scopes:
  - site_url: https://contoso.sharepoint.com/sites/example
    mode: entire_site
reconcile_interval_days: 7
create_reporting_views: false

Cron (SQL Server nightly):

# every night at 02:00
0 2 * * * cd /opt/spsync && SPSYNC_DB_CONNECTION="$(cat /etc/spsync/db.env)" uv run spsync run replication.yaml >> /var/log/spsync/run.log 2>&1

GitHub Actions:

# .github/workflows/spsync-run.yml
name: SPSync
on:
  schedule:
    - cron: "0 2 * * *"
  workflow_dispatch: {}
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync
      - run: uv run spsync run replication.yaml
        env:
          SPSYNC_DB_CONNECTION: ${{ secrets.SPSYNC_DB_CONNECTION }}
          SPSYNC_LICENCE_KEY: ${{ secrets.SPSYNC_LICENCE_KEY }}

Azure DevOps:

# azure-pipelines.yml
schedules:
  - cron: "0 2 * * *"
    branches: { include: [main] }
    always: true
steps:
  - script: uv sync
  - script: uv run spsync run replication.yaml
    env:
      SPSYNC_DB_CONNECTION: $(SPSYNC_DB_CONNECTION)
      SPSYNC_LICENCE_KEY: $(SPSYNC_LICENCE_KEY)

Windows (PowerShell + Task Scheduler):

# Windows Task Scheduler action (see /docs/cli/automation/)
$env:SPSYNC_DB_CONNECTION = (Get-Content C:\spsync\db.env)
uv run spsync run C:\spsync\replication.yaml
schtasks /Create /SC DAILY /ST 02:00 /TN "SPSync" /TR "powershell -File C:\spsync\run.ps1"

macOS (launchd):

# ~/Library/LaunchAgents/io.spsync.run.plist, then: launchctl load ~/Library/LaunchAgents/io.spsync.run.plist

Secrets (licence key, connection strings) come from the environment, so never write them into the YAML. See scheduling and secrets.

Book a call

Book a call to talk through your use case, see further walkthroughs or demos, and set up a trial in your own environment.