SQL Server – Easy Database Migration

migrationsql server

We have an old SQL Server 2008 server that needs to be replaced, and as the sole developer (and by extension DBA), I have been asked to figure out the best way to move the 5 databases to a new server. As someone more familiar with T-SQL than SSIS, I'm not sure the way to go, but have come up with a plan that seems to allow quick and mostly painless (for the users at least) migration to the new server. My high level plan so far is:

  1. Setup the new server (applications, patches, etc). We may stay with 2008, but I'm going to recommend 2012 or 2014 to bring us up to date.
  2. Enable database mirroring or replication from the old server to the new one. Wait for the databases to copy over.
  3. With all users logged out, shut down old server and rename new server to old server's name.
  4. Shut down replication, go live.

Yes, I realize there are a lot of steps in here, and plenty of caveats (users, security roles, etc), but if I'm thinking about this right, then most of this will be taken care of automatically. My question is this (two part): Is this a valid plan to get everything moved over? If not, what would be better? I'm trying to minimize downtime for the users and overtime for us.

Best Answer

High level your approach will work but there is an additional step you will need to do along with a gotcha.

First off the gotcha - you will need to ensure that the instance names are identical on each server (although you can have a different server names). This isn't an issue though if you are just using default instances.

Once you cut over the databases you can then rename the new server to the old name. Once renamed you will need to rename the server name within SQL Server (again not to be confused with the instance name) using the steps outlined in this article.

https://msdn.microsoft.com/en-us/library/ms143799.aspx

I would either use log shipping or mirroring for the 5 databases and then manually copy across each instance level object (logins, jobs, linked servers, mail profiles, etc) and goes without saying that the applications should be tested before hand to make sure you are aware of all the instance level components and don't forget anything.

I have used approaches like this before to migrate clustered instances with numerous databases. This approach has more work up front getting everything set up and ready but it makes the cut over relatively quick and painless for the client applications.