Server Migrations at

nine Team Sep 12, 2016
Server Migrations at

In this post we would like to take the opportunity to look at the topic of “Server Migrations at” and explain why they are necessary, how they are implemented at and what kinds of things our customers should be aware of.

#Why is a server migration necessary?

Like many things in life, even a server with proper hardware and the software that runs on it does not last forever. Operating systems as well as services such as PHP or MySQL reach a point at which maintaining them is no longer worthwhile. Changing technology, which is very much a positive thing, is responsible for this. For developers and administrators of applications and servers, however, this can be problematic.

Software that has been on the market for a long time becomes ever more vulnerable and the costs of maintaining it continually increase. As technologies change and software gets older, partly outdated expertise for software must also be available and it must be possible to apply this knowledge. This can sometimes cause problems. It is challenging and very costly for manufacturers of operating systems to close gaps in previous versions in order to continue ensuring a high-level of security - especially if these gaps have been closed in the newer versions. The effort required by developers to maintain the software also greatly increases as they have, for example, have become accustomed to more modern changes in the programming languages.

In order to counteract this, many manufacturers have defined so-called “life cycles”. They determine how long the software will be maintained and supported. This helps developers and administrators more accurately plan the necessary migrations to new technologies. This is therefore also one of the reasons why we rely on Ubuntu, which provides exactly 5 years of LTS (“long term support”).

The principle with technology remains the same: improvements come only through enhancements and innovations. This also means giving up and getting rid of outdated concepts and gaps. The migrations that we’ve performed so far have allowed us to gather considerable experience. That is why we would like to support our customers as actively as possible in this process.

#How does a typical migration proceed at

Migrations are initiated for two reasons:

##Migration due to customer request As a customer of, you would like to migrate to a newer version available in the repositories that is offered by (e.g. from PHP 5.4 to PHP 5.6, or from Ubuntu 14.04 to Ubuntu 16.04). For such a project, we provide you with a second server with the desired configuration. You then migrate your data and test your applications until everything works properly and as intended. Subsequently, settings such as DNS entries (with a reverse proxy for forwarding to the new server if needed) are changed and the old server is shut down after confirmation by you.

##Migration due to expiring support informs customers about the EOL (end of life) of their products. Customers receive an e-mail with details about the migration and the link to the migration portal (login using your cockpit login data). Customers can use the migration portal to conveniently and easily communicate with regarding the affected server, check out the various options, provide feedback and view the status of the migration. We provide our customers with a second server in this case as well, which runs parallel to the production server. Unlike requested migrations, your data is copied to the new server by us in order to minimise the effort required by you as much possible.

Within the migration tool itself, you can click on “Select migration option” to select the desired versions and set a desired date for the migration. This information is sent to whereupon a second server will be provided according to your specifications. We will install the new system, configure it (based on the old system where possible), copy your data and verify that everything has been done properly using our quality assurance process. You then receive the new login information in a separate e-mail and the status of the server is set to “Migration check” in the migration tool.

You, as the customer, now have the opportunity to ensure that everything is working and if any modifications need to be made to applications, e.g. changes to PHP versions and resulting incompatibilities. The old system remains live during your trial period so that you have plenty of time to configure the new system to suit your needs. If problems occur on the server side, you can set the status in the migration tool to “rework” with a click and add an explanation of the problems. A member of staff will then take care of it as quickly as possible.

Once the new server has been set up as desired, we will coordinate with you for implementing the final synchronisation. To prevent any further changes to data, a maintenance page is activated on the old system. Subsequently, all changed data is synchronised again (depending on the agreed implementation, either a reverse proxy is connected which ensures requests are forwarded from the old server to the new one or the IP is swapped). The new system is now live.

Reverse Proxy
Reverse Proxy
IP Change
IP Change

We switch off the old system after receiving positive feedback from you that everything is working. We allow the old system to be reactivated for about 10 days after the switchover in case of emergency. The migration is now complete.

#What you should consider or do as a customer?

The following points are important for implementing the migration:

  • Notification of which migration option you prefer (the various options are specified by

  • Specify the desired date for delivery of the new server for testing purposes

  • Specify the desired date for final synchronisation

  • Adaptation and testing of applications; notify of any configuration changes that must be made

You should take the following into account:

  • In principle, only the functionality should be checked on the new server. When creating new databases or content, for example, some data may be overwritten during the final synchronisation. This can however be avoided. If new content is absolutely required, it is better to create it on the old server - the synchronisation ensures that the content will be transferred to the new system. On request, can also perform a second synchronisation before the final sync.

  • Do not take wait too long before performing a migration. As soon as a support for a product is no longer available, the potential risk increases. For example, a server can be compromised and it will no longer be possible for us to set up a 1:1 copy of the server as it will become outdated. At which point we would have to migrate to a current system, which may in turn result in undesirably long downtimes.

We hope that this post has helped you better understand the topic of “Migrations at”. Feel free to contact the team with any questions or comments you may have by e-mail or phone.