How to Migrate Your Website to a New Host Without Downtime

A safe hosting move is a staged handover

You can move a website to a new hosting provider without changing its domain name or public URLs. The safe sequence is to build a working copy on the new server, test it privately, prepare email and DNS, switch traffic, then keep both hosting accounts running until the new setup is proven.

Do not start by cancelling the old account or changing nameservers. That removes your easiest rollback path before you know whether the files, database, forms, email and SSL certificate work at the destination.

If you are still choosing the destination, compare the new plan's storage, runtime, mailbox and support limits on the Allanux web hosting page before moving any data. A migration cannot fix a plan that is too small or incompatible with the site.

Before the move: build a migration inventory

Write down who controls the domain, DNS, hosting, website application, email and analytics. For a small business, those logins are often split between an owner, former developer and hosting provider. Resolve missing access before setting a date.

Record the current PHP version, database engine, storage used, mailbox count, DNS zone, SSL setup, scheduled tasks and any CDN or firewall service. Note integrations that receive traffic from outside the site, including payment callbacks, booking systems, SMTP services and webhooks.

Check that the new hosting plan supports the same application requirements. A WordPress copy can still fail if the PHP version, extensions, database credentials, file permissions or memory limits differ. An ecommerce site also needs enough time to test checkout, order emails and stock changes without losing live transactions.

Make a backup you can restore yourself

Take a complete copy of the website files and database. If email is part of the move, record every mailbox, alias, forwarder and routing rule, then confirm how existing messages will be copied. Keep the backup somewhere outside both hosting accounts.

A provider snapshot is useful, but it is not a substitute for a portable copy when the reason for moving is poor support, an account dispute or unreliable access. Use the website security checklist to confirm ownership and recovery access before handing credentials to anyone.

Copy the site before you touch DNS

Create the domain or subscription at the new host, install the required runtime and copy the files and database. For WordPress, that may be a provider migration tool, a control-panel transfer, a migration plugin or a manual file-and-database move. If database names or users change, update the application's configuration rather than assuming the old credentials will work.

Recreate SSL, cron jobs, redirects and server rules at the destination. Check whether the CDN, firewall or payment provider allows traffic only from the old server IP address. Those allowlists and callbacks can break even when the website itself looks normal.

Test the destination privately

Use the new host's preview method, a temporary hostname or a local hosts-file entry so your computer loads the destination while public visitors still reach the old server. Keep temporary test pages out of search results.

Test more than the home page:

• open representative pages, images and downloads;
• submit every important contact, quote and booking form;
• sign in to the CMS and save a low-risk change;
• check search, redirects, 404 handling and HTTPS;
• test checkout in the platform's safe test mode where available;
• confirm analytics and consent scripts load; and
• review application and server logs for errors.

Do not approve cutover while a critical function is “probably fine.” Record who tested it and what passed.

Move email as its own workstream

Changing website hosting does not automatically mean the mailboxes must move. Read the current MX records first. If they point to Microsoft 365, Google Workspace or another external service, preserve that routing when you update the website records.

If mail is moving, create every destination mailbox, alias and forwarder before changing MX records. Copy existing messages through the supported control-panel or IMAP migration method, test sending and receiving, then plan a final sync after cutover. Keep both mail services available while cached DNS answers expire because some senders may still reach the old server.

If DNS hosting or nameservers are also changing, copy the complete DNS zone rather than only the website's A record. MX and TXT records may carry mail routing, SPF, DKIM, DMARC and third-party verification. If you need a separate mail platform, compare the mailbox and support options on the Allanux email hosting page before changing those records.

Cut over DNS only after the new copy passes

Make the lowest-risk DNS change your setup allows. That may mean updating the website's A and AAAA records while leaving external email untouched, or changing nameservers after an identical zone has been created at the new DNS provider. Do not improvise with a partial zone during the move.

If you control the DNS TTL, plan the reduction in advance rather than at the moment of cutover. Cached answers do not disappear instantly, so traffic can reach both servers for a period. Avoid publishing major content changes or processing conflicting database writes on both copies during that window.

Know the rollback trigger

Point traffic back to the old environment if the destination cannot serve critical pages, complete transactions, receive essential mail or run safely. A rollback is not a failure; it is why the old account stayed active.

After the switch, watch public DNS results, uptime checks, server logs, forms, checkout, mail delivery, analytics and Search Console. Keep the old site reachable until traffic has moved and any final data or mailbox sync is complete.