Feedback on dbatools Start-DbaMigration

It’s time to follow up on a post from a few months ago where I said I’d give my thoughts on Start-DbaMigration from dbatools after picking up more experience. Along with Start-DbaMigration I picked up some experience with Copy-DbaDatabase to migrate databases from one server to another. Below are some thoughts on the good and bad.

What’s what

If you’re reading this post first and are not familiar with Start-DbaMigration, it is part of dbatools. dbatools offers a set of PowerShell commands that can be used to automate SQL Server tasks. Start-DbaMigration offers an easier way to migrate a SQL Server environment from one server to another. It can be used to migrate databases and other areas like logins, jobs, and more.

Gets the Job Done

I’ve had success using Start-DbaMigration, and it’s been a time saver. For migrating logins, jobs, etc., Start-DbaMigration runs quickly, and that part works as designed.

But it hasn’t been perfect for some of my specific needs, and admittedly, I expect I’m more of an outlier. The biggest drawback I’ve run into is trying to do larger amounts of databases at a time.

If I were only ever migrating a handful of databases, then Start-DbaMigration would be perfect. Instead, I’ve been testing with dozens, or even hundreds, of databases. Trying to do one big session with Start-DbaMigration to migrate that many databases and the rest of the server settings was not going to cut it if the process was going to be running for hours.

Experimenting

If we look at the Start-DbaMigration.ps1 script, we’ll notice that it’s running many “Copy-Dba…” scripts. I toyed around with creating multiple PowerShell sessions to run one of these scripts, Copy-DbaDatabase, so that I was restoring more than one database at a time (one PowerShell session for 10 databases, another session for 10 more databases, etc.). While that worked to speed up the process, it doesn’t feel like the best way to go. Plus, managing multiple PowerShell windows can be a burden. I could also use Start-DbaMigration instead of Copy-DbaDatabase to copy the databases and exclude everything else with the -Exclude switch, but it made sense to just roll with the Copy-DbaDatabase instead as I was testing.

For larger counts of databases, log shipping would probably be an ideal solution as an alternative to getting the databases themselves migrated and bringing them online right away at the beginning of a scheduled outage. You could kind of mimic this with Copy-DbaDatabase. With Copy-DbaDatabase there’s the option to restore databases to the new server, leave them in a NoRecovery state, and then use the same script plus the -Continue switch to keep restoring the latest transaction log backups.

Overall, I highly recommend using Start-DbaMigration.

Thanks for reading!