S 2.319 Migration of servers

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

If the services of the server are to be taken over by another system, this transition must be planned. Especially if there are special requirements regarding the availability of the services, very careful planning is needed.

In most cases, it is recommended to perform the "function transition" to the secondary system outside the normal operating hours. If this is not possible, safeguards must be implemented to ensure that no data are lost during the function transition and that no unacceptable downtimes occur.

For the migration of important servers, an appropriate migration concept must therefore be drawn up in advance. The following points should be give special attention when doing so:

• Migrating the data and the configuration
  
  After the transfer of data to the new system, it must be checked whether the data have been transferred completely and correctly.
  
  If a new version of the server software is to be used on the new system, it must be ensured that the new version can handle the existing databases properly. This applies not only to the task of correctly reading in the data of the old version but also to modifying these data or adding new datasets. Problems often occur in precisely these cases; therefore, thorough tests are recommended.
  
  Moreover, it is important that the configuration of the old service is properly taken over by the new system or can at least be "replicated in a functionally equivalent manner".
• Compatibility of the service
  
  It must be ensured that the service on the secondary system is compatible with the original service. This is particularly important if within the frame of migration to the new system a new version of the server program is to be used to which clients with the old version still have to access. Even if a manufacturer presents reports from reference customers on successful migration or guarantees "downward compatibility without problems", "complete backward compatibility with earlier versions" or similar things, it is urgently recommended to conduct the corresponding tests beforehand.

• Cryptographic keys
  
  If parts of the data or the file systems of a server are encrypted, the security or transfer of the corresponding keys gains special importance: They are frequently stored in a different part of the system from the data used in daily operation. For example, if the data are directly copied block-wise with the help of system-related programs, or the hard disks must be taken from the old system and installed in the new one, it must be ensured that the keys are also transferred; otherwise, access to the encrypted data is no longer possible.

• Changing names and addresses
  
  If a server is only accessed via its IP address or a DNS name, migration is usually relatively unproblematic, because in this case the secondary system can simply take on the IP address of the old system. It is more problematic, for example, if the new system is to receive the same DNS name but cannot take on the IP address, because it takes a while before the change of address "reaches" all clients. Such latency times must be taken into consideration when planning the migration.
  
  If the system is accessed in different ways (e.g. if the address is resolved by another directory service), it must be taken into consideration that the change made in this manner might also lead to a certain latency time before taking effect.
  
  The biggest problem arises if clients access the servers via an application in which the IP address or the name of the server is stored in a local configuration file or configuration database. If a larger number of clients need to be manually reconfigured, this can consume a considerable amount of time and must be planned in advance.
• Permanent connections
  
  If there are clients that establish longer term or even permanent connections to the service that has to be migrated to a new computer (as is the case with some database applications, for instance) this must be taken into consideration during migration. If required, these connections must be manually terminated on the respective clients. This also requires adequate planning.

When conducting the migration, it is advisable to draw up a checklist while elaborating the migration concept, which can then be used to perform the transition step by step. When planning migration and drawing up the checklist, care must be taken that each step is only dependent on the previous ones.

In case of high demands on the availability of the service, the entire transition should be tested beforehand in a testing environment under conditions that are as realistic as possible in order to identify and eliminate potential problems as early as possible.

Review questions:

• Is there a migration concept that, among other things, takes the availability of functions, services, and data into account?