How to Move Your Website to a New Host Without Breaking It

Migrating a website has a reputation for being risky, and that reputation is mostly earned by people doing the steps in the wrong order. Done carefully, a small site can be moved with no visible downtime at all. Done carelessly, you can lose a day of orders, break your email, and discover that your only backup was on the server you just cancelled.

The difference is preparation rather than technical skill. Here is the sequence that works, along with the mistakes that catch people out.

Before You Touch Anything, Write Down What You Have

Most migration disasters start with an incomplete picture. Spend twenty minutes documenting the following, because you will need every item.

Find out where your domain name is registered, and confirm you can log in. The registrar is often a different company from your host, and people frequently do not know which one holds their domain.

Find out where your DNS is managed. This is not always the registrar. It might be your host, your registrar, or a service like Cloudflare sitting in front of everything. Changing DNS records at the wrong place does nothing at all, which is a confusing failure to debug.

Find out where your email is handled. This is the single most common way migrations go wrong. If your business email runs on the same provider as your website, moving the site can take your email with it. Note your MX records before you change anything.

Finally, note the technical details of your current setup: the software version your site runs, the PHP version, the database type and version, any scheduled tasks running in the background, and any SSL certificate arrangements.

Choose the New Host With Migration in Mind

When comparing providers, a few things specifically make migration and its aftermath easier.

Check whether backups are included and whether you can restore them yourself. Being able to snapshot the new server before you make changes turns experimentation into something reversible.

Check the refund window. A 14 or 30 day money back period gives you room to abandon the move if the new environment turns out to be unsuitable.

Check that the software versions you need are available. Moving to a server with a much newer PHP version than your site expects will break things, and it is far easier to discover that before you migrate.

Independent providers are usually cheaper than the large platforms for equivalent resources. Hosts such as QDE offer virtual private servers from a few euros a month with NVMe storage and daily backups included, which compares favourably to shared hosting renewal pricing while giving you dedicated resources rather than shared ones.

One useful piece of context: if you are in the EU, providers of data processing services have been under a statutory obligation since September 2025 to cooperate technically when customers switch away, and switching charges are being phased out entirely by January 2027. If your current provider is unhelpful about exporting your data, they may be on shakier ground than they suggest.

Lower Your DNS TTL First

This step happens days before the migration and is the one most guides omit.

Every DNS record carries a TTL, or time to live, which tells the rest of the internet how long to cache the answer. A typical default is 24 hours, meaning that after you change your records, some visitors continue reaching the old server for a full day.

Two days before your planned migration, log into wherever your DNS is managed and lower the TTL on your A record to 300 seconds. Then wait. Once the old, long TTL has expired everywhere, changes will propagate in about five minutes rather than a day. Raise it back to normal a few days after the move is complete.

This single step is the difference between a five minute cutover and a day of split traffic.

Take a Backup You Have Actually Verified

Download a complete copy of your website files and export your database. Store both somewhere that is not either server: your own machine, plus cloud storage.

Then verify it. Open the database export in a text editor and confirm it contains your actual content rather than an error message, which happens more often than you would think when exports time out on large databases. Check that the file archive contains your uploads directory and any configuration files, which are sometimes hidden and get skipped by naive downloads.

An unverified backup is the reason people lose sites during migrations. Ten minutes of checking removes that risk almost entirely.

Build and Test the New Site Before Switching Anything

This is the core of a safe migration. You set the new server up completely, and you test it thoroughly, all while the live site continues serving visitors from the old host.

Upload your files to the new server. Import the database. Update your site’s configuration file with the new database name, user and password, since these will differ from the old host.

Now test without touching public DNS. There are two ways. Most hosts provide a temporary URL or staging domain you can use. Alternatively, edit the hosts file on your own computer to point your domain at the new server’s IP address, which makes your browser reach the new site while everyone else still sees the old one. This is the cleanest way to test the real domain in the real configuration.

Work through the site properly. Load several pages. Submit a contact form. If you run a shop, complete a test purchase. Log into the admin area. Check that images load, since broken images usually indicate a permissions problem or hardcoded absolute URLs in the database.

Fix everything you find before proceeding. There is no time pressure at this stage, which is exactly why this order matters.

Freeze, Cut Over, and Watch

Pick a genuinely quiet period for your audience. Then stop making changes to the live site: no new orders processed manually, no content edits, no comments approved. Anything that lands on the old site after your final database export will be lost.

Do a final export of the database and import it into the new server, so the content is current.

Then change the A record to the new server’s IP address. Leave your MX records exactly as they are unless you are deliberately moving email as well. This is worth saying twice, because MX records are what stops your email disappearing.

Within a few minutes, traffic starts arriving at the new server. Confirm your SSL certificate is issued and valid on the new host, since a browser security warning is far more damaging than a slow page.

The Two Weeks Afterwards

Do not cancel the old hosting immediately. Keep it running for at least two weeks. It costs one more billing cycle and it is your fallback if something surfaces late.

In the days after the move, check that contact forms actually deliver, since outbound email often needs configuring separately on a new server. Confirm any scheduled background tasks were recreated, because these do not transfer with your files and their absence is silent. Watch your search console for crawl errors, and monitor site speed against what you had before.

Once everything has been stable for a couple of weeks, raise your DNS TTL back to a normal value and cancel the old account.

The Short Version

Document what you have. Lower the TTL early. Back up and verify. Build and test the new site fully before changing any public records. Freeze content, do a final sync, then switch the A record while leaving MX alone. Keep the old host for two weeks.

Follow that order and migration is a routine task rather than a gamble. Skip the testing step and it becomes the thing people warn each other about.