Website Migration Checklist: Move Hosting With Minimal Downtime

Moving a website to a new hosting provider can improve performance, capacity, or support, but the transfer should be treated as a controlled project. A rushed migration can produce missing files, database inconsistencies, broken email, certificate warnings, or extended downtime. This website migration checklist focuses on the steps that reduce those risks.

Audit the current website

Start by documenting what must move. List the website files, databases, scheduled tasks, email accounts, DNS records, redirects, SSL certificates, subdomains, and any external integrations. Record the current software versions and server requirements so that the destination environment can support the application.

If you are still comparing infrastructure, our guide to choosing the right web hosting plan explains the differences between shared hosting, VPS resources, management, and scalability.

Create a verified backup

Back up both the application files and the complete database before changing anything. A backup is useful only if it can be restored, so inspect the archive, verify the database export, and keep a copy outside both the old and new servers. For a dynamic website, plan how you will handle new orders, comments, form submissions, or account changes made during the final transfer.

Record the backup time, archive size, and database table count. These simple reference points make it easier to spot an incomplete copy before the destination is placed into production.

Prepare and test the destination

Configure the new server before directing visitors to it. Restore the files and database, update credentials where necessary, and check permissions, rewrite rules, PHP modules, background jobs, and outbound email. Test the site through a temporary hostname or a local hosts-file entry so that the public domain continues using the old server.

Review pages, images, logins, forms, search, checkout flows, and administration functions. Confirm that HTTPS works with the correct certificate and that no asset still depends on an old hostname or server path.

Plan the DNS change

Lower the TTL of the relevant DNS records well before the migration, then wait for the previous longer TTL to expire. This does not eliminate caching, but it can shorten the period in which visitors reach different servers. Our detailed guide to DNS TTL and propagation explains why changing the TTL at the last minute is ineffective.

During cutover, make the final content or database synchronization, update the DNS records, and leave the old hosting active. Avoid deleting the original site immediately because some resolvers and visitors may continue reaching it until cached records expire.

Monitor after launch

Check the website from more than one network and watch application, web server, and database logs for errors. Test email delivery, redirects, certificate validity, and important transactions. The checks in our website monitoring guide can help detect failures that a basic homepage request may miss.

Keep the old environment available until traffic has settled and the new server has passed a full operational review. Afterward, raise DNS TTL values to their normal level, remove temporary access methods, update backups and monitoring, and securely retire old credentials and data.

For platform-specific guidance on files, databases, URLs, configuration, and server changes, consult the official WordPress migration documentation.