Restore a SQL Server Backup to Another Server

Last updated: August 29, 2026.

Restoring to another server usually requires new physical file paths. Inspect the backup first, restore with MOVE, and then handle logins, jobs, and application configuration separately.

Inspect and restore

RESTORE FILELISTONLY FROM DISK = N'D:\Backup\Sales.bak';
GO
RESTORE DATABASE Sales
FROM DISK = N'D:\Backup\Sales.bak'
WITH MOVE N'Sales_Data' TO N'E:\SQLData\Sales.mdf',
     MOVE N'Sales_Log'  TO N'F:\SQLLog\Sales_log.ldf',
     RECOVERY, STATS = 5;

Post-restore checks

• Run DBCC CHECKDB according to your recovery procedure.
• Remap logins and review database ownership.
• Update connection strings and dependent jobs.
• Confirm encryption keys and certificates when used.
• Test backups on the new server.

Plan beyond the database files

A successful restore does not move server logins, Agent jobs, linked servers, credentials, or application settings. Include those objects in the migration checklist and use new physical file paths appropriate for the destination.

Run integrity checks, compare expected users, and test application queries before cutover. Confirm that backup jobs and recovery objectives are configured on the new server.

• Inspect logical file names first.
• Remap or transfer logins.
• Handle encryption keys and certificates.

Run administrative statements first in a controlled environment and record the current configuration. Keep a rollback or restore path, use least privilege, and verify the result through the same client path used by the application.

Continue with transfer logins, orphaned users, and move Agent jobs.

Practical implementation check

Before changing production, record the server version, relevant configuration, current object state, and a tested recovery path. Run the diagnostic query with an account that has only the permissions it needs. Apply the smallest change that addresses the evidence, then repeat the original check and monitor application behavior instead of assuming a successful statement completed the task.

Record the final setting or object state in the deployment notes, including why it was chosen. That evidence makes later capacity reviews, migrations, and incident response substantially faster.

Reference: Microsoft RESTORE documentation.