A website migration does not need to cause downtime or an SEO setback. This reusable website migration checklist walks you through preparing the new host, copying files and databases, lowering DNS TTL, testing the replacement site, transferring a domain when needed, and verifying SEO, email, SSL, backups, and redirects after the cutover.
Overview
A migration usually involves three separate changes: moving the website’s files and database, directing DNS records to a new server, and optionally transferring the domain registration to a different registrar. Treating these as separate tasks makes the process easier to control. You can move hosting without transferring the domain, or transfer the domain while leaving hosting unchanged.
The safest approach is to build and test the new environment before changing DNS. The existing website remains live while the new copy is prepared. Once the replacement site passes testing, DNS is updated so visitors begin reaching the new host. Keep the old hosting account active until DNS propagation has completed and the new site has been checked from multiple networks.
For WordPress, make a complete backup of the database, uploads, themes, plugins, and configuration files. Record the current PHP version, WordPress version, active plugins, cron jobs, redirects, forms, analytics settings, and email-related DNS records. These details provide a comparison point if something behaves differently after migration.
If your project has strict availability requirements, schedule the cutover during a period of low activity. Put an order or content freeze in place shortly before the final copy so that new orders, comments, form submissions, or other database changes are not lost between the first backup and the DNS change.
What to track
Pre-migration checklist
- Confirm the new hosting plan supports the site’s software, database engine, storage needs, email requirements, and expected traffic.
- Check resource limits such as CPU, memory, storage, bandwidth, and inodes. See the web hosting resource limits guide for a structured way to review them.
- Record the domain registrar, nameservers, DNS records, domain expiration date, transfer lock status, and the account recovery details.
- Export a full backup and confirm that it can be opened or restored. Keep one copy outside the current hosting account.
- Document the current URLs, canonical tags, robots.txt file, XML sitemap, redirect rules, analytics tags, Search Console properties, and important landing pages.
- Record email records, including MX, SPF, DKIM, and DMARC entries. Do not replace DNS nameservers until you know which records must be recreated.
- Confirm access to the hosting control panel, database, SFTP or SSH, registrar account, DNS manager, and email administration tools.
Copy and test the new site
Copy the website to the new host using the method supported by the environment. In a typical WordPress migration, this means transferring the site files, creating a database and database user, importing the database, and updating the connection settings. Some managed WordPress hosts provide a migration tool; follow its current instructions but still perform the independent checks below.
- Create the new site or server and confirm its document root.
- Create a database and user, then import the latest database backup.
- Upload the files, including the
wp-content/uploadsdirectory and any custom configuration files. - Update the database connection details and temporarily configure the site for testing.
- Check the homepage, representative posts, images, search, forms, login, checkout, and any restricted content.
- Confirm that internal links, media URLs, permalinks, redirects, and canonical URLs still use the correct domain.
- Enable HTTPS on the new host and test both the secure and insecure versions before cutover.
Use a temporary hostname, hosts-file override, staging URL, or access-control method supplied by the host for testing. Avoid allowing search engines to index a duplicate staging site. A password, access restriction, or suitable noindex configuration can help while testing; remove temporary restrictions from the production site after launch.
DNS cutover checklist and timeline
DNS changes are controlled by record TTL values, resolver caching, and the records being changed. A practical preparation step is to lower the relevant DNS record TTL before the migration, often to a short value such as 300 seconds, and do so far enough in advance for the previous TTL to expire. The appropriate timing depends on the existing TTL and DNS provider. Lowering TTL does not instantly remove caches that were created under the former value.
| Time | Action | Checkpoint |
|---|---|---|
| Several days before | Audit DNS, backups, email records, redirects, and access credentials. | Every required record and recovery method is documented. |
| Before the final copy | Lower the TTL for the records that will change, if the DNS provider permits it. | Record the old TTL and the planned restoration value. |
| Migration day | Take a final backup or database export and freeze content if necessary. | The new copy includes the latest content and transactions. |
| Cutover | Update the A, AAAA, CNAME, or nameserver records required by the new host. | Only intended records change; MX and verification records remain intact. |
| After cutover | Test from several networks and monitor both hosts. | The new site serves correctly over HTTPS and no critical function is missing. |
| After stability is confirmed | Restore a sensible TTL and retain the old host until the agreed rollback period ends. | Backups, monitoring, and DNS documentation are current. |
Control-panel migration steps
| Environment | Migration workflow | Important checks |
|---|---|---|
| cPanel | Create the account or destination site, create the database and user, upload or restore the home directory, import the database, update configuration, and verify the domain’s document root. Recreate email accounts and DNS records if they are not included in the transfer. | Check PHP version, file permissions, cron jobs, SSL installation, redirects, and mailbox data. |
| Plesk | Create the subscription or domain, set the document root, create the database, upload files, import the database, update application settings, and test the site through the panel’s preview or staging function where available. | Review PHP handlers, scheduled tasks, DNS templates, mail service settings, and certificate coverage. |
| Managed WordPress host | Use the host’s migration tool or provide a files-and-database package, confirm the temporary URL, test plugins and caching, then request or perform the domain and DNS cutover according to the host’s workflow. | Disable conflicting caching, confirm staging restrictions are removed, and verify that automated backups and SSL are active. |
| Cloud or self-managed server | Provision the runtime, web server, database, storage, firewall rules, users, backups, and monitoring. Deploy the site through SFTP, SSH, version control, or an image-based process, then point DNS to the tested endpoint. | Check security groups, ports, web-server rules, database access, certificates, logging, scheduled jobs, and rollback steps. |
Control-panel labels and migration tools change over time, so use the destination provider’s current documentation for interface-specific instructions. The WordPress migration checklist provides a complementary application-level workflow.
Domain transfer checklist
A domain transfer is optional. Hosting can move while the domain remains at its current registrar. If you are transferring the domain, verify that the domain is eligible, unlock it where required, obtain the authorization code, confirm the registrant contact details, and ensure that the approval email or account notification can be accessed. Registry and registrar rules vary by domain extension and can change, so check the current instructions before starting.
Do not rely on a domain transfer to perform the hosting migration automatically. Keep DNS management available, copy all records to the intended DNS provider, and confirm that the domain continues resolving during the transfer process. Review the domain registrar comparison for broader considerations such as transfer tools, privacy options, and renewal pricing.
Cadence and checkpoints
Use a staged schedule rather than treating migration as a single event.
One to two weeks before
- Choose the destination environment and confirm its technical requirements.
- Inventory DNS, email, redirects, integrations, and scheduled jobs.
- Create and test backups.
- Build the site on the new host and begin functional testing.
- Document a rollback plan: the old server, old DNS values, backup location, and person responsible for each action.
Twenty-four to forty-eight hours before
- Lower relevant TTL values where appropriate.
- Complete a second test of the new site, including forms, payments, logins, and email notifications.
- Confirm SSL coverage for the root domain, www host, and any required subdomains.
- Tell collaborators when content changes must pause.
During cutover
- Take the final backup and record its time.
- Apply DNS changes carefully and save a copy of the previous records.
- Check the site using the new server directly where possible, then test the public domain from different connections.
- Watch error logs, server resources, form submissions, orders, and email delivery.
Within the first day
- Test important URLs with and without trailing slashes, query strings, and common redirect paths.
- Confirm the sitemap is reachable and that robots.txt is not blocking the live site.
- Inspect Search Console coverage or indexing reports for unexpected errors.
- Run performance and uptime checks from more than one location. Compare results with the old environment rather than judging from one test alone.
How to interpret changes
Some variation immediately after a migration is normal. DNS resolvers may still use cached records, monitoring systems may test different routes, and caches may be empty on the new server. Look for patterns across several checks instead of reacting to a single failed request.
A site that works for you but not for some visitors often indicates DNS, IPv6, CDN, firewall, or propagation differences. A site that loads but shows missing images or broken styling usually points to incorrect paths, file permissions, rewrite rules, or an incomplete file transfer. Database connection errors generally indicate incorrect credentials, database host settings, character-set problems, or an incomplete import.
For SEO, distinguish a temporary crawl fluctuation from a migration error. Confirm that important pages return the intended status code, canonical tags point to the correct URLs, redirects preserve changed paths, and the sitemap contains valid, indexable URLs. Do not change URLs during the hosting move unless there is a separate reason; keeping the URL structure stable reduces the number of variables.
For email, missing messages or authentication warnings usually require a DNS and mail-service review. Compare MX, SPF, DKIM, and DMARC records with the pre-migration inventory. If email is hosted separately from the website, its records should generally remain directed to that service. For certificate warnings, verify DNS resolution, certificate names, the server’s HTTPS configuration, and automatic renewal. The SSL troubleshooting checklist covers these checks in more detail.
When to revisit
Keep this checklist with the site’s technical documentation and revisit it at three practical points: before every hosting change, after any domain or DNS change, and during a monthly or quarterly maintenance review. A migration is also a useful trigger to confirm that backups restore correctly, renewal costs are understood, resource usage is within plan limits, and the site still has an appropriate hosting setup. For broader recurring work, use the monthly and quarterly hosting maintenance checklist.
Update provider-specific steps whenever a control panel, migration tool, default DNS setting, transfer workflow, or SSL automation process changes. Review the article at least quarterly if it is used as an operational reference, and sooner when a registrar, hosting provider, certificate authority, or domain registry changes its requirements. Before your next migration, print or copy the following final sign-off list:
- Backup restored or independently verified.
- New host tested without relying on public DNS alone.
- DNS records, email records, TTL values, and rollback values documented.
- SSL, redirects, forms, logins, payments, images, and scheduled tasks tested.
- Search Console, analytics, robots.txt, sitemap, canonical tags, and important URLs checked.
- Old hosting retained until the new site is stable and the rollback window has ended.
- Final DNS, hosting, domain, backup, and renewal details stored in the site’s maintenance record.
Following the same sequence each time makes a domain transfer or hosting move measurable and reversible. The goal is not to eliminate every transient DNS delay; it is to ensure that the site, email, search signals, and recovery options remain under control throughout the change.
