Transfer SQL Server Logins and Passwords Between Instances

Last updated: August 25, 2026.

Database users and server logins are separate SQL Server objects. When a database moves to another instance, transfer its SQL-authenticated logins with the same security identifiers (SIDs) and password hashes so the database users continue to map correctly.

Generate login scripts on the source instance

Microsoft provides the sp_help_revlogin procedure for generating CREATE LOGIN statements that preserve the SID and password hash. Install the procedure from the Microsoft login-transfer instructions, then run:

USE master;
GO
EXEC dbo.sp_help_revlogin;
GO

To script only one login:

EXEC dbo.sp_help_revlogin @login_name = N'app_login';

Review the generated statements, transfer them securely, and execute them on the destination instance using an account authorized to create logins. Do not publish or email the output as ordinary text; password hashes are sensitive.

Verify the destination

SELECT name, sid, type_desc, is_disabled
FROM sys.server_principals
WHERE name = N'app_login';

Restore or attach the databases after the required logins exist. If a database user is orphaned, map it to the destination login:

USE ApplicationDatabase;
GO
ALTER USER [app_user] WITH LOGIN = [app_login];
GO

Items to transfer separately

• Server roles and explicit server-level permissions.
• SQL Server Agent jobs, credentials, proxies, linked servers, and certificates.
• Windows logins and groups, which depend on the destination server’s domain access.
• Logins on every replica or node that may accept connections after failover.

Contained database users and Azure SQL services use different migration workflows. Test application sign-in and least-privilege permissions before switching production traffic.