Move SQL Server Agent Jobs to Another Server

Last updated: August 29, 2026.

A job definition is only one part of migration. Job owners, credentials, proxies, linked servers, file paths, and databases must also exist on the destination.

Inventory jobs and schedules

USE msdb;
SELECT j.name AS JobName, SUSER_SNAME(j.owner_sid) AS OwnerName,
       s.name AS ScheduleName, s.enabled AS ScheduleEnabled
FROM dbo.sysjobs AS j
LEFT JOIN dbo.sysjobschedules AS js ON js.job_id = j.job_id
LEFT JOIN dbo.sysschedules AS s ON s.schedule_id = js.schedule_id
ORDER BY j.name, s.name;

Migration checklist

• Script jobs from SQL Server Management Studio.
• Set a valid low-privilege owner.
• Recreate credentials and proxies separately.
• Disable schedules until a manual test succeeds.
• Confirm alerting and job history retention.

Inventory every external dependency

A job script does not include every credential, proxy, linked server, file path, executable, or operator it depends on. Record those dependencies and recreate them separately with appropriate permissions.

Keep schedules disabled on the destination until each step succeeds manually. Verify job ownership, output files, notifications, and the expected database context before enabling production schedules.

• Use a valid low-privilege owner.
• Recreate proxies securely.
• Avoid duplicate schedules during cutover.

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 restore to another server and transfer logins.

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 SQL Server Agent documentation.