Is your old server slow, has renewal become too expensive, or have you simply outgrown your plan? The migration to a new server may seem daunting at first, but if you prepare properly, your visitors won’t even notice. In this guide, we’ll walk you through the steps from planning to cancelling your old service: what to back up, how to transfer your files and database, when to update your DNS, and how to avoid losing your emails.

If you’re still looking for a new home, our hosting plans offer everything from web hosting to cPanel and WordPress hosting. And if you’d rather not do it yourself, we’ll explain at the end of this article how we can migrate your website for free.

1. Planning and timing

The most important part of the migration is what happens before the data is copied. Decide in advance:

• What are you moving? Just the website, or your emails as well? Your domain registration can stay where it is; you don’t need to perform a transfer when switching hosting providers.
• When? Choose a period with low traffic (for example, weekday nights for an online shop), and avoid scheduling it during a campaign or promotion.
• Who has access to what? You’ll need access to your old hosting control panel or FTP, your database details, and the ability to manage your domain’s DNS settings (either with your registrar or wherever your DNS zone is hosted).
• How long will your old subscription remain active? Allow for a grace period: your old hosting account should remain active for at least a few days, or preferably a week or two, after the migration.

For online shops or websites that are updated frequently, it is advisable to freeze content whilst the migration is taking place: whilst the data is being transferred, no new posts should be published and, if possible, no orders should be accepted. Otherwise, data generated on the old server will be missing from the new location.

2. Inventory: what are you transferring?

Make a list of everything running on your old hosting account. Many people only think of their website files, only to realise after the migration that something has been left out.

• Files: the entire website directory, including hidden files (such as .htaccess and .user.ini).
• Databases: all those used by the website, including usernames and permissions.
• Email: a list of mailboxes, their sizes, forwarding settings, automatic replies and mailing lists.
• DNS records: A, AAAA, CNAME, MX and TXT records, including SPF, DKIM and DMARC, as well as verification records for external services (Google, Microsoft 365, newsletter providers). Take a screenshot or export the entire zone.
• Scheduled tasks (cron): online shops and newsletter services often rely on these.
• SSL certificate: free Let’s Encrypt or paid? With a paid certificate, make sure you keep track of the expiry date and the private key.
• Other settings: PHP version and PHP parameters, redirects, password-protected folders, subdomains.

3. Reducing the TTL in advance

DNS records are cached by the world’s name servers for a certain period of time; this period is specified by the record’s TTL value. If an A record’s TTL is one day, some visitors may still be directed to the old server for up to a day after the change has been made.

Therefore, at least one day before the migration (or, more precisely, earlier than the current TTL), reduce the TTL of the records to be modified – primarily the A and MX records – to 300 seconds. This way, when the switch takes place, everyone will see the new server within a few minutes. After the migration, you can reset the TTL to its usual value.

If you’re not modifying records but changing your name servers, you’ll gain less from adjusting the TTL: the name server entries are stored by the domain registry, and updating them can take hours, or even a day or two, regardless of the TTL setting. Our article on DNS propagation covers this in detail, whilst our article comparing A-records and name server changes will help you choose between the two methods.

4. Full backup

Before you do anything, make a full backup of your old hosting account and store it on your own computer or in cloud storage. This will remain your starting point even if something goes wrong during the migration, or if your old provider deactivates your account earlier than expected.

On cPanel hosting, the full account backup packages files, databases and emails into a single file; on other platforms, you back up files and the database separately. Our guide to backups details the various backup methods.

5. Transferring files

There are three ways to transfer your files:

• FTP or SFTP: use an FTP program (such as FileZilla or WinSCP) to download your files from your old hosting account, then upload them to the new one. Where possible, use an encrypted connection (SFTP or FTP with TLS); details can be found in our FTP guide.
• File management and compression: when dealing with lots of small files (a WordPress site can have tens of thousands), it’s quicker to compress the folder into a ZIP file using your old hosting provider’s file manager, transfer it as a single file, and then extract it at the new location.
• rsync over SSH: if SSH is available on both sides, this is the fastest and most reliable method, and running it a second time will copy only the files that have changed in the meantime:

rsync -avz -e ssh felhasznalo@regi-szerver.hu:public_html/ ~/public_html/

The article on copying files between servers explains how to use rsync and scp. Make sure that the files are placed in the domain’s root directory on the new hosting account (this varies by provider: public_html, www, htdocs) and that hidden files are also transferred.

6. Exporting and importing the database

Export the database from your old hosting account into an .sql file, create an empty database with a user on the new account, and then import the file into it.

Using phpMyAdmin: select the database, save it in SQL format via the ‘Export’ tab, then import it via the ‘Import’ tab in the phpMyAdmin interface of your new hosting account. Our phpMyAdmin guide explains how to use the interface. With larger databases, the upload limit may cause problems; in this case, export the database in compressed format (.sql.gz) or use the command line.

From the command line (mysqldump):

mysqldump -u felhasznalo -p --single-transaction --default-character-set=utf8mb4 adatbazis > mentes.sql
mysql -u uj_felhasznalo -p uj_adatbazis < mentes.sql

The --single-transaction switch creates a consistent backup without locking the tables, whilst the utf8mb4 character set preserves accents and emojis. After the import, take a look at a few tables and check that the Hungarian text is correct.

7. Updating the settings

On the new hosting account, the database name, username and password will almost certainly be different, so you’ll need to update these in your website’s configuration. For WordPress, this is the wp-config.php file:

define( 'DB_NAME', 'uj_adatbazis' );
define( 'DB_USER', 'uj_felhasznalo' );
define( 'DB_PASSWORD', 'eros-jelszo' );
define( 'DB_HOST', 'localhost' );

On other systems, this information is stored in configuration.php (Joomla), .env (Laravel) or a similar file. If your website uses absolute paths (for example, /home/regifelhasznalo/public_html/), you’ll need to update these to match the new server as well.

If your domain name changes (or, for example, you switch from http:// to https://), you’ll need to update the old address in the WordPress database as well. Do not do this using plain SQL or a text editor, as WordPress stores some of its settings in serialised form, and altering the length can break widgets and theme settings. WP-CLI handles this correctly; first, run a test to see what would change:

wp search-replace 'https://regi-domain.hu' 'https://uj-domain.hu' --all-tables --dry-run

Without SSH, a plugin designed for this purpose (such as Better Search Replace) can do the same thing. If the domain isn’t changing, this isn’t necessary. Our WordPress migration guide covers further aspects of moving your WordPress site, such as migration plugins, whilst the steps for moving to aWh are summarised in the article on WordPress migration to aWh.

8. Testing before the DNS change

Before you redirect visitors, check the site on the new server. The simplest method is to use the hosts file: in this, you can specify that your own computer should use the new server’s IP address for the domain, whilst everyone else will still see the old one. Add this line (using your own IP address and domain):

203.0.113.10  cegnev.hu  www.cegnev.hu

On Windows, the file is located at C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, it is at /etc/hosts; you can edit it with administrator rights. After saving, it is advisable to clear your browser’s cache or open an incognito window.

What should you look out for whilst testing?

• The homepage and a few subpages load, and the images appear;
• Login to the admin panel is working;
• The contact form sends the message;
• In the online shop, the shopping basket and payment processes run through in test mode;
• There are no PHP error messages (if there are any, it is likely due to the PHP version or a missing extension).

After testing, don’t forget to remove the line from the hosts file, otherwise you won’t be able to see the changes yourself later on. During testing, the SSL certificate may still show an error, because Let’s Encrypt can only issue the certificate on the new server once the domain is pointing there; this is not a problem at this stage.

9. Configuring the DNS or name servers

If everything is in order, it’s time to make the switch. There are two ways to do this:

• Updating the records: the DNS zone remains in its current location; only the website (and, if email is also being moved, the MX record) points to the new server. It’s quick, and the TTL reduction takes effect here.
• Name server change: the entire DNS zone is transferred to the new provider. In this case, first set up the same records at the new location as those listed in the inventory (particularly the MX, SPF, DKIM and TXT records for external services), and only then change the name servers.

We have a separate guide on how to change your name servers securely. If you also wish to transfer your domain to another registrar, it is advisable to do this separately, once the hosting migration has been completed; the process is described in our article on domain transfer.

10. SSL on the new hosting service

As soon as the domain points to the new server, enable the certificate. On cPanel hosting, AutoSSL issues the certificate automatically; on KeyHelp-based web hosting, you must enable it on a per-domain basis; the steps for this are outlined in the article on enabling Let’s Encrypt certificates on web hosting. The certificate is usually ready within half an hour.

With a paid certificate, you have two options: either install the certificate and private key exported from the old server onto the new one, or have the certificate reissued using a new CSR. If an error message appears briefly between the switch and the SSL connection, this is to be expected for the reason mentioned above; if it persists after several hours, check that the domain is actually pointing to the new server.

11. Email migration

Email is the trickiest part of the migration, because emails stored in the old mailboxes do not transfer automatically via DNS.

1. Set up the email accounts on the new hosting service using the same addresses and, if possible, the old passwords, so that users have as little as possible to change.
2. Synchronise your emails via IMAP. The most reliable tool for this is imapsync, which copies data between two IMAP servers, including the folder structure and read/unread flags:

imapsync --host1 mail.regi-szolgaltato.hu --user1 info@cegnev.hu --password1 'regi-jelszo' \
         --host2 mail.uj-szolgaltato.hu --user2 info@cegnev.hu --password2 'uj-jelszo' \
         --ssl1 --ssl2

1. Point your MX record to the new server.
2. Run the synchronisation again in a day or two: any emails that arrived on the old server during the switchover will be transferred this way too.
3. Configure your email clients and mobile phones with the new server details (incoming IMAP, outgoing SMTP, ports, encryption).

If an account was set up using POP3 and the emails are only stored on the user’s computer, they must be uploaded from the email client to the new IMAP account. The entire process, including the address book and calendar, is detailed in our email migration guide.

12. Checking after the migration

Keep an eye on the site over the next few days:

• Use an online DNS checker to see whether the domain is already returning the new IP address from various locations around the world;
• send and receive emails from an external address (such as Gmail) in both directions;
• Check the server error log and the Google Search Console reports to see if there has been a sudden spike in 404 or 500 errors;
• Check that cron jobs are running and that emails from the website (order confirmations, password resets) are being delivered;
• Check the loading speed: if it’s slower on the new server, caching or the PHP settings may not have been configured correctly;
• If you have reduced the TTL, reset it to its usual value.

13. Cancelling your old service

Only cancel your old hosting service once everything is working and at least a few days have passed since the DNS change. Before that:

• Run the latest email synchronisation and check whether any new emails have arrived in the old mailboxes;
• Download one final full backup and keep it for a while;
• Check the notice period for your old contract and the renewal date to ensure you aren’t charged again.

The guide on terminating your hosting contract explains the steps involved. If you have given someone your old hosting login details to help with the migration, be sure to change your passwords afterwards.

Common mistakes when moving

• Terminating your old hosting account too early. If the DNS hasn’t been updated everywhere yet, or it turns out that a database has been left behind, there’s nowhere to retrieve it from.
• Forgotten DNS records. After changing name servers, emails may not arrive or an external service may stop working due to missing MX or TXT records.
• Missing hidden files. Due to the missing .htaccess, pretty URLs aren’t working, and every subpage returns a 404 error.
• Incorrect character encoding. If a database is exported with the wrong settings, strange characters appear in place of accented letters.
• Manual search-and-replace in the WordPress database. Widgets and template settings disappear due to corruption of the serialised data.
• Different PHP versions. The plugin written for an older version of PHP will throw an error on the new, more recent version; before migration, check which version your old site is running on and what the new hosting service supports.
• Migration during a busy period. If any orders or comments are received on the old server whilst this is happening, they will be lost.

Free migration with aWh

If you’d rather not go through the steps above yourself, all our hosting plans come with a free migration service, with minimal or even zero downtime:

1. Order your new hosting plan. Choose the package that suits your website.
2. Open a ticket on the client portal and provide the login details for your old hosting account.
3. We’ll transfer the files, databases and emails for you.

If your previous provider also uses cPanel and you choose cPanel hosting with us, we’ll migrate your entire account (files, databases, emails and redirects) in a single step. From other platforms, we’ll transfer the files via FTP (or SSH, if available), whilst databases will be backed up and restored separately. The migration is usually completed quickly; however, for large or complex websites, or if the old server only allows slow data transfer, it may take a few days. You can request a specific start time or a migration outside normal working hours. The details are set out in our article on hosting migration.

If you have any questions before the migration, please get in touch and we’ll help you choose the right plan.

Frequently Asked Questions

How long does it take for a website migration to complete?

Transferring a small introductory website takes an hour or two, whilst the DNS change takes anywhere from a few minutes to a day or two, depending on the TTL. With large online shops or a high volume of emails, the migration process takes longer, so it’s worth planning ahead in such cases.

Will my website go offline whilst it’s undergoing migration?

With a well-prepared migration, this is not the case: the old site remains operational until the DNS has switched over, whilst the new one is ready and tested by then. Any brief downtime is limited to the time taken to issue the SSL certificate or may be caused by a missed configuration step.

Do I need to transfer the domain as well?

No. The domain can remain with the original registrar; you just need to point the DNS to the new hosting provider. The transfer is a separate process, which you can sort out later.

Will my emails get lost if I move to another hosting provider?

No, not if you transfer the contents of the mailboxes using IMAP synchronisation and then run the synchronisation again after changing the MX record. Only then should you delete the old accounts.

• migration
• web hosting
• dns
• wordpress
• backups
• email