Last updated: August 29, 2026.
Database users map to server logins by SID. Recreating a login with the same name but a new SID can leave the database user orphaned.
Inspect login metadata
SELECT name, type_desc, sid, is_disabled, default_database_name
FROM sys.server_principals
WHERE type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN','WINDOWS_GROUP')
AND name NOT LIKE '##%';
SELECT name, password_hash
FROM sys.sql_logins
WHERE name = N'AppLogin';Plan the transfer
- Use Microsoft’s supported login-transfer scripting guidance.
- Protect scripts containing password hashes.
- Create Windows identities only where the account exists.
- Verify SID equality on both servers after migration.
Treat login transfer as sensitive administration
Scripts that contain password hashes or login metadata should be protected like credentials. Transfer only required logins and review disabled state, default database, server roles, and permissions on the destination.
After creation, compare SIDs on both servers and test a restored database without changing its user mapping. Windows identities must exist and be resolvable in the destination environment.
- Protect generated scripts.
- Exclude system-created logins.
- Review least privilege after migration.
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 Microsoft login-transfer article, orphaned users, and restore a backup.
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 transfer logins guidance.
