Website Launch and Migration Checklist: Domain, Hosting, SSL, Redirects, and Testing

Overview

Use this website launch checklist for a new site, redesign, CMS change, hosting move, or staging-to-production release. The sequence matters: prepare the new environment before changing DNS, verify the site on its future domain, and keep the old site available until the new version has passed its post-launch checks.

Start by creating a simple launch record with the project name, target domain, current host, new host, planned change window, technical owner, content owner, and rollback decision-maker. Add a status column for each task: Not started, In progress, Blocked, or Complete. This turns a long list of technical details into a shared operating document.

Before touching DNS, confirm who controls the domain registrar, DNS provider, hosting account, CMS, analytics property, email service, and certificate settings. A domain may be registered in one account, use nameservers at another provider, and point to hosting somewhere else. Understanding that chain prevents a common migration mistake: editing records in a dashboard that is not authoritative for the domain.

For background, see the domain portfolio management guide and the DNS records cheat sheet.

What to track

1. Pre-launch preparation

• Record the complete list of live domains, subdomains, URL patterns, and important landing pages.
• Lower DNS time-to-live values ahead of a planned change only if your DNS provider and change plan require it. Record the original values so they can be restored later.
• Confirm that the new hosting environment has the required runtime version, database, storage, server access, environment variables, and CMS configuration.
• Copy the site and database to staging, then test the copy without modifying production.
• Take a restorable backup of files, databases, uploads, configuration, and email-related settings. A backup is not ready for an emergency until you know how to restore it; use the website backup and restore guide to plan that test.
• List integrations such as payment tools, forms, search, maps, chat, advertising, webhooks, and third-party APIs. Confirm whether each integration allows staging traffic or needs production credentials.

2. Content, crawlability, and URLs

• Compare the staging site with the current site for page count, titles, headings, canonical URLs, images, downloads, and internal links.
• Prepare a URL map for pages that will change. Each retired or changed URL should have a deliberate destination, usually a closely matching replacement rather than a generic homepage.
• Check that the production site does not retain staging-only password protection, noindex directives, disallow rules, placeholder text, or test content.
• Generate or verify the XML sitemap and confirm that its URLs use the final HTTPS domain.
• Check canonical tags, hreflang settings where applicable, structured data, pagination, and image alt text.

3. DNS, hosting, and SSL

Make a record-by-record plan before changing DNS. Identify the intended A or AAAA record for the root domain, the CNAME or other record for www, and any separate records for subdomains. Do not replace email records while moving a website unless email is part of the same project. DNS is also where verification records, SPF, DKIM, DMARC, and service-specific TXT records often live.

Check the distinction between nameservers and DNS records: nameservers determine which provider answers DNS queries, while records define where individual services point. If you change nameservers, you may need to recreate every required record at the new provider. For a detailed troubleshooting process, see the DNS troubleshooting guide.

Complete an SSL setup check before launch. The certificate should cover every public hostname users will visit, the server should redirect HTTP to HTTPS where appropriate, and mixed-content warnings should be resolved. Confirm that renewal is automated or that a named owner has a reminder and a documented renewal procedure.

4. Functional quality assurance

• Test navigation, search, account creation, login, checkout, forms, file downloads, comments, and any role-based features.
• Submit every important form with a test address and confirm validation, success messages, notifications, storage, and spam controls.
• Test on current desktop and mobile browsers, at different viewport sizes, and with a slow or interrupted connection where practical.
• Check keyboard navigation, visible focus, labels, heading order, color contrast, error messages, and meaningful alternative text.
• Review page performance, large images, cache behavior, redirects, and console errors. Compare the new site with the old site rather than relying on a single score.

5. Email, analytics, and security

Verify that domain email still works before and after the website change. Confirm MX records, sending authentication, contact-form delivery, mailbox access, and replies. A website migration should not silently remove an MX, SPF, DKIM, or DMARC record. Use the custom domain email setup guide when email hosting is part of the project.

Install analytics and tag-management settings on the production version, then test page views, conversions, consent choices, ecommerce events, and referral exclusions as applicable. Keep a dated note of the expected tracking behavior so a later change can be compared with a known baseline.

Before launch, update administrator passwords where needed, remove unused accounts and test keys, enable multifactor authentication for important services, check file permissions, and confirm that backups and monitoring are active.

Cadence and checkpoints

Several days before launch: finish the content and URL comparison, take a tested backup, verify access to all accounts, confirm the DNS plan, and write the rollback steps. Freeze nonessential changes to the old site if simultaneous editing could create conflicts.

Immediately before the DNS change: confirm that the new site is ready, the certificate is valid, redirects are loaded, email records are documented, and the launch team knows who is watching each system. Save a snapshot of important DNS records and analytics totals.

During the change: apply only the planned DNS edits. Record the exact time, values, and operator. Use a DNS propagation checker and query more than one resolver, but remember that cached answers can remain visible for a while. Check the site from a direct hostname, the root domain, the www hostname, and key subdomains.

Within the first hour: test HTTPS, the homepage, representative content pages, redirects, forms, login, search, checkout if relevant, and email delivery. Watch server errors, application logs, uptime alerts, analytics, and search-console-style crawl reports if available.

After the first day: review 404s, 5xx errors, redirect chains, traffic patterns, conversion events, indexing signals, resource usage, backup completion, and customer or internal reports. Keep the old hosting environment available until the agreed rollback window has passed.

After the first week: compare organic landing pages, top entry URLs, form submissions, page speed, email delivery, and uptime with the pre-launch baseline. Remove temporary access, staging accounts, debug settings, and migration files only after confirming they are no longer needed.

How to interpret changes

A sudden outage after launch usually points to a small set of dependencies: incorrect DNS, an incomplete certificate configuration, a hosting or application error, a database connection problem, or a failed third-party integration. Test each layer separately instead of changing several settings at once. A DNS lookup can show whether a hostname resolves, an HTTPS request can show certificate and redirect behavior, and an application log can reveal what happens after the request reaches the server.

A rise in 404 responses often means that the URL map missed old links, trailing-slash behavior changed, or asset paths were altered. Build precise 301 redirects where a relevant destination exists. Avoid sending every missing URL to the homepage, because that hides the original problem and may confuse users.

If traffic falls but the site loads normally, compare affected URL groups, canonical tags, robots directives, sitemap URLs, analytics installation, and redirects. If traffic is stable but conversions fall, test forms, checkout, calls to action, consent settings, and event tracking before assuming the cause is search visibility.

Email problems are often independent of website availability. Recheck MX and authentication records, form sender settings, mailbox quotas, and delivery logs. Do not “fix” a website outage by deleting mail records or changing nameservers without documenting the consequences.

When to revisit

Review this checklist before every launch, redesign, hosting migration, domain move, major CMS update, or change to the URL structure. Perform a lighter monthly or quarterly review of SSL renewal status, DNS records, domain and hosting ownership, backups, uptime alerts, forms, analytics, redirects, and administrator access. A domain expiration or hosting renewal review is especially important; the domain expiration prevention guide can help document those dates.

Refresh the checklist after a major browser, CMS, hosting-control-panel, analytics, or search-engine change. Also revisit it after an incident, because the most useful checklist reflects failures you have actually seen. Record what happened, which signal detected it, how long recovery took, and what new preventive check should be added.

Finally, keep a short rollback plan with three explicit decisions: what condition triggers rollback, who authorizes it, and which steps restore the previous DNS, hosting, database, and application state. Once the new site has remained stable through the agreed observation period, archive the launch record—but retain the URL map, DNS inventory, backup procedure, and monitoring ownership for the next release.