A website launch or migration is easier to manage when it is treated as a repeatable operating process rather than a one-time event. This checklist covers the items worth tracking before, during, and after a change: domain registration, DNS, hosting, SSL, business email, redirects, backups, monitoring, and search visibility. Use it for a new site, a WordPress move, a hosting change, or a domain transfer, then return to it on a monthly or quarterly schedule.
Overview
A successful launch has two goals: visitors should reach the correct site, and the site should remain usable, secure, discoverable, and maintainable after the launch window. Migration work often fails at the boundaries between systems. The files may be copied correctly while DNS still points to the old server, SSL may cover one hostname but not another, or email records may be lost during a nameserver change.
Start by recording the current state. Create a short inventory of the domain name, registrar, DNS provider, hosting account, server address, SSL configuration, email provider, analytics, search tools, backup locations, and third-party services. Include the people or accounts that can access each system. This inventory becomes the baseline for troubleshooting and future reviews.
For a new site, confirm whether you are buying domain and hosting together or managing them separately. Separate services can be perfectly practical, but ownership, renewal dates, and support contacts should be documented. If you are evaluating a domain name and hosting plan for a small business, choose based on the site's requirements rather than on the convenience of a bundled checkout.
What to track
1. Domain and DNS ownership
Verify that the domain is active, the registration contact information is current, and domain privacy protection is configured according to your needs. Record the renewal date and enable available account security controls. If a domain transfer is in progress, confirm that the transfer status, authorization details, and registrar lock state are understood before changing other infrastructure.
Record the authoritative nameservers and export or document the important DNS records before making changes. At minimum, check the records for the website, the www hostname, email delivery, email authentication, verification services, and any subdomains used by applications or developers. A practical guide to pointing a domain to hosting can help when the website and DNS provider are separate.
2. Hosting and application health
Confirm that the new hosting environment supports the site's runtime, database, storage, scheduled tasks, and required extensions. For WordPress, check the PHP version, database connection, file permissions, cron behavior, media uploads, plugins, themes, and administrative login. For a custom application, verify environment variables, build steps, background workers, queues, and deployment credentials.
Before switching traffic, test the site on a staging URL or temporary host. Check representative pages, forms, search, navigation, images, downloadable files, account flows, and any payment or booking path. A staging workflow is particularly useful for WordPress changes; see the guide to setting up a WordPress staging site before pushing changes live.
3. SSL and canonical hostnames
Confirm that the SSL certificate covers every hostname visitors may use, such as the bare domain and www version. Test both HTTP and HTTPS behavior, including the redirect from HTTP to HTTPS. Check for mixed content, where a secure page still requests an image, script, font, or stylesheet over an insecure URL.
Choose one preferred hostname and redirect the other consistently. Also verify canonical tags, internal links, sitemap URLs, and structured data so they use the preferred protocol and hostname. An SSL certificate is only one part of website security; correct redirects and consistent URLs prevent avoidable trust and indexing problems.
4. Business email and DNS authentication
Send and receive test messages using each important business address. Test from an external account, reply to a message, and check delivery to more than one provider if possible. Verify that the MX records point to the intended email service and that existing mailboxes, aliases, forwarding rules, signatures, and shared addresses are present.
Review the email provider's required TXT records, including SPF, DKIM, and any DMARC policy you have configured. Do not copy records blindly from an old setup: confirm which service is authorized to send mail and avoid creating conflicting SPF records. Keep a record of the intended configuration so a future DNS change does not interrupt business email hosting.
5. Backups, redirects, and search visibility
Take a final backup of the old site, database, uploads, configuration, and DNS documentation before migration. Confirm that the backup can be opened or restored, rather than assuming that a successful backup job proves recoverability. Keep the old environment available for an agreed rollback period if the hosting arrangement allows it.
Build a redirect map for every important URL that changes. Redirect old pages to their closest relevant replacements, not automatically to the homepage. Check for redirect chains, loops, broken links, and missing status codes. Review the site's robots.txt and XML sitemap, then submit or validate the sitemap in the relevant search platform after launch.
Cadence and checkpoints
Use different checks at different stages so the launch is not overloaded with last-minute decisions.
- Two to four weeks before: inventory systems, confirm ownership, review renewal dates, lower DNS TTL only if it supports a planned change, prepare the redirect map, and establish a rollback plan.
- Several days before: complete a full backup, test the staging site, confirm application dependencies, verify email records, and make sure the SSL certificate can be issued or installed on the destination.
- Immediately before the switch: freeze content changes where appropriate, take a final database backup, compare DNS records, confirm the destination is ready, and record the exact time of the change.
- During the switch: update only the required DNS records, monitor resolution from more than one network, and avoid unrelated configuration changes. Use a DNS propagation checker as an observation tool, while remembering that different resolvers may update at different times.
- Within the first day: test the preferred and alternate hostnames, HTTPS, forms, logins, email, redirects, analytics, search access, and key conversion paths. Review server logs and error monitoring for unexpected failures.
- After one week: compare traffic, crawl errors, response times, email delivery, backup results, and support reports with the pre-launch baseline.
- Monthly or quarterly: repeat the health review, test a restore, inspect expiring domains and certificates, review user access, and check whether the hosting plan still matches actual resource use.
Keep the checklist in a shared location and record the date, person responsible, result, and follow-up action for each check. That small audit trail is more useful than a checklist that is marked complete without evidence.
How to interpret changes
Not every change indicates a migration failure. DNS results can differ temporarily because resolvers refresh cached records on their own schedules. Compare results from multiple networks and check the authoritative nameservers directly before deciding that the change did not work. If some locations reach the old site and others reach the new one beyond the expected transition window, inspect TTLs, delegation, and duplicate records.
Separate application errors from infrastructure errors. A timeout or connection failure may indicate DNS, firewall, routing, or hosting trouble. A page that loads but shows missing content may point to a database, file path, permissions, or build issue. A form that displays correctly but does not deliver messages may involve application settings or email authentication rather than the web server.
Look for patterns instead of isolated complaints. A rise in 404 responses suggests missing redirects or incorrect internal links. A rise in 500 responses suggests an application or server problem. A drop in conversions with normal traffic may indicate a broken form, checkout, consent flow, or analytics event. If performance changes, compare page templates, asset loading, caching, database activity, and resource limits before changing the entire hosting setup.
When reviewing uptime, treat a hosting uptime guarantee as one input rather than a substitute for independent monitoring. Define what availability means for your site, identify the pages or endpoints that matter most, and keep incident notes. This makes a later discussion about hosting uptime guarantees more concrete.
When to revisit
Revisit this checklist whenever the domain registrar, nameservers, hosting provider, CMS, SSL setup, email provider, or site structure changes. Run it before a domain transfer, major redesign, server migration, WordPress update with significant dependencies, or change to the primary hostname. It is also worth reviewing after a security incident, unexplained outage, lost email, or backup failure.
For routine maintenance, perform a lighter review monthly and a fuller review quarterly. Monthly, check certificate and domain renewal dates, backups, uptime alerts, DNS changes, forms, and email delivery. Quarterly, test restoration, review administrator access, inspect redirect and crawl reports, compare resource use, and confirm that the documented architecture still matches reality.
End each review with three decisions: what is working, what needs correction, and what should be tested next. Assign an owner and a due date to each open item. A website launch is complete only when the site can be reached, trusted, measured, backed up, and supported after the original launch team has moved on.
