Zum Inhalt springen

Move websites, databases and mailboxes to cloud hosting

Hier erfährst Du, wie Du aus einem Classic Hosting oder von einem anderen Provider in ein Cloud Hosting Paket umziehen kannst.

Introduction

There can be many reasons for a move:

  • The project needs to be updated and requires a newer PHP or MySQL version.
  • The project does not support current PHP or MySQL versions and cannot be updated yet.
  • The maximum mailbox size of 10 GB in Classic Hosting is not sufficient.
  • Multiple packages should bemanaged in one customer account.
  • You don't want to spend money on SSL certificates and use free Let's Encrypt certificates instead.

PHP and MySQL versions in Classic Hosting

In the data center in Cologne, which was previously used for the Classic Hosting packages, only PHP versions 5.6 to 7.3 are currently provided. Older PHP versions that are no longer provided with security updates have been removed from the servers. Newer PHP versions 7.4 or 8.0 and 8.1 cannot be provided in the existing tariffs.

A migration of the databases from MySQL 5.6 to MySQL 5.7 is planned before the end of this year.

PHP and MySQL versions in cloud hosting

In our cloud hosting tariffs, we continue to offer the old PHP versions (from version 4.4) as "Hardened PHP" in addition to the current PHP versions. These hardened PHP versions will continue to be provided with security updates. When new security updates are released for current PHP versions, these updates are also applied to the old PHP versions as far as this is technically possible (backport, see https://de.wikipedia.org/wiki/Backport).

Besides a MySQL 5.7 compatible MariaDB 10.3 database, MySQL 5.6 databases are still available.

What happens during the migration of the databases?

When migrating MySQL 5.6 to MySQL 5.7 databases, it may happen that programs are not compatible with MySQL 5.7, which causes the website to malfunction.

The affected domain (website) will then usually stop working. Depending on the application and configuration, a blank (white) page appears instead because the PHP error messages are not enabled, or error messages are displayed.

What happens when old PHP versions are deactivated?

If further old PHP versions have to be switched off due to security vulnerabilities, PHP version 7.3 will be discontinued for the affected domain.

Depending on the application, the programming may not be compatible with PHP 7.3 and a blank white page will appear (PHP error) or error messages will be displayed. In this case the application must be updated by a developer.

There will be no data loss, all data will still be available on the webspace.

Solution: Move to cloud hosting

To continue running web applications with outdated or newer PHP or MySQL versions, we recommend moving to our new cloud hosting plans.

For this you will need to sign a new hosting contract. All actively used files, databases and e-mail accounts as well as forwardings and DNS entries have to be moved from the data center in Cologne to the data center in Frankfurt. From a technical point of view, this is a change of provider.

There are several options for carrying out the move

  1. You carry out the move yourself.
  2. You commission your agency or the creator or programmer of the website with the move.
  3. You commission us with the relocation of the websites. However, since our available capacities are limited, there may be longer waiting times.

In the following you will find the necessary steps. Depending on the option, parts will be done by us, your agency or yourself.

For all three options, please note that we cannot take over the relocation of the email inboxes. The necessary steps can be found under Step 8: Transfer e-mail boxes.

Prerequisite for the move

To perform the move, it is absolutely necessary to work on the 'shell' of the source and destination servers. The login on the shell is done via the SSH access and a terminal program. On Windows, use a program such as PuTTY or Mobaxterm.

Instructions for working on the shell.

If you don't have any experience with working on the shell so far, it is advisable to hire someone who already has experience with it to do the move.

Order and setup cloud hosting

Before the move can begin, a new hosting plan must first be ordered and set up.

We offer three cloud hosting plans to choose from: Cloud BASIC, Cloud PREMIUM and Cloud POWER. These differ in terms of storage space, performance and additional features.

We recommend the Cloud PREMIUM plan, which, in addition to 100 GB of storage space, also has numerous functions that are useful for developing and optimizing websites.

If, on the other hand, you only want to continue operating an existing website, the Cloud BASIC tariff with 30 GB of storage space could also be sufficient.

In our tariff overview, you can add the desired tariff directly to the shopping cart and complete the order as a new customer in our system. You also have to enter the bank details again if you want us to continue collecting the invoices by direct debit.

The package will automatically receive a free development domain from our system , according to the pattern 90xxxx.jweiland-hosting.de (the domain currently used by you will only be transferred when the move is completed).

Important note: When concluding a cloud hosting package, the conclusion of a contract for order processing with us is mandatory according to DSGVO. The hosting package will be activated as soon as this contract has been completed and signed.

Multiple packages in cloud hosting

While you had to book several packages with different customer numbers in Classic Hosting, there is now the possibility to book several packages in one customer account under one customer number in Cloud Hosting. Under this customer account you can now book as many cloud hosting plans (shared hosting or servers) as you like. Additional logins can be created for each of the booked tariffs, different authorizations are also possible.

A customer account is uniquely identified by the specified e-mail address, which thus cannot be used for multiple customer accounts. The address entered in the order or in the customer account corresponds to the billing address. Tariffs, domains or other additional services that are due at a certain time are billed in one invoice.

Implementation of the move

Empfohlene vorbereitende Maßnamen

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.

Step 1: Ordering a cloud hosting package

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.

Step 2: Back up databases to files

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.

Step 3: Transfer all files

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

Step 4: Read content into new database

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.

Step 5: Move files to the final destination

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.

Step 6: Create virtual hosts

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.

Step 7: Make hosting settings

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.

Step 8: Transfer e-mail inboxes

Preparation for the mail transfer

A transfer of e-mail mailboxes is only necessary if corresponding e-mail mailboxes have been created in the previous hosting plan and these are used via IMAP (e-mails remain on the server and are not stored locally on the computer). If emails are retrieved via POP3, the email mailboxes should not contain any emails (utilization 0 MB as in the image "Classic Hosting - Email mailbox").

If you have your own mail server for your domain or use your emails via another provider, you can continue with step 9: Setting for sending emails from the website.

Important note for our Classic customers:

If you use the Horde or Roundcube webmailer to receive and send emails and use one or more address books there, you must export these address books before the transfer and import them into the cloud hosting in Roundcube. Use the vCard (3.0) format for this. The address books are not transferred automatically.
Signatures or autoresponders must also be recreated, as these cannot be transferred either.

You can find a list of the e-mail addresses you have created in your previous customer menu under Manage e-mail addresses (screenshot "Manage Classic Hosting e-mail addresses"). If email addresses have been created there, you must first create these mailboxes in Cloud Hosting. However, this is only possible if domains have already been registered in the Cloud Hosting package or if they have been created as described in step 6: Create virtual hosts.

Configure the email traffic as described under Email settings for the domain.

In the domain settings under Domain: Email, there is a function for mass mail import, which can be used to automatically create email mailboxes, forwarders and aliases using a .csv file. You can request this from us, for example, if you need to move many email addresses from Classic to Cloud Hosting.

Mailtransfer Tool

Nachdem alle zu übertragenden Postfächer im Cloud Hosting Paket angelegt wurden, rufst Du unser Mailtransfer Tool auf: https://mailtransfer.jweiland.net

Nach Klick auf "Übertrage den Inhalt meines Postfachs" erscheint die Seite "Postfächer übertragen".

Möchtest Du Postfächer aus einem Classic Hosting Paket in ein Cloud Hosting Paket übertragen, dann wähle bei "Alter Anbieter" bitte "jweiland.net Classic-Hosting" aus. Andernfalls wähle den Anbieter aus, von dem Du die Postfächer übertragen möchtest.

Bei "Neuer Anbieter" wählst Du dann Deinen Cloud Hosting Server aus, den Du in der E-Mail "KN ...... - Ihr Cloud Hosting Tarif Cloud ........ wurde fertig eingerichtet" mitgeteilt bekommen hast.

Über die Schaltfläche "+ Ein weiteres Postfach hinzufügen" können weitere Postfächer des selben Anbieters zur Übertragung hinzugefügt werden.

Bei Klick auf "Weiter" werden die Zugangsdaten geprüft. Sind diese korrekt, wird die Übertragung gestartet. Außerdem wird ein Link angezeigt, unter dem Du den Status der Übertragung prüfen kannst. Bei großen Postfächern kann die Übertragung mehrere Stunden dauern.

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.

If the display of the mailbox load is not sufficient for you to check the transfer and you want to check whether all emails are available in the new mailbox before moving the domain, you must use the Roundcube webmailer in cloud hosting.

To do this, however, you must first create an A-record for the subdomain "webmail.your-domain.com" with the IP address of the cloud server in the DNS settings of the domain (in your Classic Hosting, not possible in the PRIVATE plan, or with the previous provider). Some time after the A-record has been created, the Roundcube webmailer can be accessed via the address webmail.your-domain.com.

As before, the number of emails that can be sent per mailbox is limited to 250 emails per hour.
In addition, there is a limit of 500 e-mails per hour for each domain and 1,000 e-mails per hour for the hosting package. If higher limits are required (e.g. newsletter dispatch or many mailbox owners), you can request an increase in the limits from us using the form.
E-mails sent in excess of these limits will not be stored temporarily or delivered with a delay, but will be discarded.

Make sure you use secure passwords for your e-mail inboxes and do not pass them on to third parties. If spam is sent via the domain, it can be deactivated for sending e-mails.

Step 9: Setting for sending e-mails from the website

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.

Step 10: Set up cronjobs

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

Step 11: Transfer domain

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.

Use of a domain with external registration

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.

Step 12: Set up SSL certificate

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

Troubleshooting

In this chapter we will provide troubleshooting tips in case the website on cloud hosting does not work as expected.

Error code 500: Internal Server Error

If an error 500 is displayed when calling the website, the following tips can help to fix it:

  1. Delete the TYPO3 folder typo3temp/var/Cache.
  2. Check if the file .htaccess in the start directory contains one of the following entries, if yes comment (prefix the line with #):Options +FollowSymLinks Options -Indexes Options +Indexes
Updated: 27.02.2025