Move websites, databases and mailboxes to cloud hosting

In vielen Kundenverträgen haben sich im Laufe der Zeit eine Vielzahl von Projekten angesammelt: Entwicklungs- und Testversionen, Archive älterer Versionen der Webseiten usw.

Im ersten Schritt ist es sinnvoll, sich zu überlegen, welche Anwendungen tatsächlich noch benötigt werden.

Zu jedem Projekt gehören in der Regeln mehrere Komponenten:

• Eine Domain oder Subdomain, über die das Projekt im Browser aufgerufen werden kann.
• Ein Zielverzeichnis, in dem die Dateien des Projekts liegen, auch DOCROOT oder Startverzeichnis genannt. Das ist das Verzeichnis (mit Unterverzeichnissen), aus dem die Dateien beim Aufruf der Domain geladen werden.
  In den Unterverzeichnissen liegen auch der Programmcode (PHP Skripte), Bilder, PDF Dateien, ...
• Eine Datenbank, in der die Inhalte (Texte und weitere Datensätze) der Webseite gespeichert werden.
• Cronjobs, das sind Programme, die in regelmäßigen Zeitabständen aufgerufen werden um bestimmte Aufgaben zu übernehmen. Dazu gehören Backups, Datenimporte und -exporte, Versand von Newslettern, usw.
• Hilfsprogramme, die für bestimmte Aufgaben in der Anwendung benötigt werden. Dazu gehören Bildbearbeitung und -umwandlung, Extraktion von Informationen aus Bild- und PDF-Dateien für Suchfunktionen, usw.
• Weitere Programme wie Matomo (für Webseiten Statistik) die für ein Projekt benötigt werden.
• E-Mail Postfächer mit darin gespeicherten E-Mails.

All diese Komponenten müssen beim Umzug auf den neuen Server übertragen werden.

Nach der Übertragung müssen dann in der Regel noch Anpassungen, wie z.B. absolute Pfadangaben in Skripten, vorgenommen werden.

Je nach Umfang der Webseite dauert ein solcher Umzug einige Stunden.

Vor Abschluss des Umzugs wird das Projekt auf dem neuen Server mit Hilfe einer temporären Domain getestet. Damit wird sichergestellt, dass alles wie gewünscht funktioniert. Das ist auch ein guter Zeitpunkt, die Geschwindigkeit zwischen Quell- und Zielserver zu vergleichen, da die Webseite auf dem alten sowie auf dem neuen Server aufrufbar ist.

Sind alle Tests abgeschlossen, wird die Domain auf den neuen Server übertragen. Bei sogenannten Domains mit externer Registrierung, die nicht über uns sondern über einen anderen Provider registriert sind, ist eine Umstellung der A-Records beim Domainprovider erforderlich, damit die Domain auf den neuen Server zeigt.

As explained in detail in the introduction above, you must first order a cloud hosting package as a new customer.

Once we have received the completed and complete AV contract, we will set up the package. Once we have completed the work, you will receive an email with your access data and passwords.

Most websites use databases to store content. Once it has been determined which projects are to be moved to cloud hosting, the associated databases must be identified.

Determine databases

If a domain points to a target directory in the previous customer menu (and is not a redirect to another domain), make a note of the target directory (e.g. /typo3cms/projekt1 or /wordpress). In this target directory, you must find out in which file the access data for the database is stored.

In TYPO3, depending on the version, this data is stored in the files [target directory]/typo3conf/LocalConfiguration.php or [target directory]/typo3conf/localconf.php

For Redaxo, the access data can be found in the file [target directory]/redaxo/include/master.inc.php

For WordPress, the access data can be found in the file [target directory]/wpconfig.php

Backing up databases

To save the contents of the database in a file, log in to the previous hosting package via SSH access and change to the folder

/typo3cms/system/backup/databases

Here you create the image of the database with the following command (enter in one line):

mysqldump --opt --no-tablespaces -h mysql -u db123456_789 -p db123456_789 > mybackup.sql

You must then enter the password for the database and confirm with [Enter].

In the previous hosting packages, the names for the database user and database name are identical; in the cloud hosting packages, these may be different.

The file name (in the example meinbackup.sql) under which the database is saved can be chosen as desired.

If several databases are in use, each database must be saved in a separate file.

The rsync command is used to transfer all files, including the database backups, from the previous hosting package to the new cloud hosting package.

Logged in to the server of the previous hosting package, you switch to the new hosting package with the command

cd [Enter]

to the start directory (this corresponds to the directory in which you land after the SSH login).

To carry out the transfer, enter the command customized with your own data:

rsync --delete -ave ssh . username@host:httpdocs/__transfer

The point after ssh with a space before and after it is important.

• username: SSH user of the cloud hosting package
• host: Server name (e.g. 900xxx.jweiland-hosting.de) of the cloud hosting package

Depending on the amount of data, the transfer may take a few minutes.

When the transfer is complete, all files on the cloud hosting package are now in the directory: httpdocs/__transfer

You must create a new database for each original database in the cloud hosting package.

In the Databases menu item, click on "+ Add database" and enter a user name and a database name for the new database. The databases MySQL 5.6 and MariaDB 10.3 (corresponds to MySQL 5.7) are available.

As only MySQL 5.6 was available with the previous hosting, you also select MySQL 5.6 for cloud hosting when transferring websites.

Have the password generated and displayed. Make a note of it in a safe place (the password can no longer be viewed later, but can be reset if necessary).

After creating the databases, you must import the database backups from the file into the new database.

To do this, you must log in to the shell via SSH and change to the directory: httdocs/__transfer/typo3cms/system/backup/databases

The database files of the backups created on the previous hosting are located here. These are now read into the newly created database.

Enter the command customized with your own data:

mysql -h db.mysql56 -u username -p database name < mybackup.sql

• username: new user name
• datenbankname: new database name
• mybackup.sql: name of the backup file

You must then enter the database password and confirm with [Enter].

If you have several projects, repeat this process for each database.

Then enter the new database access data in the website configuration file. Where to find these has already been described in Step 2: Backing up databases in files.

All files of the project are now still in the directory: httpdocs/__transfer

It makes sense to move these project files to the final destination. For example, if the project is in the directory httpdocs/__transfer/typo3cms/projekt1, the project should be moved to a subdirectory of httpdocs/typo3cms. However, there is already a project1 directory there. This was created by us when setting up the hosting package and it contains an empty TYPO3 installation.

You can either delete the directory httpdocs/typo3cms/projekt1 first (if it is not needed for a new website) or you can move the transferred project to a new directory, e.g. httpdocs/typo3cms/projekt2 or httpdocs/typo3cms/name-of-the-domain.com

The name of the target directory can be chosen at will, as it is not visible to the outside world. In our example, you move the project to httpdocs/typo3cms/projekt2

First change to the start directory, then to the httpdocs directory and execute the move command there:

cd [Enter]
cd httpdocs
mv __transfer/typo3cms/projekt1 typo3cms/projekt2

In a TYPO3 project, the subdirectory typo3temp/var/Cache should be deleted, as it still contains some path information from the previous server. After deletion, the directory is automatically recreated the next time a website is accessed.

So that you can transfer your e-mail inboxes in step 8 and make the settings for the domains in step 7, you must add your domains to the package as virtual domains in the order management.

In the document root of the domain, save the directory to which you moved the website in step 5: Moving files to the final destination.

For PHP support, select the appropriate PHP version for the website. On our website there is an overview of the TYPO3 versions and the corresponding PHP versions.

If the transfer takes a long time or further emails are received between the transfer and the final domain transfer, the transfer of the mailboxes can be restarted. Only the new emails are then transferred, making the process significantly faster than the first run.

SPF entry

The SPF entry is used to define which servers can send emails for a domain.

The server on which your package is located is automatically included in the SPF record.

v=spf1 +a +mx +a:servername.jweiland.cloud -all

If you send emails via another server, the SPF entry must be extended by an include:servername:

v=spf1 +a +mx +a:servername.jweiland.cloud include:servername -all

Multiple SPF records may not be created for one domain. An existing entry must always be extended or changed.

Check in the old customer menu which cronjobs are entered there and create them analogously in cloud hosting.

When executing scripts, httpdocs/ is added to the path, for example:

typo3cms/system/backup/daily (previously)
httpdocs/typo3cms/system/backup/daily (for cloud hosting)

When calling the TYPO3 scheduler, the execution interval of 5 minutes can be specified in "Cron Style" as */5 * * * * *.

For other timings, you will find further tips and a"Cronitor" on an external page.

If the scheduler.sh script is called via cronjob, the path to the correct version of the PHP interpreter must be adjusted.

Example, if PHP 7.2 is currently used in scheduler.sh (in one line):

env -i /usr/local/bin/php7-72LATEST-CLI -f ~/typo3cms/projekt1/typo3cms scheduler:run

the PHP version 7.2 is now specified with

env -i /opt/alt/php72/usr/bin/php -f ~/httpdocs/typo3cms/projekt1/typo3cms scheduler:run

Once all data and mailboxes have been transferred and the functionality of the website has been checked, you can now transfer the domain(s). A distinction must be made here as to whether the domain was previously registered with us or with another provider. In the latter case, you must also check whether the domain should be transferred to us or remain with the other provider.

Domain should be moved to cloud hosting

First, you should check whether additional name server settings have been made for the domain.

In Classic Hosting, go to your customer menu. From the BUSINESS plan onwards, you will find a cogwheel icon in the line for your domain under "Configuration" ' "Domain administration". Click on this gear icon and then on "Edit nameserver" in the menu that appears.

If "auto" is entered everywhere in the settings, no deviating or additional entries have been made.

However, if there are additional or different settings here, these must be noted carefully, as they will have to be created again in the same way later for cloud hosting. It is best to take screenshots, bearing in mind that the table with the entries may be longer and can be scrolled.

In addition to the respective host name, the type and destination or value of the entry is also important!

Once the details have been noted, the domain must be released for a provider change at jweiland.net or the other provider.

• If the owner data in the Classic Hosting and Cloud Hosting package match, the release can be requested from the email address stored in the Classic Hosting master data.
• If the owner data in the Classic Hosting and Cloud Hosting package do not match, the domain owner must request the release using the form Cancellation of domains (no cancellation of the package).

The AuthCodes (authorization code) required to transfer the domains are communicated in both cases in a confirmation that is sent by email to the email address stored in the Classic Hosting package in the master data.

You can now order the domain in the order management for the provider change.

A domain can also be used with us if it is registered via another provider and is not to be transferred to us. In most cases, only the website will then run via us while, for example, the e-mail traffic runs via another provider.

As you have already created the domain in step 6: Create virtual hosts, you now only need to update the IPv4 and IPv6 address with your domain provider.

Finally, you can now set up an SSL certificate for your domain.