dbatools: SQL Server automation and instance migrations from PowerShell

The manual SQL Server work dbatools replaces

The problem dbatools addresses is scale. Clicking through SSMS for one server is fine. Doing it for fifty is not, and the README frames the contrast directly: query all 50 servers in one command versus clicking through them manually, and migrations measured in minutes rather than days. The module targets DBAs who already live in PowerShell and want the same command surface whether they are pointed at SQL Server 2000 or 2022. The README states that commands are consistent across those versions, which matters because T-SQL for routine tasks drifts between releases. Three use cases carry most of the weight in the documentation: backup verification, instance migration, and discovery across a fleet. Test-DbaLastBackup restores a backup somewhere and checks it, which is the only way to know a backup is usable. Start-DbaMigration moves an instance with backup and restore under the hood. Find-DbaDatabase locates a database by pattern across a comma-separated list of instances. Each of those replaces a manual procedure that is easy to get subtly wrong.

How dbatools talks to SQL Server

dbatools is a PowerShell module, not a service or an agent. It ships as a .psd1 manifest plus public and private function directories, and every command runs in your PowerShell session against a target instance. That means the connection model is whatever the underlying command needs, and the README is unusually explicit about the network side: SQL Database Engine on port 1433 is required for 62 percent of commands, WS-Management on 5985/5986 for 25 percent, SQL WMI on 135 for 4 percent, and SMB on 445 for 4 percent. The README suggests creating a dedicated Windows Firewall rule group for dbatools management traffic. The practical consequence is that a firewall between you and the instance decides which half of the module you can use. Commands that need SQL WMI or a -ComputerName parameter are the ones that fail first, and the README notes they typically do not work on Linux or macOS at all. The module does not abstract that away; it surfaces it as a connectivity error.

Installing dbatools and testing your first backup

The README lists three install paths: current user, all users, and offline. The current-user install is the recommended one and needs no administrator rights. Before running anything, check your PowerShell version, because the README requires v3 or later on Windows and PowerShell Core 7.4.0 or later on Linux and macOS.

$PSVersionTable.PSVersion
Install-Module dbatools -Scope CurrentUser

The first line prints the version table. The second pulls the module from the PowerShell Gallery into your user scope. If you are upgrading from a version older than v2.5.5, the README documents a certificate change to Microsoft Azure Trusted Signing and gives this command for the transition.

Install-Module dbatools -Force -SkipPublisherCheck

Once installed, the smallest useful check is against a local instance. The README's quick start runs these three commands in sequence.

Get-DbaDatabase -SqlInstance localhost
Get-DbaLastBackup -SqlInstance localhost | Format-Table
Test-DbaLastBackup -SqlInstance localhost

Get-DbaDatabase lists databases. Get-DbaLastBackup reports when each database was last backed up, and the pipe to Format-Table keeps the output readable. Test-DbaLastBackup goes further and actually restores the backup to verify it, which is the command that distinguishes dbatools from a reporting script. For a fleet-wide check, the README pipes Get-DbaLastBackup into a Where-Object filter on LastFullBackup against a date, which is how you find databases that have gone a week without a full backup.

Where dbatools stops: platform coverage and offline installs

The coverage tables are the honest part of this project and the first thing to read before adopting it. SQL Server 2012 and later gets 100 percent of commands. SQL Server 2000 gets 75 percent. Azure SQL Database gets 40 percent, and Azure SQL Managed Instance 60 percent. Containers and Kubernetes get 75 percent. On the operating system side, Windows gets 100 percent while Linux and macOS get 78 percent, with the README attributing the gap to SQL WMI and -ComputerName commands. If your estate is Azure SQL Database, dbatools is the wrong tool for most tasks and you should say so before a migration project starts. Offline installation is the other constraint worth naming. The README's sequence is Save-Module on a connected machine, copy the folder to either C:\Program Files\WindowsPowerShell\Modules or $HOME\Documents\WindowsPowerShell\Modules, then Import-Module dbatools. Nothing in that path verifies the copy, and the README does not document rollback if the imported module misbehaves. You are responsible for the version you place on disk.

dbatools compared with hand-written T-SQL and SSMS

The alternative most DBAs already have is a folder of T-SQL scripts plus SSMS. The difference is not capability, it is the unit of work. A hand-written backup-and-restore script targets one server and one version; you maintain a variant per SQL Server release and per environment. dbatools wraps the same operations as PowerShell commands that accept -SqlInstance, so iterating a fleet is a pipeline rather than a loop you wrote. The second difference is verification. Test-DbaLastBackup restores the backup to confirm it, and the README describes testing 1000+ backups per hour. A T-SQL script that only checks msdb for a backup record tells you a file exists, not that it restores. The trade-off runs the other way too. T-SQL scripts have no module dependency, no execution policy to set, and no certificate to trust. dbatools asks you to set an execution policy and trust the PowerShell Gallery, and the README's prerequisites do exactly that with Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser and Set-PSRepository -Name PSGallery -InstallationPolicy Trusted. If your environment forbids either, the script folder wins by default.

Licence, upgrade cost and what the manifest tells you

dbatools is MIT licensed. That permits commercial use and modification, and the repository carries a license file at the top level. This is not legal advice; check the terms against your own policy. On upgrades, the cost is concentrated in one event rather than spread across releases. The README documents a certificate change starting with v2.5.5, when the project moved to Microsoft Azure Trusted Signing, and gives a single command for the transition. After that, Install-Module dbatools -Scope CurrentUser picks up new versions. The recent release cadence is visible in the repository: v2.9.0 on 2026-09-16, v2.8.4 on 2026-07-31, v2.8.3 on 2026-07-11, and the last push to the development branch on 2026-09-23. The module manifest dbatools.psd1 sits at the repository root, so you can pin a version and read the declared dependencies before you upgrade. Note that the default branch is development, not main, which means the branch you see first is not the one releases are cut from.

Editorial conclusion

Adopt dbatools if you administer on-premises SQL Server or Azure SQL VMs at scale and want migrations, backup testing and discovery driven from PowerShell. Do not adopt it for Azure SQL Database work, where the README puts command coverage at 40 percent, or if you cannot open port 1433 to your instances. Before committing, verify your PowerShell version against the v3+ Windows and Core 7.4+ Linux/macOS requirements, and confirm whether you are upgrading across the v2.5.5 certificate change, which needs Install-Module dbatools -Force -SkipPublisherCheck.

Frequently asked questions

Official sources

1. dataplat/dbatools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases