Citrix March 15, 2026 • 8 min read

SQL Server Side-by-Side Migration for Citrix CVAD 2402

Featured Image — CVAD Architecture Diagram

Upgrading Citrix Virtual Apps and Desktops to the 2402 LTSR release is a significant milestone for any enterprise environment. One of the most critical — and often underestimated — components of this upgrade is the SQL Server database migration. In this guide, I'll walk through the side-by-side migration approach that I've used successfully across multiple production environments.

Why Side-by-Side?

A side-by-side migration involves standing up a new SQL Server instance alongside the existing one, migrating the databases, and then cutting over. This approach offers several key advantages over an in-place upgrade:

Zero-downtime cutover with proper planning
Clean rollback path — the old server remains untouched until decommissioned
Opportunity to move to a newer SQL Server version simultaneously
Ability to test the new environment before committing

Prerequisites

Before starting the migration, ensure you have the following in place:

New SQL Server instance installed and configured (SQL Server 2019 or 2022 recommended)
Sufficient disk space for the database files on the new server
Network connectivity between the Citrix Delivery Controllers and the new SQL instance
A maintenance window of at least 2 hours (though the actual downtime is typically under 15 minutes)
Current backups of all Citrix databases: CitrixSiteDB, CitrixMonitorDB, and CitrixLoggingDB

Step 1: Backup the Existing Databases

Start by taking full backups of all three Citrix databases. I always use a PowerShell script to ensure consistency and include timestamps in the backup filenames:

# Citrix CVAD Database Backup Script
$SqlServer = "YOUROLDSERVER\YOURINSTANCE"
$BackupPath = "E:\SQLBackups\CVAD_Migration"
$Timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
$Databases = @("CitrixSiteDB", "CitrixMonitorDB", "CitrixLoggingDB")

foreach ($db in $Databases) {
    $BackupFile = Join-Path $BackupPath "$($db)_$Timestamp.bak"
    Backup-SqlDatabase -ServerInstance $SqlServer `
        -Database $db `
        -BackupFile $BackupFile `
        -CompressionOption On
    Write-Host "Backed up $db to $BackupFile" -ForegroundColor Green
}
            

Step 2: Restore to the New SQL Server

Copy the backup files to the new SQL Server and restore them. Pay attention to the file paths — you'll likely need to use WITH MOVE to relocate the data and log files to the correct directories on the new server.

Pro tip: Always verify the restored databases by running a quick row count comparison against the source databases. It takes 30 seconds and can save you hours of troubleshooting.

Handling Orphaned Users

After restoring the databases, you'll need to fix orphaned SQL users. This is a common gotcha that catches many admins off guard. The SIDs of the SQL logins on the new server won't match the old ones, so the database users become orphaned.

-- Fix orphaned users on the new SQL Server
USE CitrixSiteDB;
EXEC sp_change_db_owner 'sa';
ALTER USER [CitrixAdminUser] WITH LOGIN = [CitrixAdminUser];
GO
            

Step 3: Update the Citrix Site Connection Strings

This is where the actual cutover happens. On each Delivery Controller, you'll update the connection strings to point to the new SQL Server. The key commands are:

# Run on each Delivery Controller
asnp Citrix.*

# Update Site database
Set-ConfigDBConnection -DBConnection $null
Set-ConfigDBConnection -DBConnection "Server=NEWSERVER\INSTANCE;Database=CitrixSiteDB;Integrated Security=True"

# Update Monitor database
Set-MonitorDBConnection -DBConnection $null
Set-MonitorDBConnection -DBConnection "Server=NEWSERVER\INSTANCE;Database=CitrixMonitorDB;Integrated Security=True"

# Update Logging database
Set-LogDBConnection -DBConnection $null
Set-LogDBConnection -DBConnection "Server=NEWSERVER\INSTANCE;Database=CitrixLoggingDB;Integrated Security=True"
            

Step 4: Validate and Test

After updating the connection strings, validate the environment:

Run Get-BrokerSite to confirm the site is healthy
Check Citrix Studio — all services should show as "OK"
Launch a test application or desktop session
Verify that the Monitor service is logging data to the new database
Confirm configuration logging is working by making a minor change in Studio

Rollback Plan

If anything goes wrong, rolling back is straightforward since we didn't modify the original SQL Server. Simply revert the connection strings on each Delivery Controller to point back to the old SQL instance. The entire rollback can be completed in under 5 minutes.

Common Issues

In my experience, the most common issues during this migration are:

Firewall rules — Ensure port 1433 (or your custom SQL port) is open between the Delivery Controllers and the new SQL Server
Service account permissions — The Citrix service account needs db_owner on all three databases
SQL collation mismatch — The new SQL instance should use Latin1_General_CI_AS_KS collation to match Citrix requirements

This migration pattern has worked reliably across environments ranging from 50 to 5,000+ concurrent users. The key is preparation — if your backups are solid and you've tested the restore process, the actual cutover is anticlimactic (which is exactly what you want).