Migrations that work even when the two servers can't see each other.

Direct when it can be, two-phase when it must be.

A connectivity check against the other server decides which path to use — or you override it explicitly via Auto / Direct / TwoPhase.

Direct	TwoPhase (Umweg)
Source and target reachable at the same time	Source and target separated — different domains, no shared network
One pass, run from the source server	Phase 1 on source, phase 2 on target, connected only by a state file
Objects copied directly via Copy-Dba*	Objects exported to script, then imported via Invoke-DbaQuery
Backup taken locally, then robocopied straight into the target's admin share	Backup and scripts land on a shared exchange path (UNC) both sides can reach

In TwoPhase mode, logins export via Export-DbaLogin as a CREATE LOGIN script — including SID and password hash — because Copy-DbaLogin needs both servers visible at once. Agent jobs, linked servers, credentials, and proxies export the same way via Export-Dba*/Export-DbaScript, importing in this order: credentials → proxies → linked servers → agent jobs.

Backup/Restore, or Detach/Attach.

What migrates, in both modes: databases, logins, DB users, linked servers, agent jobs, credentials, and proxies. Credential and linked-server secrets aren't always decryptable — the tool writes a TODO list of exactly which ones need to be re-entered by hand on the target.

Before you start.

• PowerShell 5.1+ on both source and target.
• dbatools ≥ 2.0 installed on both.
• Run as Administrator (file access, services, detach/attach).
• sysadmin on both SQL instances for the account running it.
• A shared exchange path (UNC) reachable from both servers, with room for the backups.
• A local backup path as fallback, if the SQL service account has no UNC access.
• SQL port 1433 open for Direct mode; SMB 445 open for the exchange path.
• On SQL 2022 / self-signed certificates: leave TrustServerCertificate enabled.

Phase 1 — source.

1. Start and choose SourceRun Start-SQLMigration.cmd as Administrator, select the Source role.
2. ConnectServer/instance is pre-filled with the current machine — check it, choose auth, connect.
3. Select objectsCheck what to migrate in each tab (databases, logins, ...) — Select All/None per tab, or across all tabs.
4. Choose method and pathsBackup/Restore or Detach/Attach; verify the exchange path and local backup path.
5. Optional dry runEnable WhatIf to simulate the whole run with no real changes.
6. Start Phase 1Confirm the summary. A state file is written to the exchange path when it's done.

Standard strategy: the backup is written first to the server's own local default backup directory (where the SQL service account always has write access), then robocopied to the exchange path — the copy itself runs in the admin context, so the service account never needs UNC access. The local copy stays on the source as a byproduct.

Phase 2 — target.

1. Start and choose Target(or Automatic — it detects the state file and picks Target on its own.)
2. State file is readMethod and object selection are pre-filled and locked from Phase 1.
3. ConnectTarget server, pre-filled with the current machine.
4. Verify pathsExchange path and local path.
5. Start Phase 2Robocopy from the exchange path to the local directory, then restore or attach.
6. Automatic post-processingRuns right after restore/attach, respects WhatIf — see below.

What happens on the target without being asked.

Login migration	If Mixed Mode isn't already on and SQL logins are among the imported ones, Mixed Mode is enabled and the SQL service restarted before import — existing connections to the target drop briefly. New_Password_Policy is disabled for the import and re-enabled after.
Orphaned DB users	Repaired via Repair-DbaDbOrphanUser.
Database owner	Set to sa, resolved by SID 0x01 — works even if sa has been renamed.
Orphaned AD logins	Removed, but only when the Logins object type is checked, only Windows logins with a domain SID, never system or sysadmin logins, and only when AD positively fails to resolve the SID (a domain-controller hiccup skips the cleanup rather than risk deleting something valid).

What to check before calling it done.

• All expected databases present, status ONLINE.
• DBCC CHECKDB clean.
• Recovery model and compatibility level correct.
• Database owner is sa (set automatically) — spot-check.
• Orphaned users repaired (automatic) — spot-check.
• Orphaned AD logins removed, if Logins was checked — check the log.
• Logins present with correct SIDs — check the log for any foreign-domain Windows logins that couldn't be created.
• Mixed Mode on if SQL logins were migrated (switched automatically if needed).
• New_Password_Policy active again (re-enabled automatically after import) — spot-check.
• Agent jobs, linked servers, credentials, and proxies present and working — fill in any secrets from the TODO list.
• Application connection strings pointed at the new server.
• Application smoke-tested.
• Source databases only taken offline after acceptance is signed off.

What "undo" means, depending on where you are.

Before restore/attach	Nothing has changed yet on the target — just stop.
Backup/Restore method	The source was never touched and stays online — rollback is simply leaving the application on the source.
Detach/Attach method	The source was detached — reattach it (via the Re-Attach option, or manually) to put it back.
Worst case	Restore the independent full backup taken before the migration started.

What each symptom actually means.

Symptom	Cause / fix
"dbatools is not installed"	Run Install-Module dbatools.
Connection or certificate error	Enable TrustServerCertificate; check server/instance, port, firewall.
"Exchange path not reachable"	Check the UNC path and permissions; fall back to the local backup path if needed.
Backup gets created locally	That's by design — local backup, then robocopy to the share in the admin context. The local copy stays in the server's backup directory.
Robocopy error (exit code ≥ 8)	Check the target/source path and the running admin's permissions; check disk space.
Phase 2 finds no state file	Phase 1 didn't complete successfully, or the exchange path doesn't match.
Orphaned users after restore	Repaired automatically in Phase 2; re-run Repair-DbaDbOrphanUser if needed.
An AD login was wrongly kept or removed	Cleanup only deletes when the domain SID positively fails to resolve; a DC hiccup skips it (log: "AD check skipped").
Logins missing after TwoPhase	Check migration_logins.sql on the exchange path; individual batches can fail (log category "LOGIN-IMPORT"). Windows logins from foreign domains can't be created this way.
Jobs / linked servers / credentials / proxies missing after TwoPhase	Check the export/import scripts on the exchange path (migration_jobs.sql, migration_linkedservers.sql, migration_credentials.sql, migration_proxies.sql); log categories *-EXPORT (phase 1) and CRED-/PROXY-/LS-/JOB-IMPORT (phase 2). Fill in secrets from the TODO list for credentials/linked servers.

Nothing is deleted for you.

Log: C:\SQLMigration\Logs\SQL-Migration_*.log, or the [Log] button in the GUI. CSV trail via the [CSV] button. Local backup files are not deleted automatically — clean them up by hand after acceptance. Remove _migration_state.json from the exchange path once you're done, before starting a new migration — otherwise the next run will wrongly detect Target mode.

After acceptance — sqmSQLTool tasks.

Once the migration is signed off, these sqmSQLTool commands cover the checks worth running on the new home for these databases.