Creating and migrating a site in KeyHelp Print

Moving a site onto the server involves two separate parts — the files and the database. This guide covers both, in the order that avoids surprises.

1. Prepare the data on the old hosting

Packing the files into a single archive makes the transfer much faster than copying thousands of files individually:

tar -cvzf site.tar.gz ~/www/site

Then export the database:

mysqldump -u<user> -p <database_name> > dump_file.sql

Keep both files until the move is complete and verified.

2. Create an FTP user

1. Go to User administration and use Log in as this user for the account the site belongs to.
2. Go to Settings → FTP users and add an FTP user.
3. Fill in the form and save.

You can then upload the files with any FTP client. Choose FTPS or SFTP in the client rather than plain FTP — over plain FTP the user name and password travel in clear text.

3. Upload the files

Upload the archive and unpack it on the server. The web root for KeyHelp sites is:

/home/users/<username>/www

Then tell the panel where the files are: go to Domains, choose Edit for the domain, and set the directory containing the site.

Check where the files actually ended up. Most archives contain a top-level folder, so unpacking produces www/site/index.php rather than www/index.php — and the site then shows a directory listing or an error instead of the home page. Either move the files up a level, or point the domain at the nested directory.

4. Create the database and import the dump

1. Logged in as the same user, go to Settings → Databases and add a database — see Creating and managing databases in KeyHelp.
2. Import the dump you made earlier:

mysql -u<user> -p <database_name> < dump_file.sql

For a large dump this is far more reliable than importing through phpMyAdmin in the browser, which can fail on the upload size or the script time limit.

5. Point the site at the new database

Update your CMS configuration file with the database name, user and password on this server — they are almost never the same as on the old hosting. The file is usually wp-config.php for WordPress, configuration.php for Joomla, or .env for framework-based applications.

A site showing a database connection error after a move has this as its cause in the great majority of cases.

6. Test before switching the domain

Do not change the DNS until the site works here. Until then, visitors still reach the old hosting, so you have as much time as you need. The subdomain created with the user account — username.servername — is useful for checking the site before the domain points here.

Once you are satisfied, point the domain at this server, and keep the old hosting running for a few days: DNS changes propagate gradually, and if something turns out to be missing you still have the original.

Do not forget the mail

Moving the site does not move the mail. If your mailboxes are still with the old provider, changing the domain's DNS stops mail arriving unless the MX records are handled deliberately. Decide before the switch whether the mail is moving too.

If anything goes wrong during the move, open a ticket from your client area describing the stage you reached.