Website Migration Checklist: Move a Domain and Hosting Without Downtime

Overview

A migration is safest when treated as a sequence of small, reversible changes rather than one large switch. Moving a website to a new host may involve files, databases, DNS records, email, scheduled jobs, SSL certificates, redirects, analytics, and deployment credentials. Transferring the domain registration is a separate operation and is not always required to change web hosting.

Start by deciding what is actually moving:

• Hosting only: The registrar and domain remain in place while the website is copied to a new server.
• DNS management: Nameservers or individual DNS records move to a different provider.
• Domain registration: The registration moves between registrars, usually using a transfer authorization code.
• Application platform: The operating system, web server, database, PHP or runtime version, CMS, or deployment process changes.

Keeping these decisions separate makes troubleshooting easier. For example, you can migrate the site to a new host while leaving DNS at the existing provider, then transfer the domain later after the website has been stable.

Before making changes, record the current configuration. Save a copy of the DNS zone, hosting settings, web-server configuration, database credentials, scheduled tasks, redirect rules, and certificate details. Confirm that you can access the registrar, DNS provider, existing host, new host, and email administration panel. Do not begin a cutover while relying on a single administrator account or an untested backup.

What to track

1. Site and application inventory

List every hostname that must continue working, including the apex domain, www, staging addresses, API subdomains, image hosts, and mail-related names. Record the document root, application version, database engine and version, uploads directory, environment variables, file permissions, cron jobs, webhooks, and third-party integrations.

Take a complete backup of files and databases, then verify that the backup can be opened or restored. A backup that has never been tested is not a reliable rollback plan. For a database-backed site, note whether the application can tolerate a short period of read-only operation while the final database copy is made.

2. DNS and email records

Export or manually document the DNS zone before editing it. Include A and AAAA records for web traffic, CNAME records, mail exchange records, and TXT records used for verification, email authentication, or DNS-based certificate validation. Also note delegated subdomains and any records managed outside the main DNS panel.

Email deserves its own migration plan. Preserve the existing MX records unless mail is intentionally moving. Check related hostnames and authentication records before changing nameservers. A site can appear healthy while mail delivery is failing, so test sending and receiving from more than one external mailbox after the cutover.

3. Destination compatibility

Compare the old and new environments before copying production data. Check the runtime version, required extensions, database character set, maximum upload size, process limits, filesystem behavior, server timezone, and URL rewriting support. Confirm that the new server can run the application without silently changing configuration.

Build the site on a temporary hostname or a hosts-file override. Keep the test address inaccessible to search engines where appropriate, and avoid sending real transactional email from a test environment. Test login flows, forms, payments, file uploads, background jobs, caching, and administrative functions before DNS changes.

4. HTTPS, redirects, and visibility

List every HTTP-to-HTTPS redirect, canonical URL, old path redirect, and rewrite rule. Preserve these rules at the new host rather than assuming a control panel will recreate them. Check both the apex and www hostname, as well as important subdomains.

The destination must serve a certificate covering every hostname users will visit. You can install a certificate before cutover if DNS validation or another supported validation method is available. Otherwise, plan the certificate issuance immediately after DNS points to the new server. The Let’s Encrypt setup guide covers common Certbot workflows for Nginx and Apache, while the certificate renewal guide explains how to make renewal part of the new deployment rather than a manual reminder.

Cadence and checkpoints

Use a written timeline with an owner for each checkpoint. The following sequence works for many small and medium website migrations:

1. Several days before: Audit the site, create and test backups, confirm access, document DNS and email, and build the destination environment.
2. Before the change window: Copy files and the database, install dependencies, configure the web server, create required users and scheduled tasks, and test the site on a temporary address.
3. One or two DNS TTL intervals before cutover: Lower the TTL for records you expect to change, if your provider permits it. A commonly used planning window is 24 to 48 hours, but resolver behavior varies, so do not treat TTL as a precise outage timer.
4. Immediately before cutover: Take a final backup. If content changes frequently, place the application in maintenance or read-only mode long enough to copy the final database changes. Confirm that the new server has current files and data.
5. At cutover: Change only the intended A, AAAA, or CNAME records, or update nameservers if DNS management is moving. Keep the old host available.
6. During propagation: Test from the new server directly and from multiple networks. Monitor both the old and new environments because different users may reach different destinations temporarily.
7. After stabilization: Re-enable normal caching and maintenance settings, raise TTL when appropriate, and retain the old host until traffic, logs, mail, and application behavior are consistently normal.

Do not combine a hosting move, domain transfer, nameserver change, CMS upgrade, and redesign in one cutover unless there is a compelling reason. Fewer simultaneous variables produce a clearer rollback decision.

Verification table

How to interpret changes

A temporary difference in DNS answers does not necessarily indicate a failed migration. During propagation, some resolvers may return the old address while others return the new one. Compare results using authoritative DNS queries, more than one public network, and direct requests to each server. A HTTPS troubleshooting checklist can help separate DNS, certificate, redirect, and server-configuration problems.

Classify failures by layer:

• DNS failure: The hostname returns no answer or points to an unintended address. Review the zone, nameserver delegation, and record spelling.
• TLS failure: The certificate does not cover the requested name, the certificate was not installed on the active server, or the renewal configuration is missing.
• Web-server failure: The server returns a 4xx or 5xx response, misroutes the hostname, or lacks rewrite and permission settings.
• Application failure: The site loads but database connections, sessions, uploads, queues, or integrations do not work.
• Email failure: MX, mail host, authentication, or firewall settings were omitted or changed unintentionally.

Define rollback criteria before the switch. Examples include sustained server errors, missing data, broken checkout or login flows, failed mail delivery, or an HTTPS failure affecting a required hostname. Rollback should mean restoring the previous DNS values and, if necessary, putting the old application back into service. Keep a timestamped record of every change so the team can reverse only what changed.

When to revisit

Review this migration checklist before every domain transfer, host replacement, server rebuild, major CMS upgrade, redesign, or emergency move. Revisit the technical inventory quarterly for active sites, even when no migration is planned. Hosting platforms, runtime versions, DNS providers, control panels, and certificate automation can change the steps required by the next move.

After a migration, schedule checkpoints rather than declaring success immediately:

• Same day: Check DNS answers, HTTPS, redirects, forms, logins, transactions, email, error logs, and scheduled jobs.
• Next business day: Review traffic, application errors, resource use, cache behavior, and important conversion paths.
• Within the first week: Confirm backups, certificate renewal automation, monitoring alerts, DNS documentation, and administrator access.
• Quarterly: Restore-test a backup, review DNS records and domain contacts, verify renewal ownership, and remove obsolete credentials or temporary records.

Finally, document the final architecture: registrar, DNS provider, host, nameservers, certificate method, renewal process, backup location, rollback procedure, and responsible accounts. That record turns the next migration from an emergency investigation into a repeatable deployment task. For certificate scope and DNS validation decisions, see the guides to wildcard certificates and DNS-01 validation.