How to Change Web Hosting Without Downtime: Migration Checklist

How do you change web hosting without losing your site or email?

To change web hosting, you copy your site files, database, and mailboxes to the new provider, then point DNS at the new server. The safe order: take a full backup, set up the new account, test it through your hosts file, lower the TTL in advance, switch DNS, and keep the old plan running until traffic stops.

Each step in that order closes a specific risk. The backup is your way back. Testing lets you see errors before your visitors do. Lowering the TTL in advance means the switch spreads in minutes instead of days. If you break the order, for example by canceling the old plan first and looking for a backup later, there is no way back.

This guide covers the technical side of how to change web hosting: backups, setup, testing, DNS, email, SSL, and the cutover itself. We are a digital marketing and web team, not a hosting company. That is why we tie every command and setting to official documentation. We also point out, section by section, when you should not do the work yourself.

What should you inventory before the move?

When you change web hosting, most problems come from what you forget, not from what you copy. So the first job is a written list of everything that runs on your current account. Without that list, "everything moved" is only a guess.

• The main domain, subdomains, and any addon domains.
• Databases, database users, and their privileges.
• Email accounts, forwarders, autoresponders, and filters.
• Scheduled tasks (cron jobs) and the script paths they call.
• The PHP version, enabled PHP extensions, and custom limits such as memory.
• Every record in the DNS zone: A, AAAA, CNAME, MX, TXT, and SRV.
• Outside services that allowlist your server IP, such as payment gateways, invoicing tools, shipping APIs, or accounting software.

The last item is the one people skip most often. For example, some payment providers and business APIs only accept requests from a registered IP address. If you forget to register the new IP, the site loads fine, but checkout fails quietly. Also export a full copy of your current DNS zone. You can check each record with our DNS lookup tool before you touch anything.

Is a hosting move the same as an SEO migration?

No, they are two different jobs. When you only move hosts, the domain and URL structure stay the same; only the server behind them changes. An SEO migration changes the domain, the URL structure, or the site architecture. That brings in extra work such as 301 redirects and a URL mapping sheet.

Google makes the same distinction. Google Search Central's guide to site moves without URL changes treats an infrastructure-only move as its own scenario. In that case the main search goal is simple: Googlebot must reach the new server without trouble, and the site must keep responding.

So if you are also changing your domain or restructuring the site, follow our website migration SEO checklist alongside this guide. It covers the redirect plan, URL mapping, and Search Console steps in detail, so we will not repeat them here. That said, we recommend you avoid doing both jobs on the same day. Move the server first and let the site run cleanly for a few days. Then start the structural changes. That way, if something breaks, you can tell whether the server or the URL change caused it.

How do you back up files, databases, and email?

The backup is your insurance policy, and it has three parts: site files, the database, and mailboxes. If you use cPanel, its Backup section offers a full account backup as well as partial backups. With partial backups you can download the home directory, MySQL databases, and email forwarders and filters separately.

If you have SSH access, you can also dump the database from the command line. The example below uses the --single-transaction option for a consistent dump of InnoDB tables:

mysqldump --single-transaction -u db_user -p db_name > backup.sql
tar -czf site_files.tar.gz public_html

Always verify the backup after you take it. Open the archive and spot check a few files. Then look at the end of the SQL file to confirm the dump finished. Also, do not leave the only copy on the old server. Download it to your own machine or to separate storage.

We explain backup types and retention in our website backup strategy guide. For restore details with mysqldump, see our database backup and restore guide.

How do cPanel to cPanel transfer tools work?

If both providers run cPanel, your job gets easier, because cPanel has tools that move a whole account at once. According to cPanel's official documentation, the Transfer Tool in WHM copies accounts, packages, and configurations from a source server to a destination server. It needs root access on the destination server.

The documentation lists these details:

• It copies account data, database information, email data, and mail routing.
• It can bring over DNS zone files when certain conditions are met.
• It does not move two factor authentication settings or DNS zone templates.
• For cases without root access, WHM offers a separate "Transfer or Restore a cPanel Account" interface.

On shared hosting you will not have WHM access. In that case the practical route is to download a full account backup from the old host and ask the new provider's support team to restore it. Many providers do this for free; still, ask before you sign up. If the panels differ, for example when you move from Plesk to cPanel, tool support changes. In short, use a transfer tool when the panels match. When they do not, move the files and database by hand.

How should you set up the new hosting account?

First, add the domain to the new account. Next, upload the files to the right directory and create an empty database and user. Then import the dump file:

mysql -u new_db_user -p new_db_name < backup.sql

New providers often add a prefix to database names and usernames. As a result, you need to update the site's configuration file. In WordPress that file is wp-config.php; in Laravel it is the .env file. Replace the database name, user, password, and host with the new values.

After that, match these settings to the old server:

1. The PHP version and required extensions.
2. PHP limits such as memory and upload size.
3. File and folder permissions.
4. Cron jobs and their script paths.
5. Any absolute file paths hard coded in the application.

If the PHP version does not match, the site may show a blank page or an error code. In cPanel you pick the version in the MultiPHP interface. If you are moving an older site, run it on the old PHP version first and get it working. Then treat the PHP upgrade as a separate task after the move is done.

How can you test the new server before changing DNS?

The safest test is to point the domain at the new server on your own computer only. You do this with your operating system's hosts file. The rest of the world keeps seeing the old server, while you browse the new one under the real domain.

On Windows the hosts file lives at C:\Windows\System32\drivers\etc\hosts. On macOS and Linux it is /etc/hosts. Open it with admin rights and add a line like this:

203.0.113.10  example.com  www.example.com

That IP is a documentation example; you use the IP your new provider gives you. After saving, clear your browser cache or open a private window. Then test the following:

• Do the home page, category pages, and product pages load?
• Can you log in to the admin area?
• Does the contact form send email?
• Do images and file downloads work?
• Do search, the cart, and customer login work?

When you finish, remove the hosts line. Otherwise you cannot be sure which server you see after the DNS change. Google also recommends testing the new infrastructure in a browser before launch. In addition, it suggests using the URL Inspection tool in Search Console to confirm that Googlebot can reach it.

Why and when should you lower the TTL?

TTL tells resolvers how long, in seconds, they may cache a DNS record. If the value is high, some visitors keep going to the old cached IP even after you change it. So lowering the TTL before the move is the most effective way to shorten propagation.

Timing matters here. When you lower the TTL, resolvers that already cached the old high value still wait until that old period runs out. Therefore you need to lower the TTL at least as far in advance as the current TTL. Google's guide gives a clear recommendation: lower the TTL to a conservative low value, for example a few hours, at least a week in advance.

In practice, you follow this order:

1. Note the current TTL of your A, AAAA, and, if needed, MX records.
2. Lower the TTL on those records at least a week before the move.
3. Change the IP on cutover day.
4. Once everything has run cleanly for a few days, raise the TTL back.

Do not skip the last step. A low TTL makes resolvers query your DNS more often. On the other hand, you can only change the TTL if you know where your DNS is managed. We cover that in the next section.

Should you change nameservers or just the A record?

There are two routes, and the choice depends on where your DNS lives. A nameserver change moves the entire DNS zone to the new provider. An A record change leaves DNS where it is; you only update the record that holds the site's IP address.

If you want the least downtime, the A record route is usually easier to control. For example, if your DNS sits with an independent DNS service or your registrar, you only change the IP and leave the zone alone. If you choose the nameserver route, build the full zone at the new provider first. Then compare it line by line with the old zone. You can see your registrar and current nameservers with our WHOIS lookup tool.

Can you change web hosting without losing email?

Yes, you can, but email is the most fragile part of the move. First, find out where your email actually lives. If your MX record points to a separate service such as Google Workspace or Microsoft 365, a hosting change does not touch your mail. The only condition is that the new DNS zone carries the same MX and verification records.

If your email lives on the old host, things change. In that case you copy the mailboxes to the new server and point the MX record there. However, an MX change also spreads gradually over the TTL period. During that window, some senders still deliver to the old server. So you should not close the old mailboxes right away.

A practical rule: for a few days after the MX change, also check the old mailboxes. You can connect to the old server over IMAP using the hostname or IP your old provider gave you. Then move any late messages into the new mailbox. Also note that users' incoming and outgoing server settings may change. We cover client settings in our business email guide. In short, moving email a day after the site is a reasonable option, so you do not carry two risks at once.

What should you check in SPF, DKIM, and PTR records?

After the move, emails such as contact form messages and order notifications leave from the new server. To keep them out of spam folders, you need to update your sender authentication records.

• SPF: The SPF policy in your TXT record must cover the new server's IP address. If it does not, receiving servers may treat those messages as suspicious.
• DKIM: The new server usually creates its own DKIM key. The DKIM record in DNS must match the key of the server that signs the mail.
• DMARC: The policy record usually stays the same. Still, watch the reports for failures from the new IP.
• PTR: Whoever owns the IP manages reverse DNS. If you moved to a VPS, you request it from your provider.

We explain why PTR matters in our PTR record guide. After the move, you can check all three sender records at once with our SPF, DKIM, and DMARC checker. Then send a test message to your own Gmail or Outlook address. Open the message headers and confirm that SPF and DKIM pass. That way you catch problems before customers complain.

How do you reinstall the SSL certificate on the new server?

An SSL certificate belongs to a server setup; it does not travel with your files by itself. If you use a free Let's Encrypt certificate, you need to issue it again on the new server. There is a timing detail here.

According to the Let's Encrypt documentation, the HTTP-01 challenge only works on port 80, and Let's Encrypt reads the challenge file through your domain. In other words, you cannot get a certificate this way until the domain points at the new server. That is also why automated systems such as cPanel's AutoSSL usually finish the certificate after the DNS change. The DNS-01 challenge works by adding a TXT record instead, and it can also issue wildcard certificates.

To reduce disruption, you have two options:

1. If you have a paid certificate, export the certificate, private key, and intermediate certificates from the old server. Then install them on the new server in advance.
2. If you use Let's Encrypt, trigger issuance right after the DNS change. Also schedule the switch for your lowest traffic hour, so any brief warning window affects few visitors.

Take extra care if your site uses HSTS, because browsers will not let visitors click past an invalid certificate. After setup, check the chain with our SSL checker. We cover certificate types in our SSL certificate guide.

How do you avoid losing orders on an ecommerce site?

On a brochure site, content rarely changes, so the backup and the live site stay in sync. On an ecommerce site, however, new orders, signups, and stock changes happen every minute. If you take the backup in the morning and switch DNS in the evening, the orders in between stay on the old server.

You solve this with a freeze window. A freeze window is a short period in which you pause all writes on the site. The order looks like this:

1. Pick your lowest traffic hour and tell customers in advance.
2. Put the site in maintenance mode and stop accepting orders and signups.
3. Take a final database dump and import it on the new server.
4. Sync any new files that users uploaded.
5. Switch DNS and turn off maintenance mode on the new server.
6. Keep maintenance mode on at the old server, so late visitors cannot place orders there.

The last step matters. While DNS propagates, a customer who still reaches the old IP could place an order that never reaches the new database. Also check the payment gateway's notification URL and IP allowlist. Run a test transaction from the new server for payment, shipping, and invoicing integrations. We help with these infrastructure decisions as part of our ecommerce consulting work.

What does cutover day look like, step by step?

Cutover day is not for planning; it is for following the plan. So we recommend writing the steps down in advance and checking them off in order. The sequence below assumes the earlier preparation is done.

1. Confirm with a DNS query that the TTL dropped at least a week ago.
2. Start the freeze window if the site handles live data.
3. Take the final database dump, import it, and compare row counts.
4. Test the new server one last time through your hosts file, then remove the hosts line.
5. Update the A and AAAA records or the nameservers.
6. Trigger the SSL certificate, or confirm the one you installed earlier.
7. If email is moving, update the MX, SPF, and DKIM records.
8. Test forms, checkout, and outgoing email on the real domain.

Write the time and result next to each step. Then, if a problem shows up, you see right away which step it followed. Also set a rollback threshold. For example, if checkout does not work within a set time, you switch the A record back to the old IP. Because the old server is still running and current, that rollback takes minutes. Put simply, a move without a rollback plan is only an optimistic guess.

How do you track DNS propagation?

DNS propagation is the gradual process in which resolvers around the world pick up the new record. It does not happen all at once; each resolver refreshes the old record when its TTL runs out. That is why you may see the new site while a visitor in another city still sees the old one.

On the command line, you can query records with dig:

dig +short example.com A
dig +short example.com MX
dig example.com NS

To ask a specific public resolver, add its address to the command with the @ sign. That way you get a result that does not depend on your own network's cache. If you prefer the browser, the DNS lookup tool we mentioned earlier shows the same records.

Google also recommends watching the server logs on both the old and new systems and using public DNS checkers. This method works well in practice. As traffic rises in the new server's access log, it falls in the old one. Still, some networks and corporate firewalls refresh records late. So keep watching both sides until traffic to the old server stops completely.

When should you cancel the old hosting plan?

Do not cancel the old plan on the day you switch DNS. When you change web hosting, early cancellation is one of the most expensive mistakes you can make. Google's guide also says to shut down the old infrastructure only when traffic to the old provider reaches zero.

Canceling early carries concrete risks:

• Visitors whose resolvers still hold the old IP see an error page.
• Late email that lands on the old server bounces or disappears.
• You cannot recover a cron job, file, or database table you forgot.
• You lose your quick rollback route if something goes wrong.

So align the end of your hosting contract with the migration plan. If you move too close to the renewal date, the provider may suspend the account in the middle of the switch. If possible, move a few weeks before renewal, so both accounts run in parallel for a few days. Before you cancel, download one last full backup from the old account and keep it for a while. Also, if your domain is registered with the old host, check the domain registration separately. That way, canceling hosting does not affect the domain renewal.

When should you let the hosting provider handle the move?

You do not have to do every migration yourself. In some cases the best choice is to hand the job to the new provider's support team. To be honest, for most small sites this route is both faster and safer.

We suggest leaving it to the provider in these cases:

• Both sides run cPanel and the new provider offers free migration.
• You have little experience with SSH, databases, or DNS.
• Your accounts hold many mailboxes and years of correspondence.
• You are moving to a managed hosting plan where you do not run the server yourself.

On the other hand, handing it over does not mean giving up all control. Prepare the inventory yourself, run the hosts file test yourself, and choose the DNS switch time yourself. For an ecommerce site in particular, plan the freeze window together with the provider. If you are still choosing a provider, we collected the criteria in our guide to choosing web hosting. If your current plan simply feels too small, upgrading with the same provider is another option; we cover that in a separate article.

Checklist to change web hosting: everything in one place

The list below gathers the steps from the earlier sections in one place. We suggest printing it and checking off each item as you go.

• Inventory: list domains, databases, email, cron jobs, PHP settings, and DNS records.
• IP allowlists: register the new IP with payment, invoicing, and API services.
• Backup: take files, database, and email, verify them, and download them off the server.
• Setup: prepare the site, database, and configuration file on the new account.
• Testing: try every key page and form through the hosts file.
• TTL: lower it at least a week before the move.
• DNS method: decide between a nameserver change and an A record change.
• Email: plan the MX, SPF, DKIM, and PTR updates.
• SSL: settle on the certificate method and timing.
• Freeze window: set the time and the customer notice for sites with live data.
• Rollback: note the old IP and your rollback threshold.
• Old hosting: keep it running until traffic reaches zero.

With this list, the decision to change web hosting stops being a gamble and becomes a measurable project.

What should you monitor in the first week after the move?

The DNS switch is not the end of the move. The first week is when hidden problems surface. So we recommend checking a few signals regularly.

First, look at the server's error log. A missing PHP extension or a permission problem usually shows up there. Next, confirm that cron jobs actually run; for example, does the automatic backup or newsletter task fire on the new server? Also send a test message to confirm outgoing mail still arrives.

On the search side, watch Search Console. Google notes that a temporary drop in Googlebot's crawl rate right after launch is normal, followed by a steady increase over the next few days. Also make sure your Search Console verification method, such as the HTML file or meta tag, still exists on the new server.

Finally, measure speed. Compare the new server against the measurements you took before the move, so you know whether it is really faster. If you want to rethink your site's technical foundation, we also handle infrastructure planning as part of our web design service.

In short: what makes a migration downtime free?

The core of a downtime free move is keeping your way back open until the very end. You take a backup, test the new server through your hosts file, lower the TTL a week ahead, and keep the old plan running until traffic stops. Those four habits prevent most problems before they appear.

Email and ecommerce need the most care. For email, you carry over the MX, SPF, and DKIM records in full. For ecommerce, a freeze window keeps the last orders from getting lost. And if you do not feel ready to change web hosting on your own, handing the job to the provider is a professional decision too, as long as you keep control of testing and timing.