What’s the big deal with moving a DB to another server? Detach it, move it, and then reattach it, right? Easy peasy! But what if it’s a whopping 20tb? Can your company handle the DB going offline for that long? Fear not, here’s the scoop on how to make that happen with just a few minutes of downtime.

Most of our businesses are now 24/7. Time is money and we can’t have our databases offline for very long or it’s costing us loss revenue and faith in reliability from our customers. What if I told you there was a way to move any database with only a few minutes of downtime, REGARDLESS of the size of the database? It’s like a magical sleight of hand for databases! Well, have you ever heard of a feature in SQL called Log Shipping?

Yes, Log Shipping. The SQL Server feature that lets you have a backup buddy for your database in case of a disaster can also assist you in relocating said database. It’s been around since SQL2005, so it’s like the vintage tracksuit of disaster recovery solutions. Sure, there are newer options out there, but this old-timer can still bust a move when faced with interesting problems.

To move your database, simply turn on log shipping to pre-stage your database. Let the logs restore on the destination server while your clients continue to use the original database.

After some time your mirrored database will be caught up to real time. That’s when you schedule a quick outage (I always schedule 30mins to be safe, but you can determine how long it’ll take based on the most recent log restores). You then kick everyone out of your application, take one final backup, restore that final backup with recovery, and then point your application to the new location.

Your database may be huge and take hours to do the initial restores, but the cutover should be pretty quick. With this knowledge you can keep your users in the database as long as possible and have a very limited down time even if you have standard edition.