Keeping a copy through tenant migrations and mergers

Last updated 20 October 2026

A tenant migration or merger is planned and list data risks being dropped, renamed or reshuffled in the move, with no independent record of what it looked like before.

Two firms have merged, and the IT team has six weeks to move the acquired company’s SharePoint sites into the parent tenant. The migration tool will move the sites. What it will not do is leave behind a queryable record of what each list held before the move. Column types can be remapped on the way, lookups can break when a target list is recreated, and an item can go missing unnoticed. When the finance team asks in week eight whether every open purchase order came across, the only place to check is the source tenant, and by then it is half decommissioned.

Take a copy before anything moves

Replicate the lists into a database before the migration starts. The pre-migration state then exists independently of whatever the migration tool does to the source tenant. Each list becomes a table with its choice, person and lookup columns; managed metadata columns are not replicated yet. Lookups are key columns, so the relationships between lists are recorded in the copy even if the migration tool handles them differently. Deleted items keep their row with sp_deleted_at set, so the snapshot records everything that existed before the move.

Prove the migration with a second copy

When the move is done, sign in to the destination tenant and replicate the same sites into a second set of tables, in another database or the same one under a different prefix. Now the two copies can be compared directly, row for row and column for column. The week-eight question becomes a query: purchase orders present before, missing after. That is a better answer than the migration tool’s own completion report. Keep the destination replication running afterwards as the ongoing sync.

A migration project often has access to only some sites in the destination tenant. SPSync supports app permissions scoped per site with Sites.Selected, which matches that arrangement.

Mergers of more than two tenants

For a merger of several companies, replicate each tenant’s sites into one database with a table prefix per site. The merged business gets a consolidated view of every list that none of the source tenants ever had, which is often the first report the new leadership asks for.

SPSync does not perform the tenant migration and needs no add-in installed in either tenant. For a project with a runbook, script one config per tenant with the command line and keep both in git, so the before and after copies can be rebuilt on demand.

spsync auth login --client-id 00000000-0000-0000-0000-000000000000
spsync export-config --output replication.yaml --pipeline-name tenant_migration_and_mergers --prefix tenant_migration_and_mergers --destination-kind mssql --connection-string-env SPSYNC_DB_CONNECTION --dataset-name tenant_migration_and_mergers --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: tenant_migration_and_mergers
prefix: tenant_migration_and_mergers
auth:
  mode: delegated
  client_id: 00000000-0000-0000-0000-000000000000
  tenant_id: common
destination:
  kind: mssql
  connection_string_env: SPSYNC_DB_CONNECTION
  dataset_name: tenant_migration_and_mergers
scopes:
  - site_url: https://contoso.sharepoint.com/sites/example
    mode: entire_site
reconcile_interval_days: 7
create_reporting_views: false

# 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/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-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 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"

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