50 databases. 30 minutes each — backup plus restore, running sequentially. That is 25 hours of database work before a single SharePoint site comes online on the new server. 25 hours does not fit in a migration weekend. It barely fits between Friday night and Monday morning, with no margin for a failed restore, a network hiccup, or a rollback.

This is not an edge case. It is the default outcome when you run a standard SharePoint database migration without a parallel execution strategy — and it is the most common reason migration weekends fail or extend into production hours.

The solution is throttled parallel backup and restore. Instead of processing databases one at a time, you run four, six, or eight concurrent backup-and-restore jobs simultaneously, with a configurable throttle limit that protects your SQL Server and storage from I/O saturation. The arithmetic is straightforward: 50 databases across 6 concurrent jobs at 30 minutes each takes roughly 4.5 hours instead of 25.

This post covers four PowerShell scripts that implement this pattern at production scale:

• Parallel-Migrate-Full.ps1 — the full parallel backup and restore orchestrator, with configurable throttle limit, retry logic, per-DB logging, and progress reporting
• Direct-ParallelBackup.ps1 — parallel backups only, without the restore step, purpose-built for seeding log shipping secondaries
• RestoreBackup_Script.ps1 — standalone restore for individual databases with WITH NORECOVERY and WITH RECOVERY mode support
• DBBackup_Script.ps1 — standalone backup for individual databases

By the end of this post you will understand the throttled parallel job pattern, know when to use each script, and have a clear performance tuning checklist for your environment.

The Sequential Migration Problem at Scale

The Arithmetic Nobody Wants to Do

Before any script or architecture discussion, there is a calculation that every SharePoint admin running a large database estate needs to do. It looks simple. The result is usually alarming.

Planning note: These are estimates based on a 30-minute average per database across backup, transfer, and restore. Actual times depend on database size distribution, backup compression ratio, disk throughput, and network bandwidth to the backup share. Always run a pilot with five databases before your production migration window.

The top row and the last row are the two failure modes. Sequential is too slow. Unlimited concurrency is too dangerous. The middle rows — four to eight concurrent jobs — represent the range that most SQL environments can sustain safely, and that range is where a 25-hour window becomes a 4-hour window.

Why Unlimited Parallel Is Not the Answer

The instinct when you see the sequential number is to ask: why not just run all 50 jobs at once and finish in 30 minutes? The answer is infrastructure physics.

I/O channel saturation. SQL Server backup streams compete for disk channels. If your backup target is a file share or a SAN LUN, 50 simultaneous write streams will saturate the channel long before all 50 jobs finish. You get I/O waits, job stalls, and backup files that take three times longer to write than they would sequentially — which defeats the purpose.

SQL Server worker thread exhaustion. Every concurrent backup or restore operation consumes SQL Server worker threads. On a busy migration server, launching 50 simultaneous backup jobs can exhaust the max worker thread pool, causing connection failures for jobs that start later in the batch. A conservative throttle limit — typically no more than half the available worker threads — keeps the thread pool healthy throughout the run.

Network bandwidth saturation. If you are backing up across a network to a remote backup server or NAS, 50 concurrent streams at 100–200MB/s each will saturate even a 10Gb link. The throttle limit is your network bandwidth protection as much as it is a SQL resource governor.

The throttle limit is not a restriction on what the scripts can do. It is the safety mechanism that makes overnight unattended runs reliable.

How Parallel Backup and Restore Works — The PowerShell Job Pattern

PowerShell Background Jobs as the Execution Engine

The parallel execution pattern in Parallel-Migrate-Full.ps1 is built on PowerShell background jobs — the Start-Job, Get-Job, and Wait-Job cmdlets that allow you to run multiple script blocks simultaneously in separate PowerShell processes.

The orchestrator works in a polling loop:

1. Read the database list from a CSV file
2. Check how many jobs are currently running
3. If the running count is below the throttle limit, start the next backup job
4. If the running count has reached the throttle limit, wait and poll until a slot opens
5. Repeat until all databases have been submitted and all jobs have completed
6. Run retries for any failed databases
7. Write the final summary report

Here is the core pattern, simplified for clarity:

# Example: throttled parallel job loop
$ThrottleLimit = 6
$Jobs = @()
foreach ($db in $DatabaseList) {
    # Wait until we're below the throttle limit
    while (($Jobs | Where-Object { $_.State -eq 'Running' }).Count -ge $ThrottleLimit) {
        Start-Sleep -Seconds 5
        $Jobs = $Jobs | Get-Job
    }
    
    # Start the next backup job
    $job = Start-Job -ScriptBlock {
        param($DatabaseName, $BackupPath)
        # Backup logic here
        Backup-SqlDatabase -ServerInstance $using:SqlInstance -Database $DatabaseName -BackupFile "$BackupPath\$DatabaseName.bak"
    } -ArgumentList $db.Name, $BackupPath
    
    $Jobs += $job
    Write-Host "Started backup job for: $($db.Name)"
}
# Wait for all remaining jobs
$Jobs | Wait-Job | Receive-Job

This is the core pattern. The production script, Parallel-Migrate-Full.ps1, adds CSV-driven database input, per-DB structured logging to a timestamped output file, configurable retry logic, job state polling with live progress output, and an end-of-run summary report designed for migration sign-off. That additional complexity is what makes it a production tool rather than a proof of concept.

The full Parallel-Migrate-Full.ps1 is part of the SQL Migration Bundle — more on that at the end of this post.

Key Parameters — What to Configure Before You Run

There are four parameters that must be set correctly before you run the orchestrator. Treat this as a pre-flight checklist, not a parameter reference.

The -ThrottleLimit setting is the one that requires the most environment-specific judgement. A value of 4 is a safe conservative start for most SQL environments. A value of 8 is appropriate for environments with fast local backup storage, high-spec SQL servers, and 10Gb+ network connectivity. Running a five-database pilot at your target throttle before the production migration window is always worth the 30-minute investment.

The Retry Logic — Why It Is Not Optional

What Causes Transient Failures in Parallel Runs

In a sequential migration, failures are rare and easy to identify. In a parallel run across 50 databases, transient failures are statistically normal. In a busy datacenter environment, expect two to five transient failures on the first attempt of a 50-database run. That is not a script problem — it is the reality of parallel I/O in shared infrastructure.

The most common causes in production parallel runs are:

• Backup share I/O contention. Multiple jobs writing to the same network share simultaneously create write queue backlogs. Jobs that start while the queue is deep can time out before the first write completes.
• SQL Server connection pool exhaustion during burst starts. When the orchestrator launches six jobs in rapid succession at the start of a run, the connection pool may briefly exhaust. Jobs that start during this burst are more likely to hit connection failures.
• Network timeouts to remote SQL instances. If your source and destination SQL instances are on different network segments, high-load periods generate transient TCP timeouts that appear as backup or restore failures.
• Antivirus scan interference. Real-time antivirus scanning on backup target directories is a surprisingly common source of mid-write failures. The AV process locks a backup file for scanning just as SQL Server is writing to it.

None of these failures are deterministic. Run the same 50 databases again immediately after and different databases will fail. Retry logic handles all of them.

How the Retry Logic Works

After the initial parallel run completes, the orchestrator collects all failed databases into a retry queue. Each database in the queue is retried up to -RetryCount times (default: 3), with a configurable delay between attempts to allow temporary contention to resolve.

The retry runs are sequential by default — one failed database at a time — because by the time the retry queue runs, the main parallel batch has finished and there is no longer any contention from the primary run. This means retries are fast and almost always succeed.

Every database gets one of three final statuses in the output log:

• Success — completed on the first attempt
• RetrySucceeded — failed on the first attempt but succeeded on retry
• Failed — failed all retry attempts and requires manual intervention

The script never silently skips a database. If a database fails all retries, it is flagged explicitly in the end-of-run summary report with the last error message, so the migration team can address it before the cutover window closes.

Monitoring Progress — Per-DB Status and Job Reporting

Running 50 background jobs overnight without visibility is not acceptable in a production migration context. Parallel-Migrate-Full.ps1 provides several layers of progress visibility designed for unattended overnight runs.

Console output at each polling interval displays the live job state: Running: 6 | Completed: 22 | Failed: 0 | Remaining: 22. This updates every polling cycle (default: 10 seconds) so an admin who checks the terminal at any point can see exactly where the run stands.

Per-DB log entries are written as each job completes, not only at the end of the run. Each entry includes the database name, job ID, start time, end time, duration, backup file size, and final status. This means if the script is interrupted mid-run, the completed database records are already persisted.

The log file path is written to the console at script start. This allows an admin to open a second terminal session and monitor the log file in real time using Get-Content -Path $logPath -Wait — the PowerShell equivalent of tail -f.

An end-of-run summary report is generated after all jobs complete (including retries), listing every database with its final status and any error details for failed databases. This summary is designed to serve as a migration checkpoint sign-off document.

Combining Parallel Backup with Log Shipping — The Initial Seeding Pattern

The Problem with Seeding Log Shipping One Database at a Time

If you followed Post #6 of this series on SQL Log Shipping for SharePoint Migration, you already know the goal: establish a live log shipping relationship between your SP2019 source and your SPSE destination during the week before cutover, so that the final cutover window only needs to apply a small tail of transaction logs rather than a full backup-and-restore cycle.

The problem is the initial seeding step. To establish a log shipping relationship, you must restore a full backup of each source database to the secondary server — with WITH NORECOVERY, so the database remains in a restoring state ready for subsequent log backups. For 50 databases, done sequentially, that seeding process takes 20 or more hours before the first log chain is even established.

Starting log shipping synchronisation 20 hours into a migration week leaves less time for the secondary to catch up before the cutover window. It also means the seeding process itself may run into the next business day if it starts Monday night.

Using Direct-ParallelBackup.ps1 for Fast Initial Seeding

Direct-ParallelBackup.ps1 solves the seeding problem by running only the parallel backup phase — without the restore step. It generates full backup files for all source databases concurrently, producing 50 ready-to-restore backup files in 2–4 hours instead of 20+ hours.

The workflow integrates directly with the log shipping setup from Post #6:

1. Run Direct-ParallelBackup.ps1 on the source SQL Server to generate all full backups in parallel (2–4 hours)
2. Copy backup files to the secondary server location — or reference them from the shared backup path
3. Run Configure-LogShippingJobs.ps1 (covered in Post #6) — it restores each full backup WITH NORECOVERY and begins the transaction log chain
4. Let log shipping run continuously through the migration week to keep the secondary in sync
5. On the cutover weekend, apply the final log backup, bring databases online, and mount them in SharePoint Subscription Edition

This pattern compresses the seeding step from a 20-hour sequential process to a 3-4 hour parallel one, giving log shipping maximum time to synchronise before the cutover window opens.

Direct-ParallelBackup.ps1 is included in the SQL Migration Bundle alongside Configure-LogShippingJobs.ps1, Parallel-Migrate-Full.ps1, and the full suite of standalone backup and restore scripts — everything you need to run the database layer of a SharePoint migration from initial seeding to final cutover.

Standalone Scripts vs Full Orchestrator — When to Use Which

Not every migration task requires the full parallel orchestrator. The four scripts in this post cover a range of use cases, from a single ad-hoc database backup to a complete 50-database parallel migration run.

RestoreBackup_Script.ps1 — NORECOVERY vs RECOVERY Mode

This is the detail that trips up SharePoint admins without a SQL DBA background, and getting it wrong means a restore that looks successful but leaves the database in an unusable state.

WITH RECOVERY brings the database online after the restore completes. This is the mode you use in the standard backup-and-restore migration flow: back up the source database, restore it to the destination server WITH RECOVERY, and the database is immediately accessible. This is the default for the parallel orchestrator.

WITH NORECOVERY leaves the database in a restoring state — not online, but ready to receive additional transaction log backups. This mode is required when you are seeding a log shipping secondary. If you restore WITH RECOVERY when setting up log shipping, the database comes online but the log chain cannot be established, and log shipping configuration will fail.

RestoreBackup_Script.ps1 exposes both modes through a parameter switch, with clear validation to prevent accidental cross-mode restores. For a standard migration restore, use WITH RECOVERY. For log shipping seeding, use WITH NORECOVERY.

Performance Tuning for Parallel Backup and Restore

The difference between a 4-hour parallel run and an 8-hour one is often infrastructure configuration, not the script. These six tuning points apply regardless of which scripts you use.

1. Enable backup compression at the server level.
SQL Server backup compression reduces backup file size by 60–75% for SharePoint content databases, which consist mostly of structured data that compresses well. A 100GB content database produces roughly a 25–30GB compressed backup file. Smaller files mean faster writes and faster restores across the network.

EXEC sp_configure 'backup compression default', 1;
RECONFIGURE;

If this is not already enabled on your SQL instance, enable it before your pilot run. The impact on I/O-constrained environments is significant.

2. Use a dedicated backup volume — separate from SQL data.
Backing up to the same physical disk as SQL data files creates I/O contention that degrades both backup speed and any live SharePoint traffic still running on the source farm. Use a dedicated backup mount point with its own disk channel. On SAN environments, verify that backup LUNs are on separate storage pools from data LUNs — same SAN, different pool, is not the same as separate I/O channels.

3. Put transaction log backups on a third volume.
If you are running log shipping in parallel with your migration, transaction log backups (for the log shipping jobs) should land on a separate volume from both data and full backups. This is standard SQL DBA practice but commonly ignored in SharePoint farms that grew without a dedicated DBA.

4. Place TempDB on fast local storage.
Parallel restores generate significant TempDB activity — sort operations, version store pressure, and internal buffer use. If TempDB is on the same volume as your SQL data files or the backup target, restore times will degrade under parallel load. Place TempDB on fast local SSD storage with enough pre-allocated space to avoid autogrowth events during the restore window.

5. Pre-calculate and verify backup storage capacity.
Before launching a 50-database parallel backup run, calculate the required storage: total content database size × compression ratio (estimate 0.35 for compressed backups) × 1.2 safety margin. Running out of disk space at database 40 of 50 mid-migration is an avoidable failure mode that has ended more than a few migration weekends.

6. Pilot at throttle 4 before scaling up.
Do not set -ThrottleLimit 8 on the first run in a new environment. Run a five-database pilot at throttle 4, observe SQL Server performance counters (I/O wait times, worker thread utilisation, backup throughput), and then scale up. A pilot run is 30 minutes of work that prevents a 6-hour overnight run from stalling at hour 3.

Conclusion

The 25-hour sequential window is a solved problem. Throttled parallel backup and restore — with configurable concurrency, per-DB retry logic, and live progress reporting — compresses a weekend-killing database migration into a manageable overnight window. Combined with the log shipping seeding pattern from Post #6, the full database layer of a 50+ database SharePoint migration can be prepared and synchronised during the week before cutover, leaving the actual cutover weekend as a final log application and farm mount operation.

Once your databases are restored and online on the SharePoint Subscription Edition server, the next phase begins: the cutover itself. Post #8 covers the Cutover Playbook — the step-by-step process for detaching content databases from SP2019, mounting them in SPSE, verifying site collection accessibility, and managing rollback if anything goes wrong. The databases you restore using the scripts in this post are exactly the ones you will be mounting in Post #8.

If you are adding your migrated content databases to a SQL Server Availability Group after migration, Post #9 covers Availability Groups and SharePoint — including the Add-DatabasesToAG.ps1 script that handles bulk AG enrollment for large database estates.

Get the SQL Migration Bundle — Cut Your Migration Window from 25 Hours to 4 Hours

The scripts in this bundle can reduce a 25-hour sequential database migration to under 5 hours.

The SQL Migration Bundle includes every script needed to run the database layer of a SharePoint 2019 → Subscription Edition migration:

• Parallel-Migrate-Full.ps1 — parallel backup + restore orchestrator with configurable throttle, retry logic, per-DB structured logging, and end-of-run summary report
• Direct-ParallelBackup.ps1 — parallel backup only, purpose-built for seeding log shipping secondaries at scale
• RestoreBackup_Script.ps1 — standalone restore with WITH NORECOVERY / WITH RECOVERY mode selection
• DBBackup_Script.ps1 — standalone database backup
• Configure-LogShippingJobs.ps1 — log shipping setup from Post #6
• Disable-LogShippingJobs.ps1 — pre-cutover log shipping pause
• Decommission-LogShipping.ps1 — post-cutover log shipping cleanup
• Add-SecondaryDatabases.ps1 and Add-DatabasesToAG.ps1 — Availability Group integration
• Bring-DatabasesOnline.ps1, Simulate-ChainBreak.ps1, Repair-ChainWithDiff.ps1 — operational utilities for log shipping maintenance

Every script includes input validation, structured error handling, and a README with full parameter reference and example usage.

Contact sudharsan_1985@live.in to get the SQL Migration Bundle.

If you have questions about whether the bundle fits your environment, leave a comment below or reach out directly. I am happy to help you plan the right approach for your database estate.

This is Post #7 of a 12-part series on SharePoint 2019 to Subscription Edition migration. Previous post: [Post #6 — SQL Log Shipping for SharePoint Migration]. Next post: [Post #8 — The Cutover Playbook].