A website migration involves more than copying files to a new server. This checklist helps you track domains, DNS, email, databases, redirects, SSL, performance, backups, and uptime before, during, and after a move—so you can reduce avoidable disruption and maintain a clear rollback path.
Overview
Website migrations vary in scope. You might move from one web hosting provider to another, change the underlying cloud infrastructure, replace a content management system, alter a domain, or combine several changes at once. Each additional change increases the number of dependencies that need to be checked.
The safest approach is to separate the migration into controlled stages:
- Discover: document the current website, domain, DNS, email, hosting, integrations, and security settings.
- Prepare: build the destination environment, create backups, lower DNS TTL where appropriate, and test the new site privately.
- Transfer: copy files and databases, synchronize recent changes, and update DNS or domain settings at a planned time.
- Validate: test pages, forms, authentication, email, redirects, SSL, performance, and monitoring.
- Stabilize: keep the old environment available for a defined period, review logs and alerts, and close the migration only after checks remain healthy.
Do not treat a domain transfer as the same thing as a hosting migration. A registrar transfer changes where the domain is managed; it does not automatically move website files, databases, DNS records, mailboxes, or SSL configuration. Similarly, changing nameservers can affect email and other services if the complete DNS zone has not been recreated at the new provider.
Before beginning, record the current setup in a simple migration document. Include the registrar, nameservers, DNS records, hosting addresses, database details, scheduled jobs, third-party integrations, email provider, SSL method, analytics, redirect rules, and administrator contacts. This inventory becomes both a runbook and a rollback reference.
What to track
Domain and DNS
Confirm the domain is not close to expiration and that you can access the registrar and DNS provider. If you plan a domain transfer, check the transfer requirements in advance and avoid combining the transfer with unrelated DNS changes unless there is a clear reason.
Export or record every relevant DNS entry, including A and AAAA records, CNAMEs, MX records, TXT verification records, and any service-specific entries. Pay particular attention to SPF, DKIM, and DMARC records if the domain sends business email. A website may appear healthy while email delivery is failing because one mail record was omitted.
Use a DNS propagation checker as one input, not as the only validation method. Query the records from more than one network or resolver, and confirm that the returned address matches the intended destination. DNS caching means different users may see old and new values during the transition.
Files, databases, and application behavior
Compare the source and destination file counts or checksums where practical. For database-driven sites, verify that the database dump completed successfully, the destination user has the required permissions, and the application is using the intended database and environment variables.
Test the site on a staging URL or temporary host before changing public DNS. Review the homepage, key landing pages, search, login, checkout or enquiry forms, uploads, scheduled tasks, API connections, and any pages that depend on rewrite rules. For WordPress cloud hosting or another content management system, check plugin and theme compatibility, media paths, cron jobs, and administrator access.
URLs, redirects, and search visibility
Make a list of important URLs before the move. If the URL structure changes, create a one-to-one redirect map from old paths to their closest relevant new destinations. Avoid sending every old URL to the homepage; that can confuse users and make troubleshooting harder.
After launch, test representative old URLs, canonical tags, robots directives, XML sitemaps, pagination where applicable, and internal links. Preserve the existing structure when there is no strong reason to change it. A hosting migration is usually easier to diagnose when URL changes are not introduced at the same time.
Email and SSL
Document all mailboxes, aliases, forwarding rules, autoresponders, shared addresses, and mobile or desktop clients. If email is moving as well, plan mailbox creation and message copying separately from the website transfer. The guide on moving email during a domain or hosting change can be used as a companion checklist.
Confirm that the destination supports the required hostname and that the SSL certificate for the website covers every public domain and subdomain. Test both HTTP and HTTPS behavior, certificate validity, mixed-content warnings, secure cookies, and redirects. Do not remove the old certificate or hosting configuration until the new endpoint has been verified.
Cadence and checkpoints
A migration should have explicit checkpoints rather than a single launch moment. Use the following schedule as a reusable baseline.
One to two weeks before
- Confirm ownership and administrative access for the registrar, DNS provider, hosting accounts, email platform, and application.
- Create and test restorable backups of files, databases, configuration, and mail where relevant. A backup that has never been restored is only an assumption; review website backup strategy principles before proceeding.
- Record baseline measurements: key page response times, error rates, uptime, traffic patterns, and important conversion actions.
- Build the destination environment and restrict access while it is being tested.
- List the migration owner, approver, implementation window, validation tasks, and rollback decision-maker.
One to three days before
- Review the DNS zone and recreate records at the destination provider if nameservers will change.
- Reduce DNS TTL only if it supports the planned change and your provider allows it; remember that existing caches may not honor the new value immediately.
- Freeze nonessential content and code changes, or define a final synchronization process.
- Run a complete staging test using realistic data and the production configuration where safe.
During the change
- Take a final backup and record its timestamp.
- Synchronize files and databases, then verify that the application can read and write correctly.
- Apply DNS, nameserver, or domain changes according to the runbook.
- Keep the previous environment available and avoid making unrelated changes.
Immediately after
Check the site from multiple networks and devices. Test the homepage, several deep links, forms, login flows, transactions or lead paths, images, downloads, APIs, and administrative functions. Confirm the intended IP address, SSL certificate, redirects, response headers, and canonical host. Send and receive test messages through each important email path.
Enable or confirm website uptime monitoring from outside the hosting network. Monitor not only availability but also elevated error responses, slow pages, certificate warnings, DNS changes, and failed transactions where your tooling supports them. For a broader monitoring workflow, see website uptime monitoring options for small teams.
How to interpret changes
Not every difference after a migration indicates a failure. DNS records can appear inconsistent for a period because resolvers and local devices cache answers. Temporary variations should be judged against the expected TTL and the actual change plan.
Separate infrastructure symptoms from application symptoms. If the site resolves to the wrong address, investigate DNS. If it resolves correctly but returns server errors, inspect application logs, runtime versions, permissions, database connections, and environment variables. If pages load but forms or payments fail, check third-party credentials, callback URLs, firewall rules, and scheduled tasks.
Compare post-migration measurements with the baseline rather than relying on a single speed test. A slower result on one test device may be local or temporary; a sustained increase in response time across several locations is more meaningful. Review cache configuration, database performance, image delivery, compression, and the selected hosting resources before making changes. The cloud-hosted website speed checklist provides a useful follow-up sequence.
Set a clear rollback threshold. Examples include persistent downtime, loss of critical data, broken payment or enquiry flows, widespread email failure, or an unresolvable security issue. Rollback should mean restoring the known-good DNS or hosting path and preserving logs and data needed for diagnosis. It should not mean deleting the new environment before the cause is understood.
When to revisit
Review the migration checklist at least monthly during the first period after a move, then quarterly as part of normal domain and hosting maintenance. Revisit it sooner when the following events occur:
- The domain, nameservers, registrar, DNS provider, or email provider changes.
- The website moves between shared, VPS, or cloud hosting, or its resources are resized.
- The content management system, runtime, database, theme, plugins, or deployment process changes.
- A certificate, DNS record, mail authentication record, firewall rule, or third-party integration is renewed or replaced.
- Monitoring reports repeated downtime, slower responses, unusual errors, failed forms, or certificate warnings.
- A backup, restore test, incident, security review, or staff handover exposes missing documentation.
On each review, confirm that the inventory is current, backups can be restored, administrator access still works, DNS and email records are documented, SSL renewals are visible, redirects remain valid, and monitoring alerts reach the right people. Remove obsolete access and stale records only after checking that no active service depends on them.
The practical next step is to copy this checklist into a migration runbook, assign an owner to every task, record baseline results, and schedule a post-launch review. Treat migration as a monitored process rather than a one-time switch. That habit makes future domain transfers, hosting changes, and infrastructure upgrades easier to test, explain, and reverse.
