How to move SQL Server from one computer/server/machine to another? Moving SQL Server from one computer to another is not a very difficult thing to do, but it often stumps newbie DBAs. Of course, it needs careful planning to ensure that the SQL Server is moved completely and properly to the new machine, and with a minimal downtime and no data loss. This article introduces you to a couple of methods you can employ to move/migrate SQL Server from one computer to another. Before we get into the nitty-gritty, lets look at some reasons why one would want to move SQL Server from one computer to another? Here are a few:  Number of users has increased and the current database server simply doesn't have the required processing capacity.  You found out that the current database server is having hardware problems and is not reliable anymore.  You are enhancing your database applications and adding more features, and require more processing power, but the current server cannot be scaled up anymore. Instead of scaling out, you decided to scale up, by moving to a powerful new server.  Your infrastructure team came up with a new corporate spec, and you must upgrade your SQL Server to the new hardware specification. Moving the entire SQL Server from one physical machine to another is different from just moving one or more databases. Moving an entire server means, moving more than just databases. You need to make sure the new server is configured with the same server level settings as the old server, and the new server must contain the same logins, role memberships etc. If you are interested in just moving databases, you could use backup/restore or detach/attach (using sp_detach_db and sp_attach_db) approach. You can find more information about moving databases, using the links provided at the end of this article. I also listed some useful books for DBAs. For now we will concentrate on moving SQL Server completely from one machine to another. Here are the steps involved in the process:  Purchase a new server, with the required hardware configuration.  Install the exact same version of Windows operating system on the new server.  Make sure the new server has the exact same drive letters with at least same or more disk space, as the old server. Configure your RAID subsystem as needed.  Take a note of the Windows service packs, Windows hotfixes and security patches that are currently installed on the old server, and apply them on the new server in the right order.  Take a note of any specific configuration changes that were made to the old server, and configure the new server accordingly. For example, if the old server is using AWE memory and has a /3GB switch or /PAE switch in the boot.ini file, then you need to add those switches on the new server's boot.ini as well. Another example would be, the pagefile. Page file can be spread across multiple drives, with specific amount of storage on each drive. You must mirror those settings on the new server as well.  Make sure the new server has the same number of (or more) network cards as the old server, and the network cards are configured optimally (for example, full duplex mode).  Once the new server is at the same (or better) level as the old server, from operating system's point of view, start with SQL Server installation. Install the same version of SQL Server (I tested these steps on SQL Server 7.0 and SQL Server 2000 only. Most of it is applicable to SQL Server 6.5 as well).  Make sure your new SQL Server is configured with the same authentication mode as the old server (Windows authentication (integrated security) or mixed mode).  Take a not of service packs, security patches, hotfixes that are installed on the old SQL Server, and install them on the new SQL Server as well.  Reboot the new server if necessary and make sure SQL Server, SQL Agent (and Microsoft Search) service are starting fine, without any errors. You can perform the above steps much faster, if you have a corporate standard for installing and configuring SQL Server. Also, documentation of server settings is very important. Okay, now we have our new SQL Server ready. The next step would be to move the data, jobs, DTS packages, logins etc. to the new server. Moving all these objects individually would be very time consuming, as well as error-prone. If you can afford some downtime on your old SQL Server, follow these steps:  Make sure no users are trying to connect to your SQL Server. Inform them well in advance about the downtime. Shutdown any applications or websites that might be accessing this SQL Server.  Stop the SQL Server, SQL Agent and MS Search services on the OLD SQL Server.  Stop the SQL Server, SQL Agent and MS Search services on the NEW SQL Server.  Copy the data files and transaction log files from your old SQL Server's hard drive (for example D:\MSSQL\Data) to the new SQL Server's hard drive (to the same location, in this example, D:\MSSQL\Data). Since we are copying all database files, including the system databases (like master, model, msdb, distribution), your server level settings, jobs, DTS packages, alerts, operators, logins etc. will be copied across.  Copy all the other folders (like backup, ftdata, jobs, log, repldata etc.) under the old server's MSSQL directory, to the same location on the new server.  Copy any other folders or files from the old server to the new server, that will be accessed by your jobs, DTS packages, stored procedures etc.  If you have any specific net library configurations, aliases, protocol binding orders on the old server, make sure you apply those changes to the new SQL Server, using the tools, Client Network utility and Server Network Utility.  Take a note of any shares on the old server, and recreate them on the new server, with the same permissions and access rights to the relevant Windows accounts.  Start the SQL Server, SQL Agent and MS Search services on the new server. Connect to the new server, using Enterprise Manager and make sure all the databases are displayed and that there are no suspect databases. Scan through the SQL Server error logs, SQL Agent error logs, System and Application event logs, to make sure there are no errors. If you find any errors, fix them before you proceed any further.  Once you are happy with the new server's state, shutdown the SQL Server, SQL Agent and MS Search services. Now its time to rename the new server as the old server, and remove the old server from the network. Consider that your old server is being called 'ServerA' and the new server we are building is currently named 'ServerB'. Follow these steps to swap the names of these servers:  Rename 'ServerA' to 'ServerA_OLD'. You can do this by right clicking on 'My Computer', select 'Properties', go to 'Network Identification' tab. Also, remove this server from the domain, and place it in it's own workgroup. Reboot the server 'ServerA'. As we renamed it, it will now come up as 'ServerA_OLD'.  On ServerA_OLD SQL Server, either disable all the jobs or disable the SQL Agent service. This is important, because, if the SQL Agent starts on this machine, it might kick off some jobs, that will interfere with other servers, or duplicate the work, that is already being done by our new server ServerA. If this situation is not taken care of, it will result in chaos and unpredictable results.  Rename the new server 'ServerB', to 'ServerA' and make sure it is in the production domain. Reboot 'ServerB'. As we renamed it, it will now come up as 'ServerA' (the name of the original server).  Connect to 'ServerA' using Query Analyzer and execute the command SELECT @@SERVERNAME. This will return the correct server name (if it didn't, then drop that server by running sp_dropserver and re-add the correct server name (ServerA), by running sp_addserver (Be sure to specify the 'local' parameter). For more information on how to drop and add the server names, read the article mentioned in the links section, at the end of this article.) Now your new SQL Server is ready for use. Before you let the users start working with this server, perform testing and make sure the server is fully functional and all aspects of your production application are working fine. Once you are happy, you can let your users start accessing this new server. Since the name of the new server is now same as the old one, your applications will connect to the new server, without any problems. You don't have to reconfigure or change any DSN and connection string properties. As you can see, it is not a very difficult task to move an SQL Server from one machine to another, but it requires careful planning. The only time consuming step in this process is the file copy. Copying databases that are several giga bytes (GB) or terra bytes (TB) in size from one machine to another over the network will be very time consuming, It can take a few hours or even a couple of days. The speed of file copy depends on the speed of your hard drives and your network bandwidth. Consider zipping the bigger files (using an application like WinZip or WinRAR) before copying. That could speed up the file copy over the network. Though this method works well for mirroring SQL Server installation onto a new machine, it will require server downtime. If you are running a mission critical, 24/7 database and cannot afford any downtime at all, then you could follow the alternative approach described below:  Follow the same steps as explained above, for building a new SQL Server from scratch.  Copying database files requires you to shutdown the SQL Server. Since we don't want any downtime at all, forget about copying physical database files. Simply create backups of your static (read-only) databases and restore them onto the new server, using BACKUP and RESTORE commands.  You cannot apply the above step for your ever changing OLTP database, because, by the time you restore the backup onto the new server, the old server would have received more changes. To avoid this problem, you need to resort to log shipping. Log shipping is nothing but an automated process of backup and restore. The following steps will explain the process of log shipping (Note that SQL Server 2000 Enterprise Edition provides inbuilt logshipping. We don't need that for this purpose. We can simply create a job, that backs up and restores the databases).  Take a full database backup of your OLTP database from the old server, and restore it onto the new server. Make sure you restore using WITH STANDBY or WITH NORECOVERY option, as this allows us to restore further transaction log backups onto this database.  Create a job on the old server, with two steps. The first steps backs up the transaction log of the OLTP database. The second step restores this transaction log backup file onto the new server, using WITH STANDBY or WITH NORECOVERY option of the RESTORE command. Schedule this job to run every 10 minutes or 15 minutes, depending on the volume of transactions your OLTP database receives.  This job will take care of shipping all new transactions since the full database backup, to the database on the new server. Let this job run until you can afford some downtime on your production database (that is, mid-night, or early morning, or a planned maintenance window).  Once you are ready to swap the servers, ask your users to logoff (if there are any) and shutdown any applications or websites that are currently accessing this database on the old server. To be doubly sure, no new transactions are coming in, set the database in 'single user' or 'dbo use only' mode. Take one last transaction log backup of the production OLTP database, and restore it onto the database on new server. This time use the WITH RECOVERY option of the RESTORE command.  Now the OLTP database on the new server is completely in synch with the one on the old server. Its time to rename the servers now. Just follow the steps explained above (in the other approach), for renaming the servers. As is evident, this method requires only a few minutes (5 to 10 minutes at the max) of downtime. The only time consuming processes in this approach are the "Amount of time it takes to create the last transaction log backup and apply it on the new server, the server renaming process (also depends on how quick you are on the keyboard:-), and the server reboot process". Additional note about servers involved in replication topology: If the server you are moving is a distributor, then all replication agents (log reader, snapshot, distribution and merge) will be suspended, when you shutdown the server during the above process. The only side effect of this, would be the growing transaction log of the published database (as the transaction log cannot be truncated, until the replicated transactions are picked up by the log reader). If you have pull subscriptions, the pull distribution or merge agents will fail to connect to the distributor and you will see errors on your subscribers. These agents will most probably succeed (unless expired) when you restart them at the end of this process. If the server you are moving happens to be a publisher, just make sure you stop the replication agents related to this publisher, on the distributor and everything should be okay, once the new publisher comes back up. If the server you are moving happens to be a pull or push subscriber, make sure you stop the corresponding distribution agent, till the server swapping process completes.