How to Move a Website to a New Host Without Downtime

Web Hosting June 17, 2025

Changing web hosts is a normal part of running a website. You may be moving because your site has outgrown its current plan, you need different features, you want better control, or you simply found a hosting environment that fits your requirements better.

The part that makes a migration stressful is the possibility of downtime. The good news is that most website moves can be performed with little or no visible interruption if the new account is built and tested before DNS is changed.

Global network connections — A planned migration separates server preparation from the final DNS cutover.

The Basic Migration Strategy

The safest general sequence is simple: build the new environment, copy the site, restore the database, test the new server, synchronize any changes, and only then change DNS.

Phase	What happens	Website status
Inventory	Document files, databases, email, DNS, SSL, cron jobs, and versions	Old site remains live
Build	Create the new hosting account and application environment	Old site remains live
Initial copy	Transfer files and database	Old site remains live
Testing	Test the site on the new server	Old site remains live
Final sync	Copy changes made since the first transfer	Old site remains live
DNS cutover	Point traffic to the new server	Transition

Inventory the Existing Account First

Do not start by copying the public_html directory and assuming you are finished. Make an inventory of everything the site actually uses.

Website files and document roots
Database names, users, and versions
PHP version and enabled extensions
Cron jobs and scheduled tasks
SSL certificates and HTTPS configuration
DNS records
Email accounts, aliases, and forwarding rules
Application-generated uploads and storage outside the document root
Environment files and application secrets

This inventory often exposes the hidden dependencies that cause migration failures.

Build the Destination Before the Cutover

Create the new hosting account and configure the domain before changing public DNS. Set the PHP version, create the database, create the database user, configure the document root, and make sure required PHP extensions are available.

If you are moving WordPress, install the required PHP version and database support first. If you are moving a custom PHP application, check its required modules and configuration files before transferring production traffic.

Transfer the Files

Use a reliable transfer method such as SFTP, SCP, rsync, or a provider’s migration tool. Avoid manually dragging thousands of files through a browser interface when a direct transfer method is available.

After the transfer, compare file counts and investigate obvious differences. Permissions may also need to be adjusted because the destination server can use different user and group IDs.

rsync -avz --progress /source/site/ user@new-server:/destination/site/

The exact command depends on your environment. Treat the example as a concept rather than a command to paste blindly.

Move the Database

For a database-driven application, the database is just as important as the files. A WordPress site with every PHP file intact but an old or missing database is not a complete migration.

A common approach is to export the source database, create the destination database, and import the dump.

mysqldump -u USER -p DATABASE > site.sql
mysql -u USER -p DATABASE < site.sql

Update the application’s database credentials only after confirming the destination database and user exist.

Test Before Changing DNS

This is the step that prevents most avoidable downtime. You need to view the site from the new server while the public domain still points to the old one.

Depending on your environment, you can use a temporary hostname, a hosts-file override, a staging URL, or another controlled testing method. Test the homepage, important internal pages, forms, logins, uploads, images, redirects, and any ecommerce functions.

Do Not Forget Email

Website migrations frequently become email outages because administrators focus exclusively on web traffic. If the domain’s MX records already point to a separate mail provider, changing web hosting may not require any email changes at all. If email is hosted on the old server, however, you need to plan that migration separately.

Before changing nameservers, record every important mail-related DNS entry, including MX, SPF, DKIM, and DMARC records.

SSL Certificates

Do not assume the certificate on the old server moves with the website files. Certificates and private keys may be managed separately, and many hosting environments can issue a new certificate automatically once the domain points to the new server.

Make HTTPS part of your pre-cutover test. Check both the certificate and the actual application behavior over HTTPS.

Lower DNS TTL Before the Move

If you control the DNS zone, lowering the TTL before a planned migration can reduce the period during which some resolvers retain the old address. It does not eliminate DNS caching completely, and it does not make every visitor switch simultaneously.

Perform the Final Synchronization

If the website is receiving changes during migration, your initial copy will become stale. A busy WordPress site may receive comments, orders, form submissions, or uploads after the first database export.

Before the final DNS change, perform a final file and database synchronization. For high-write applications, you may temporarily put the application into maintenance mode or otherwise stop writes during the final database transfer.

Migration Checklist

Record the existing hosting and DNS configuration.
Build the new hosting account.
Configure PHP, database, SSL, cron jobs, and application dependencies.
Transfer website files.
Export and import the database.
Test the site on the new server.
Verify email and DNS records.
Perform a final synchronization.
Change DNS.
Monitor both servers during the transition.

Final Thoughts

A website migration becomes much easier when the DNS cutover is treated as the final step rather than the first step. Build and test the destination while the old site is still serving visitors, then synchronize the last changes and switch traffic deliberately.

GaugeHosting provides hosting environments designed to give website owners practical control over domains, files, databases, email, and hosting configuration. Learn more at GaugeHosting.

Test the Application, Not Just the Homepage

A migration can appear successful because the homepage loads while important functions remain broken. Test contact forms, authentication, password resets, search, uploads, image processing, redirects, APIs, ecommerce checkout, and any scheduled background jobs the application depends on.

For WordPress, check the administration area, media library, permalinks, plugins that communicate with outside services, and scheduled tasks. If the site sends email, verify that mail delivery still works after the move.

Watch the Old Server After Cutover

Do not immediately cancel the old hosting account. DNS caching means some visitors can continue reaching the old server for a period of time. Monitoring the old environment can reveal requests that are still arriving and can expose overlooked services or hostnames.

Keep the old account available until you are satisfied that traffic has moved and the new server is stable. Then take a final backup before decommissioning the old environment.

When Zero Downtime Is Not Realistic

Some applications cannot be migrated without a controlled write freeze. High-volume databases, systems with continuous transactions, and applications with files being modified constantly may require replication or a brief maintenance window.

The goal should be to minimize disruption while protecting data integrity. A few minutes of planned maintenance is preferable to silently losing orders or database changes.