Problem solve Get help with specific problems with your technologies, process and projects.

Moving workloads to new servers

The task of moving a workload to a new server often seems simple enough, but the process is plagued with gotchas. Here’s what to watch for before making the move to new hardware.

The task of moving a workload to a new server often seems simple enough, but the process is plagued with gotchas. Here’s what to watch for before making the move to new hardware.

The server’s identity. Typically when a workload is being moved, the new server will take on the identity of the old server. Although this identity transition will likely take place through backup restoration, it is a good idea to document server-specific information ahead of time.

This is particularly true for the server’s computer name and Internet Protocol address. Static IP addresses are often lost when a backup is restored to dissimilar hardware. Likewise, I have had situations in which the Active Directory computer account had to be reset before the new server could fully participate in a domain.

You could use a different name for the new hardware, but that tends to greatly complicate the migration. A new computer name can invalidate digital certificates and cause network drive mappings to fail.

Service pack levels and patches. You should also document the service packs and patches in use on your old hardware before a workload migration. If you attempt to migrate a workload to a new server that is running an alternate service-pack level, then you can expect any number of problems. In the case of Exchange Server, for example, the service-pack level affects your ability to mount the mailbox database.

Lab testing. The most critical aspect of migrating a workload is to test both the new hardware and the migration process in a lab environment. I typically create an isolated lab and then restore backups of domain controllers, infrastructure servers (DNS, DHCP, etc.) and anything else that will be necessary to thoroughly test the migration process.

With lab testing, I like to join the new production hardware to the lab domain. There are a couple of reasons for this. First, allowing the new hardware to participate in a lab environment makes for a good hardware burn-in. If a component is going to fail, it is better for it to fail before the new server is in a production environment.

The other reason I like to use the new hardware in a testing lab is that testing with production hardware sometimes reveals hardware-specific glitches. For instance, you might discover that you need to disable TCP/IP offloading on the new server’s network card.

Minimizing downtime. You should come up with a plan for minimizing downtime during the migration process. If the server that you are replacing is operating as a part of a cluster, this might be as simple as joining the new server to the cluster and then removing the old server. In a nonclustered environment, however, minimizing downtime can be a bit more challenging.

The exact method for minimizing server downtime depends on the type of workload. As a general rule, I like to restore a recent backup to the new server before I even begin the migration process. When it comes time for the migration, I disconnect the old server from the network and then perform one last backup. Since the new server has already been provisioned with a recent backup, restoring the most recent backup to the new server should be relatively fast because only the new data needs to be restored.

Support software. Finally, remember the support software that might be running on your server. This includes things like antivirus software and a backup agent. I have found that support software can be a bit finicky and that it may not always work properly after a migration. This is another reason why testing is so critical.

The exact method that you will use to migrate a workload to a new server will vary considerably based on the server’s workload and on your own infrastructure requirements. In any case, test the migration process before you perform it in a production environment. Throughout your testing, make sure that all necessary services start, that any databases that might reside on the server mount properly and that any data stored on the server is accessible.

ABOUT THE AUTHOR: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD 2D, Relevant Technologies and other technology companies.

This was last published in June 2012

Dig Deeper on Configuration Management and DevOps

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

TheServerSide.com

SearchCloudComputing

DevOpsAgenda

Close