Website Migration Checklist: Move Hosts Without Losing Pages, Media, or Your Rollback Path

Moving a website is not a file-copying task. A working migration needs the files, database, configuration, URLs, media, and traffic switch to agree with one another.

Before accepting a host's migration promise, use the backup, migration, and support evaluation guide to define the written scope, exclusions, access requirements, and validation owner.

This checklist is designed for a small WordPress site or a lightweight web application. It does not promise zero downtime. Its purpose is to make failures visible before users are affected and to preserve a way back if the destination is not ready.

The principle: validate a destination before moving traffic

The safe sequence is:

inventory → backup → restore to a separate destination → validate → switch traffic → monitor → keep rollback available

Do not change DNS first and hope the destination works. Build and verify the destination through a temporary address, staging URL, hosts-file override, or equivalent non-production route before the public switch.

1. Make an inventory before touching the old host

Record the facts that a future-you will need during an incident:

• registrar and DNS provider;
• current hosting account and server type;
• application and runtime versions;
• database engine and version;
• domains, subdomains, redirects, and canonical URL;
• TLS certificates and renewal method;
• email provider, mailboxes, sending service, and DNS records;
• scheduled jobs, queues, webhooks, cron tasks, and third-party integrations;
• CDN, cache, firewall, and monitoring configuration;
• backup location, retention period, and restoration procedure.

For WordPress, also record the active theme, plugins, PHP version, permalink structure, upload path, and any custom configuration. A host label is not enough: WordPress itself recommends verifying the PHP, database, and HTTPS environment that a host actually provides. See the current WordPress requirements. ↗

Put legacy PHP behind a compatibility gate

Do not discover during cutover that the source runs a PHP version the destination will not provide. Record the exact source PHP version, required extensions and configuration, then confirm the destination's supported versions in current documentation or a test environment.

Choose and document one path before migration:

1. Preserve the runtime temporarily: use a supported destination environment that can reproduce the required PHP behavior while you plan a separate application upgrade.
2. Upgrade before migration: update PHP on a non-production copy of the source, then test WordPress core, the active theme, every required plugin, scheduled jobs, forms, admin actions, and error logs before moving hosts.

Do not combine a PHP upgrade and host migration into one untested change. If they must happen in the same maintenance window, preserve a restorable source, define which PHP or application errors trigger rollback, and assign an owner who can make that decision. WordPress warns that legacy runtime versions can be insecure even when the application still runs, so “it loads” is not a sufficient long-term compatibility decision. Check the current WordPress requirements and legacy-version warning. ↗

2. Create backups you can identify and restore

Take separate backups of:

1. application files;
2. database data;
3. configuration and environment settings; and
4. any user-uploaded media stored outside the normal application directory.

Label each backup with a date and origin. Record a checksum for each archive or export. A backup that cannot be located, identified, or read is not yet a reliable recovery option.

In our local WordPress rehearsal, we created separate file and database backups and recorded SHA-256 values before restoring them to a different local database. That exercise caught a URL issue that a simple file-count check would have missed.

For a database-and-media migration, record more than archive sizes:

• database table counts and representative row counts;
• the export time and the last accepted content-write time;
• upload and media file counts, total size, and checksums for representative large and recent files;
• any media stored outside the normal uploads directory or in object storage; and
• whether the file backup and database export represent one consistent recovery point.

After restoration, compare those records and sample recent posts, images, downloads, thumbnails, and administrator uploads. A matching file count does not prove that URLs, permissions, metadata, or serialized database values are correct.

3. Restore into a separate destination

Do not overwrite the source while testing the move. Create a distinct destination environment with:

• its own database;
• a separate filesystem or server account;
• a temporary access route;
• a clear destination-specific configuration; and
• no production credentials unless they are required and explicitly reviewed.

For a self-managed VPS, do not assume that the provider will perform this work. Some VPS products are self-managed, which can make the user responsible for operating system updates, application installation, DNS, SSL, mail, and migration work. Hostinger describes that boundary for its VPS product. ↗

4. Update the destination carefully

Copying a database does not automatically make it correct for a new address.

At minimum, review:

• the application’s base URL and site URL;
• absolute links embedded in posts, pages, templates, or configuration;
• redirect rules;
• callback URLs and webhooks;
• image, file, and upload URLs;
• cache, CDN, and proxy settings; and
• provider-specific configuration values.

Treat caches as part of the cutover plan. Identify every cache layer—WordPress/plugin cache, page cache, object cache, reverse proxy, CDN, and browser cache—and record who can purge or bypass it. Before changing DNS, verify the destination with caches bypassed where possible. After the switch, purge only the reviewed layers, then confirm that public requests no longer serve stale source URLs, redirects, assets, or application data.

Treat URL replacement as a data change

WordPress and many other systems can store values in serialized or structured formats. A blind global database replacement can corrupt that data. Use a reviewed, serialization-aware migration tool where appropriate; make a backup first; and document what changed.

Our local rehearsal showed why this matters. The destination database restored correctly and the article loaded, but one internal link still pointed to the source address. We corrected the known test URL only in the destination fixture, then confirmed that the source URL no longer appeared in the page output. That is evidence for a checklist item—not a claim that every site can be repaired with a simple text replacement.

5. Verify the destination before changing DNS

Run a written checklist on the destination. At a minimum, test:

The local rehearsal covered home pages, posts, pretty permalinks, internal links, database counts, a test media file, and a simulated rollback. It did not cover production DNS, TLS, email, CDN, forms, payments, plugins, or real users. Your own checklist must cover the components your site actually uses.

6. Plan the traffic switch and the rollback

Choose a low-traffic window where possible. A provider’s migration guidance may recommend allowing time for DNS propagation, but actual behavior depends on TTL, DNS provider, resolver caches, and your architecture. Hostinger’s VPS migration guidance recommends planning for a low-traffic period and allowing time for DNS propagation. ↗

Before changing traffic, write down:

• who makes the DNS or proxy change;
• the exact records to change;
• when the source can be shut down (usually not immediately);
• the tests that define “destination healthy”; and
• the trigger and steps for rollback.

If email shares the domain, preserve and review the complete mail path before the DNS change: MX, SPF, DKIM, DMARC, mailbox/alias/forwarding rules, SMTP credentials, sending-service verification, and any application mail configuration. A website migration is not accepted while forms or transactional mail silently use the wrong server. Test send and receive behavior with independent accounts before and after cutover.

For DNS, record the current zone and nameserver state, the intended changes, current TTLs, and the time each change is made. Do not promise instant propagation or zero downtime. Verify the destination directly before the switch, then resolve the production hostname from more than one independent resolver or network after the change.

Keep the source available until the destination is verified under real traffic conditions. In the local rehearsal, stopping the destination and returning to the source restored the tested article successfully. A real rollback needs equivalent planning for DNS, data writes, email, and any external services.

Prove that rollback is executable

“We can change DNS back” is not a complete rollback test. Before cutover:

• confirm the source still starts and serves a known test page;
• keep the pre-migration files, database, configuration, and DNS record values available to the rollback owner;
• define how writes made after the switch will be frozen, copied back, or deliberately discarded;
• rehearse the traffic return using a hosts-file, proxy, load-balancer, or other non-public routing method where practical; and
• write objective rollback triggers, such as failed login, missing media, database errors, broken email, or an acceptance-check deadline.

After any rollback, repeat the same page, login, media, form/email, DNS, and database checks used to accept the destination. Traffic returning to an HTTP 200 home page does not by itself prove that the original service is safe to resume.

7. Monitor after the switch

For at least the first day, inspect:

• HTTP error rates and server/application logs;
• key page response status;
• form and transactional email delivery;
• login and account flows;
• background tasks and webhooks;
• media and static asset loading;
• database and disk usage; and
• backup job completion.

Do not take “the home page loads” as the whole acceptance test.

Common migration mistakes

• Changing DNS before a destination is independently tested.
• Backing up only files or only the database.
• Forgetting uploads, email, scheduled tasks, or external callbacks.
• Leaving absolute source URLs inside content or configuration.
• Using a blind search-and-replace that damages serialized data.
• Shutting down the source before there is a tested rollback path.
• Treating a successful staging test as proof that production mail, TLS, CDN, or payment flows will work.

Before the final traffic switch, work through the printable WordPress Pre-launch Checklist for HTTPS, search controls, email, access, monitoring, DNS, and launch ownership.

A concise handover record

At the end of the migration, preserve a short record with:

• source and destination environments;
• backup locations and checksums;
• migration start and end times;
• tests run and results;
• issues found and how they were fixed;
• DNS/proxy changes made;
• rollback plan and the date the source can be retired.

That record is more useful than a vague “migration completed” message when you need to troubleshoot later.