Moving SQL Server 2008 R2 to new Server Hardware

  • Hi All,

    I'm tasked with moving an existing SQL Server 2008 R2 environment to a new server. The current server is attached to a SAN. The SAN is staying the same...it's going to be detached and attached to the new Server. All system databases are on the M drive (the san). So...all that will be changing is the server. I've come up with the following plan...just wanted to check with you all if this is correct:

    1. Create new server and ensure SQL and Patch are same level as existing server.

    2. Detach SAN and reattach to new server

    3. Ensure new server can see SAN drives

    4. Switch off old server. Change server name on new server to the name of the old server

    5. Change startup parameters for MASTER db and point to M drive

    6. Alter MSDB database and also point to M drive

    7. Configure TEMPDB (split into multiple files)

    This seems straight forward...but I'm not too sure

    Thanks

    Denesh

  • I would say there are a lot of things you need to take into conideration still:

    - If you are renaming a server that hosts SQL Server you will need to go through certain steps to ensure the SQL Server instance reflects this change:

    How to: Rename a Computer that Hosts a Stand-Alone Instance of SQL Server

    Additionally you should probably research the following on the current instance to ensure they get migrated over:

    - logins (which do not get migrated over like users do)

    - SQL Agent jobs

    - Linked servers

    - Stored credentials

    - Maintenance Plans

    - SSIS packages

    - Certificates

    Joie Andrew
    "Since 1982"

  • If you really want to do it like you detailed then ensuring the same patch level is essential, however you will definitely have issues with encryption using the SMK which will be orphaned and will need re generating. IMHO it's best to build a new instance and move the user databases and other objects.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Hi guys,

    Thanks for the replies.

    This environments has no certificates.

    Regarding the maintenance plans, logins etc...by moving the current Master and Msbd...this should be covered.

    There also no Smk being used.

    Thanks again guys for the reply

  • Are the paths that SQL Server is installed in the same between the old and new instance? If not I would imagine you are going to have problems with where master is pointing for certain resources.

    Joie Andrew
    "Since 1982"

  • Test your intended process using a sandbox server before doing it with real data. This will help you find anything you have missed.

    My personal preferance is to build a new server and move over the logins, etc followed by the user databases. If anything goes wrong then doing it this way means there is a standard build and standard troubleshooting can be used.

    Doing it your way means ther will be far less help available if you need to troubleshoot. You should factor in the relative risks before deciding what approach you will use.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • Hi all

    Yes the install paths will be the same.

    This plan will be tested first on a qa server.

    The reason for this plan is to ensure migration is as seamless as possible. Therefore I want to use the existing Master db on the new server so as to not miss anything.

    Also downtime for this environment is very limited.

  • You may or may not also want to alter this to in "change IP address of old server to newly assigned IP, change IP address of new server to be that of what the old server had been running as" prior to powered off the old server. This avoids the host file edits proposed above, and also accounts for hardcoded IP address connections (not uncommon if your environment has had DNS issues before).

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply