How can we reduce the downtime of server migration?

It seems easy to migrate the load to a new server, but there are still many minor problems in this process. Next, let's list what you need to prepare before you execute this task.

Server Authentication. When the load is migrated, the new server replaces the old server identity. Although this identity conversion may be completed through backup and re-creation, it is best to record the information about the server's own characteristics before.

This is a deep understanding of the computer name and Network Protocol address of the server. Static IP addresses are often suddenly lost when the backup is rebuilt on a different hardware. Similarly, I have met that the Active Directory (Active Directory) computer account must be reset before the new server can be fully added to the function.

You can give new hardware different names, but the migration process will become very complicated. The new computer name makes the digital certificate invalid, resulting in the failure of the mapped network drive.

Service Package level and patch. You also need to record the service packages and patches of the old server before migration. If the new server you are trying to migrate is running an alternative service package level, you may encounter many problems. Take Exchange Server as an example. The service package level affects your ability to load the mailbox database.

Lab testing. This is the most critical part, testing new hardware and migration processes in a lab environment. I usually create a separate lab, and then rebuild backups on the Regional Controller, infrastructure server (DNS, DHCP, etc.), and any other backup that must be thoroughly tested for the migration process.

Through the above tests, I can add new product hardware to the experiment area. There are many reasons for this. First, the new hardware can be well integrated into the experimental environment. If a component is always invalid, it is better than that of the new server after it enters the working environment.

The second reason is that this will help you find some minor hardware faults. For example, you may find that the TCP/IP unmount fails on the NIC of the new server.

Minimize downtime. You should develop a plan to reduce the downtime of the migration process. If a server you are replacing is part of a working cluster, it may be relatively simple to add the new server to the cluster and then overflow will be required. However, in a non-cluster environment, reducing downtime is more challenging.

Reducing downtime depends on the load type. I like to rebuild the latest load to a new server before starting the migration. This is a general rule. At the time of migration, I first cut off the network connection of the old server and then made the most final backup. When the new server is ready and a recent backup is available, I will recreate the latest backup. This will be faster, because only the latest content needs to be updated.

Support software. Finally, remember the support software that may run on your server. This includes anti-virus software and backup agent. I found that the support software may be overly detailed, so that it will not work properly after migration. This also indicates that testing is very important.

But what is the migration load on the new server? This answer should be analyzed based on server load and your own infrastructure requirements. However, it is necessary to test the migration process before it is put into the work environment. During the test, make sure that all necessary services are started and any database on the server is normal and any data can be accessed.