iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Migrating a SQL Server database to an instance in another Active Directory domain takes two related jobs: restore the user database on the target instance, then rebuild or verify the server logins, Windows identities, services, and remote connections that let applications use it. A database restore moves database contents; it does not automatically move all instance-level configuration or make Windows authentication work across the new domain boundary.
What moves with the database—and what does not
A backup-and-restore migration is a documented way to copy a user database to another SQL Server instance. Database users and database-level permissions are in the database, but the server-level logins they rely on, SQL Agent jobs, linked-server settings, and service identities may need separate work on the destination. Microsoft’s backup-and-restore guidance describes the database move; its login-transfer guidance covers login migration.
| Migration item | What to expect |
|---|---|
| User database | Moves through backup and restore; database files can be placed at different target paths during restore. |
| Database users and permissions | Travel with the database, but a user may no longer match a destination login if its SID differs. |
| Server-level logins | Must be transferred or created on the target instance; a restore does not supply them. |
| Jobs, linked servers, service identities, and external access | Must be inventoried and reconfigured or validated separately where the destination needs them. |
The domain change is therefore primarily an identity and authentication issue, not a special database-file conversion. Windows accounts with the same apparent username in different domains are different security principals and have different SIDs.
Plan the migration around its dependencies
Inventory source and target
Record the source and destination SQL Server versions and editions, instance names, database files and paths, authentication mode, database owners, and the identities used by applications and administrators. Inventory Windows logins and groups, SQL logins, SQL Agent jobs, linked servers and their login mappings, service accounts, file shares, certificates, and any mirroring or availability-group configuration.
#1 Best Overall
- Classify each connection as Windows integrated authentication or SQL authentication.
- Identify every job, service, or application that reads or writes to a domain resource, such as a file share.
- Note which logins own databases, jobs, or other server-level objects so they can be reassigned deliberately if necessary.
- Confirm the source and target SQL Server versions before selecting a move plan. SQL Server backups cannot be restored to an earlier SQL Server version.
There is no single downtime or low-downtime method prescribed by the cited Microsoft migration guidance. A one-time backup and restore is straightforward, but the team must account for writes made after the backup and before cutover. Database size, transfer time, target file layout, version compatibility, authentication type, and external dependencies all affect the plan.
Move the user database to the target instance
- Take and verify a suitable backup. Coordinate the backup point with the application owner and the cutover plan. Keep the source available until the restored copy and dependent services have been validated.
- Inspect the backup’s file layout. On the target, use
RESTORE FILELISTONLYto identify the logical and physical file names before restoring. - Restore to the target instance. If the destination paths differ, use
WITH MOVEfor the database files or create equivalent paths as appropriate. Follow Microsoft’s backup-and-restore workflow and check the restored database state before directing applications to it. - Check database ownership. The login or Windows user that initiates the restore becomes the new database owner. The system administrator or new owner can change ownership afterward; verify that the resulting owner is intentional.
Do not treat a system-database restore as a shortcut for moving instance configuration. Microsoft notes that backups cannot be restored to an earlier SQL Server version, and earlier-version backups of master, model, and msdb are not restored by later versions. Plan system-database or instance-level migration separately.
Recreate logins and fix orphaned database users
Transfer or create server logins
Database users are not a substitute for server logins. Transfer the required SQL logins and create the destination Windows logins or groups before application testing. Microsoft’s procedure for transferring SQL Server logins and passwords can preserve SQL login password hashes across instances. Review its generated statements rather than running them blindly: replace source-domain Windows identities with the intended destination identities and resolve conflicts or destination-specific settings.
Free tools Windows power users keep installed
One-click scans. No signup required.
The documented login-transfer procedure does not transfer a login’s default database setting. Check and set that separately where applications or users depend on it.
Map users to the correct destination login
When a restored database user’s SID no longer matches a destination login—commonly the case when the Windows identity is in a different domain—the user can be orphaned: the database user remains, but SQL Server cannot associate it with the intended login. Microsoft summarizes the relationship this way: “In SQL Server, the SID for a login governs database-level access.”
- Identify the affected database users and the correct destination logins, including whether each should map to a user or a group.
- Map each user to its intended login using an appropriate user-remapping method for the SQL Server version and validate the mapping in the target database.
- Verify database ownership, role membership, explicit grants, and application dependencies before changing or removing any principal. Do not drop and recreate users indiscriminately; that can discard permissions or affect ownership.
After remapping, test with the actual application identity. A successful administrator connection does not demonstrate that the migrated users have the intended permissions.
Reconfigure services and remote Windows authentication
SQL Server and SQL Server Agent identities
Choose service identities according to the destination’s least-privilege design. If SQL Server or SQL Server Agent must reach domain resources, Microsoft recommends considering a minimally privileged domain account and documents managed service accounts, including group-managed service accounts. Confirm the service logon rights, local permissions, file-share access, and SPN registration for the account and topology in use. See Microsoft’s service-account guidance and SPN guidance.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsLinked servers and pass-through authentication
Review each linked server’s local-to-remote login mapping. If it passes Windows credentials through to another server, verify the required Kerberos and delegation configuration, as well as the relevant SPNs; a successful restore does not establish that a cross-server query will authenticate. Microsoft’s linked-server authentication details state that pass-through supports full delegation. Constrained delegation support begins with SQL Server 2017 CU17; resource-based constrained delegation is not supported in the cited documentation. Confirm the precise SQL Server release and applicable configuration before implementing delegation.
Best Value
Microsoft also documents managed-identity authentication for linked servers beginning with SQL Server 2025 (17.x) in a defined Azure VM or Azure Arc and Microsoft Entra configuration. That is a deployment- and version-specific option, not a general replacement for domain identity planning. See sp_addlinkedserver documentation.
Check availability and mirroring identities
For database mirroring or availability-group configurations, review the identities used to start SQL Server on the participating instances. When startup accounts differ, Microsoft’s setup guidance calls for creating the required logins and granting them CONNECT permission on the relevant endpoint. Apply the guidance for the specific topology and validate endpoint connectivity before cutover: Microsoft’s mirroring and availability login setup.
Test the destination before cutover
Run a controlled test restore and validate the database and its dependencies before applications are pointed at the target. Use the real service and application identities—not just an administrator account.
- Confirm the restored database is in the expected state and that applications can connect.
- Test Windows and SQL login behavior, database roles, explicit permissions, and database ownership.
- Run SQL Agent jobs and verify linked-server queries and any required file-share access.
- Confirm backup jobs and high-availability operations work under the destination identities.
- Agree on the cutover point and rollback conditions in line with the organization’s recovery objectives; there is no universal downtime or rollback duration for every environment.
Keep the source and target roles clear during cutover so writes do not unintentionally diverge between copies. Do not retire the source until the application owner has confirmed the target’s required access paths.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
