Copying files and databases to a new host

Moving a site to a new host is really two jobs stitched together: copy the files, copy the database, then tell the files where the database now lives. Do those three things in the right order and the move is straightforward. Do them out of order, or skip the last one, and you end up with a site that looks copied across but won't load.

This guide covers the manual route through cPanel and phpMyAdmin, which is what most people moving a WordPress or other database-driven site onto Hostworld will use, plus the command-line alternative for databases too large for phpMyAdmin to handle comfortably.

Before you start

This picks up once you have a Hostworld hosting account or VPS set up and can log into cPanel (or SSH, if you're on a VPS). If you haven't got hosting in place yet, our cPanel hosting guides cover choosing a plan first.

• Back up the old site before you touch anything. A full copy of the files and a fresh database export, kept somewhere other than the old host, means you can always start again if a step goes wrong. Do not treat this as optional.
• Know where the site's database credentials live. For WordPress this is wp-config.php. Other applications keep the same information in a similarly named config file.
• Check the database size. phpMyAdmin in cPanel has a practical ceiling of around 1GB for import and export. Above that, you're better off on the command line from the start, which this guide also covers.
• If the old host is cPanel and you have WHM/root access (a reseller account or a VPS running WHM), there's a Transfer Tool built into WHM that automates a cPanel-to-cPanel move. It is only available with WHM access, so most shared-hosting customers on the old side won't see it and will need the manual route below instead.

Step 1: Back up the old site

Before exporting or copying anything, take a full backup of the files and the database as they currently stand. If something goes wrong partway through the move, you want a known-good copy to fall back to rather than a half-migrated site with no original to compare against. Store the backup somewhere other than the old host, on your own machine or in cloud storage, so it survives even if the old account is cancelled or wiped during the switch.

Step 2: Copy the files across

If you have access to cPanel's File Manager on the old host, select the site's files, compress them into a single archive, and download that archive to your computer. Then upload the archive into File Manager on the new Hostworld account and extract it there. This avoids transferring thousands of small files one at a time, which is slow and more likely to drop something partway through.

If File Manager isn't available to you, an FTP or SFTP client works the same way: download everything from the old host, then upload it to the new one. Either way, keep the folder structure identical. WordPress and most other applications expect their files in specific relative locations, and moving things around breaks paths that were never meant to change.

Step 3: Export the database

With the files copied, move on to the database. In cPanel, open phpMyAdmin from the Databases section of the cPanel home screen. It opens in its own window.

1. In the left-hand pane, click the database you want to export.
2. Click the Export tab.
3. Leave the export method set to Quick and the format set to SQL, unless you have a specific reason to change either.
4. Click Export. phpMyAdmin generates a .sql file and downloads it to your computer.

If you'd rather not use phpMyAdmin's interface, cPanel's Backup Wizard offers the same export as a more guided flow: open Backup Wizard, click Backup, then MySQL databases, and click the name of the database you want. It downloads instantly. This produces the same kind of SQL file phpMyAdmin does; use whichever interface you find clearer.

Step 4: Check the export before you import it

Two things are worth checking here, because both cause problems that don't announce themselves clearly:

• Size. If the file is large, compress it before uploading it for import. A large uncompressed SQL file is more likely to time out or stall partway through an upload, and a stalled import can leave a database partially written with no obvious error message, just a site that behaves as though half its content is missing.
• A stray CREATE DATABASE line. If you open the file in a text editor and see a line like CREATE DATABASE db_name near the top, and you're importing into a database that already exists on the new host with a different name, remove that line. Otherwise the import can try to create a database it isn't allowed to, or one that doesn't match what you actually want to import into.

Step 5: Import the database on the new host

In phpMyAdmin on the new Hostworld cPanel account:

1. In the left-hand pane, click the database you want to import into. This should be a fresh, empty database created for the new site, not one already holding unrelated data.
2. Click the Import tab.
3. Under "File to Import", click Browse and select the SQL file you exported.
4. Run the import.

Check the target database is genuinely the right one before you click Import. A standard database dump includes a DROP TABLE IF EXISTS instruction ahead of each table it creates. That means if you import into a database that already contains tables with the same names, those existing tables are deleted first and replaced with the imported ones, no confirmation prompt, no warning. If there was anything in that database you meant to keep, it's gone. Importing into a fresh, empty database avoids the question entirely.

Step 6: If the database is too large for phpMyAdmin, use SSH instead

Above roughly 1GB, or if you're on a VPS and comfortable with the command line, mysqldump is the more reliable route. It runs the same way on AlmaLinux, Ubuntu and Debian, since it's a MySQL client tool rather than something tied to a particular Linux distribution.

To export on the old server:

mysqldump -u username -p database_name > database_dump.sql

This connects to MySQL as username, prompts for the password, and writes the entire contents of database_name out to database_dump.sql as plain SQL statements.

To import on the new server:

mysql -u username -p database_name < database_dump_toimport.sql

Note the direction of the arrow: > when exporting sends output out to a file, < when importing reads a file in. Both commands are run from a normal Linux shell prompt, not from inside the mysql command-line client. Typing mysqldump after you've already logged into MySQL is one of the more common causes of a confusing syntax error, because mysqldump is a separate program, not a MySQL command.

Step 7: Update the database credentials in the site's config file

This is the step people forget, and it's the reason a site can have its files and database both copied correctly and still refuse to load. Copying the files across does not copy the connection details, because the old details were specific to the old server. For WordPress, open wp-config.php and update:

• DB_NAME, the name of the database on the new host
• DB_USER, the database username on the new host
• DB_PASSWORD, the password for that user
• DB_HOST, usually localhost on cPanel hosting, but check what's shown in cPanel's Databases section for the new account

Leave everything without matching credentials and WordPress tries to connect using the old server's details, which no longer resolve, and shows a database connection error. Other applications keep the same four pieces of information in a similarly structured file; the fix is the same regardless of what the file is called.

While you're in there, check the permissions on the config file. WordPress recommends 440 or 400 for wp-config.php, restrictive enough that only the file owner can read it, since it holds a plaintext database password.

Step 8: Sort out the domain, don't touch the SQL file directly

If the new site will run under the same domain, there's nothing further to do here. If the domain itself is changing, or you're testing the new copy on a temporary URL before switching, resist the temptation to open the SQL file and do a find-and-replace on the old domain. WordPress stores some settings, particularly serialized arrays used by widgets, theme options and some plugins, in a format that includes a stored character count for each string. A find-and-replace that changes the domain's length silently breaks that count without throwing an error, and the corruption doesn't always show up until much later. Make URL changes through the application itself once it's running, not inside the raw database export.

Step 9: Test before you switch anything over

With the files uploaded, the database imported and the credentials updated, check the new copy works: load key pages, log into the admin area, try a form or two if the site has them. Do this before you point the domain's nameservers at Hostworld or change anything visitors rely on. If you find a problem at this stage, you're fixing a test copy, not live traffic.

Once you're happy the new copy is working, the domain itself needs pointing at Hostworld. That's done by setting the nameservers at your registrar, wherever the domain is registered, to:

• ns1.serverworld.uk
• ns2.serverworld.uk
• ns3.serverworld.uk
• ns4.serverworld.uk

Nameserver changes take a while to spread across the internet, so expect a period where some visitors still reach the old host and some reach the new one. That's normal and settles down on its own.

What next

If you're moving several sites at once, or the database is unusually large and you'd rather work from the command line throughout, our VPS guides cover running your own database tools on a Linux VPS such as our Linux VPS line. For the backup habits worth keeping once the site is settled on its new home, see our backup guides, and for the WordPress-specific side of a move, including plugins and themes, our WordPress guides go into more detail. If you get stuck partway through, open a support ticket and we'll take a look.