Website Migration: How to Change Server

Changing hosting is something most businesses do every few years and worry about every time. The reason for the worry is clear: if the site becomes unreachable during the operation or emails get lost, the customer notices. Yet migration, when the order is set up correctly, is a routine operation that can be done without downtime; problems almost always come from a skipped preparation step.

Is there downtime when migrating a site?

Not when it's done correctly. The reason is this: the old server isn't switched off until the new one is ready. The site is set up and tested on the new server, then the domain's pointer is switched to the new address. While the pointer change propagates, some visitors go to the old server and some to the new — since both are working, nobody sees downtime. Downtime happens only when the old server is switched off early or the switch is made before the new server is tested enough.

Take an inventory before migrating

What needs migrating is not just the files. Forgotten items surface days after the switch as "that's not working either". List at least the following:

• Site files and, if any, upload folders (images, documents).
• Database and connection details.
• Email accounts, the messages in the mailboxes, forwards and aliases.
• All DNS records: A, AAAA, MX, TXT (SPF, DMARC, verification records), CNAME, CAA.
• SSL certificate and its renewal method.
• Scheduled jobs (cron) and any services running in the background.
• Third-party connections: payment provider, shipping integration, email sending service. Some grant access based on the server IP address and stop working when the IP changes.

Writing this list down is the most useful step of the migration. The last item is especially often skipped and causes the payment or shipping integration to stop silently after the switch.

Lower the TTL in advance

Each DNS record has a TTL value: it says how long the record is kept in cache. The default in most places is a few hours.

One day before the switch, lower the TTL to 300 seconds (5 minutes). That way the pointer propagates quickly at the moment of the switch and the period of traffic split between the two servers is shortened. After the switch is complete and you've verified everything works, put the TTL back to its old value.

This single step turns the migration from "a few hours of anxious waiting" into "a switch of a few minutes".

Files and database

When moving files, take care not to skip directory permissions and hidden files (like .htaccess, .env); the most common "the site opened but looks broken" situation comes from a missing configuration file.

With the database the order matters: move the files first, and take and transfer the database backup last. If new records are created on the site in between (form messages, orders), those records stay in the old database. On busy sites the switch is therefore planned for the hour with the lowest traffic.

After transferring the database, don't forget to update the connection details for the new server. Also, if there are absolute addresses embedded in the site pointing to the old server or old domain, these must be fixed too.

Email is a separate job

In a hosting change the biggest data loss happens on the email side, because the messages in the mailboxes don't come with the file transfer.

Create the accounts on the new server, then copy the existing messages over IMAP. This method preserves the folder structure, read/unread status and attachments, and doesn't touch the source mailbox. Don't close the old accounts immediately after the migration; email may still land on the old server for a while as the MX record propagates. Keeping them open for a few weeks and transferring the last arrivals too is the safest route.

Test before going live

The new server can be tested before the domain is pointed to it. By writing the new server's IP address into your computer's hosts file, you open the site from the new server on your own machine only. That way visitors keep being served from the old server while you try the new one with the real domain.

In testing look at: do the home page and inner pages open, does form submission work, can you log in to the admin panel, are images and uploaded files visible, does the payment step go through to the end.

The moment of the switch

If everything has been tested, the switch is short: you point the domain's A record (and MX records if needed) to the new server. Because the TTL is low, propagation completes within minutes.

Leave the old server running during the switch. Some visitors and some networks keep using the old record for a while; as long as both sides are up, this is invisible.

Prepare the SSL certificate on the new server before the switch. If certificate validation depends on where the domain points, generate it right after the switch — browsers may show a security warning in the short window in between.

Post-switch checklist

• Does the site open at both addresses (with and without www)?
• Is SSL valid, does the browser show a warning?
• Do form submissions arrive as email?
• Do emails sent from the new address land in spam? Were the SPF, DKIM and DMARC records updated for the new server?
• Are scheduled jobs running?
• Is the search engine crawling pages normally, or seeing server errors?
• Are internal links and file addresses broken?

The last item is hard to check by hand; running a link check quickly shows the broken addresses that appear after migration.

Rollback plan

The most reassuring side of migration is that rolling back is easy — as long as the old server is up. If a problem arises you point the DNS record back to the old one and, because the TTL is low, you're back within minutes.

So don't cancel the old hosting right after the switch. Keep it open for at least two weeks, a month if possible. During that time you both have the rollback option and can reach the source if an overlooked file turns up.

Common mistakes

1. Switching off the old server early. The main cause of downtime and data loss.
2. Not copying all DNS records. Moving only the A record and forgetting the verification TXT records silently breaks email and third-party integrations.
3. Switching without lowering the TTL. Propagation stretches over hours; the split-traffic period gets longer.
4. Starting without a backup. A full backup before migration is the last guarantee of rollback.
5. Leaving the email migration for later. After the MX changes, access to the old mailbox gets harder.

Frequently asked questions

How long does a migration take? Including preparation, half a day for a small site and a business day for a mid-sized e-commerce store is a reasonable estimate. The switch itself is measured in minutes.

Will my search ranking be affected? Not as long as the addresses don't change. What affects ranking is not the migration itself but long outages or broken addresses that occur during it.

What if I'm changing the domain too? Then the job isn't just a migration: you need to map the old addresses to the new one with 301 permanent redirects and keep the old domain for at least a year.

To record your current DNS records before migrating and verify them after the switch you can use the DNS Lookup tool, and to detect broken links after migration the Link Checker tool.