{"id":24,"date":"2026-10-03T10:45:56","date_gmt":"2026-10-03T10:45:56","guid":{"rendered":"https:\/\/superhostingai.com\/?p=24"},"modified":"2026-10-03T10:45:56","modified_gmt":"2026-10-03T10:45:56","slug":"website-deployment-checklist-before-changing-dns-or-migrating-hosts","status":"publish","type":"post","link":"https:\/\/superhostingai.com\/?p=24","title":{"rendered":"Website Deployment Checklist Before Changing DNS or Migrating Hosts"},"content":{"rendered":"<blockquote>\n<p><strong>Answer box: What should I verify before I move a live site or point DNS to a new host?<\/strong><br \/>\nBefore changing DNS, verify that you have a current restorable backup, a tested staging copy, a complete DNS inventory, a lower TTL plan, valid SSL\/TLS coverage, working email records, a checked database import, a rollback path, and post-launch monitoring. Do not treat a successful file upload as a successful migration. A live site also depends on database writes, redirects, scheduled tasks, payment callbacks, mail delivery, certificates, cache rules and DNS records.<\/p>\n<\/blockquote>\n<p>Changing hosts is not one switch. DNS is only the cutover step. Google\u2019s hosting-change guidance describes the basic sequence as preparing and testing the new infrastructure, changing DNS, then monitoring traffic on both old and new hosting. It also notes that temporary crawl-rate changes can happen after a hosting infrastructure change, so launch monitoring matters even when URLs stay the same. (<a href=\"https:\/\/developers.google.cn\/search\/docs\/crawling-indexing\/site-move-no-url-changes?hl=en\">developers.google.cn<\/a>)<\/p>\n<h2>1. Make a pre-migration inventory before you copy anything<\/h2>\n<p>Start by writing down what currently serves the site. This is your control sheet for testing, rollback and support tickets.<\/p>\n<p>Record:<\/p>\n<ul>\n<li>Domain registrar and authoritative DNS provider.<\/li>\n<li>Current nameservers.<\/li>\n<li>Existing DNS records: <code>A<\/code>, <code>AAAA<\/code>, <code>CNAME<\/code>, <code>MX<\/code>, <code>TXT<\/code>, <code>CAA<\/code>, <code>SRV<\/code> and any subdomain records.<\/li>\n<li>Current host, server IPs, control panel, SSH\/SFTP details and deployment method.<\/li>\n<li>CMS version, theme, plugins, extensions and custom code.<\/li>\n<li>Runtime requirements: PHP, Node, Python, Ruby, database version, web server, memory limits and cron jobs.<\/li>\n<li>Upload directories, media storage, private files and environment variables.<\/li>\n<li>CDN, WAF, caching, redirects and page rules.<\/li>\n<li>Email provider and authentication records.<\/li>\n<li>Analytics, search console, tag manager, payment gateway and webhook endpoints.<\/li>\n<li>Forms, transactional email, background queues and scheduled tasks.<\/li>\n<\/ul>\n<p>The inventory should identify what must move and what must stay. For example, you may move the website but keep DNS with the current DNS provider. Or you may move hosting and DNS but keep email with the same mail provider. Mixing those up is a common cause of avoidable outages.<\/p>\n<p>For WordPress, inventory both files and database. WordPress documentation explains that a WordPress site includes files such as core, themes, plugins, uploads and configuration files, while the database stores posts and much generated site data; downloading the WordPress directory alone usually does not back up the database. (developer.wordpress.org)<\/p>\n<h2>2. Verify backups by restoring, not just downloading<\/h2>\n<p>A backup is only useful if you can restore it. Before the migration window, create a backup set that includes:<\/p>\n<ul>\n<li>Site files.<\/li>\n<li>Database export.<\/li>\n<li>Configuration files such as <code>.htaccess<\/code>, <code>wp-config.php<\/code>, server redirects and environment files.<\/li>\n<li>Media\/uploads.<\/li>\n<li>Any private storage outside the web root.<\/li>\n<li>DNS zone export or screenshots.<\/li>\n<li>Email routing records.<\/li>\n<li>A note of current server IPs and hostnames.<\/li>\n<\/ul>\n<p>WordPress guidance says to back up the database and files before moving WordPress to a new server, and its backup documentation describes a typical backup order of database first, then files; restore is typically files first, then database import. (<a href=\"https:\/\/developer.wordpress.org\/advanced-administration\/upgrade\/migrating\/\">developer.wordpress.org<\/a>) (developer.wordpress.org)<\/p>\n<p>Do at least one restore test in a non-production location. That may be a staging subdomain, local container or temporary host URL. Check that the restored site can load key pages, access the admin area, show images and connect to the database.<\/p>\n<p>For higher-risk sites, keep more than one backup location. CISA-backed backup guidance commonly describes the 3-2-1 model: keep three copies of important data, on two different media types, with one copy offsite. (cisa.gov)<\/p>\n<p>Practical check: name the backup folder with the date, site name and source host. Keep the database export in the same migration package as the matching files so you do not import a database from Tuesday with uploads from Thursday.<\/p>\n<figure><img decoding=\"async\" src=\"https:\/\/superhostingai.com\/wp-content\/uploads\/2026\/10\/External_hard_drives-scaled.jpg\" alt=\"Three external hard drives on a desk representing backup storage.\"><figcaption>A migration backup should include both site files and the matching database export. \u2014 TonyTheTiger. Own work  <a href=\"https:\/\/commons.wikimedia.org\/wiki\/File:External_hard_drives.jpg\">Source<\/a> <a href=\"https:\/\/creativecommons.org\/licenses\/by-sa\/3.0\">CC BY-SA 3.0<\/a> <\/figcaption><\/figure>\n<h2>3. Build and test staging before lowering the drawbridge<\/h2>\n<p>Do not point live DNS at a new host that you have only viewed through a control panel preview. Test the new environment as close to production as you safely can.<\/p>\n<p>Minimum staging checks:<\/p>\n<ul>\n<li>Homepage, important landing pages and recent posts.<\/li>\n<li>Login, password reset and admin pages.<\/li>\n<li>Contact forms and transactional email.<\/li>\n<li>Search, filters, carts or account areas.<\/li>\n<li>Image uploads and media paths.<\/li>\n<li>Redirects and canonical URLs.<\/li>\n<li>XML sitemap and robots rules.<\/li>\n<li>404 page behavior.<\/li>\n<li>Cron jobs, queues and scheduled publishing.<\/li>\n<li>Error logs under real requests.<\/li>\n<li>Mobile layout and core templates.<\/li>\n<li>Cache purge process.<\/li>\n<\/ul>\n<p>If the site is on WordPress and the domain stays the same, WordPress says moving files and database may be enough when the database and URL remain the same, but <code>wp-config.php<\/code> must be updated if database name, user or host changes. It also warns that URL changes inside the database can cause issues with serialized data if handled by a careless search-and-replace. (<a href=\"https:\/\/developer.wordpress.org\/advanced-administration\/upgrade\/migrating\/\">developer.wordpress.org<\/a>)<\/p>\n<p>Use your local <code>hosts<\/code> file, a temporary staging domain or provider preview domain to test the new server before DNS cutover. If you use a staging domain, be careful with noindex settings and robots rules. Google\u2019s hosting-change guidance specifically says to remove temporary crawling blocks such as <code>robots.txt<\/code> disallows or <code>noindex<\/code> controls before starting the move. (<a href=\"https:\/\/developers.google.cn\/search\/docs\/crawling-indexing\/site-move-no-url-changes?hl=en\">developers.google.cn<\/a>)<\/p>\n<h2>4. Plan DNS TTL, records and cutover timing<\/h2>\n<p>TTL, or Time to Live, controls how long DNS records may be cached. Cloudflare\u2019s DNS documentation explains that longer TTLs can make lookups faster because cached answers are reused, but longer TTLs also mean record updates take longer to take effect. (<a href=\"https:\/\/developers.cloudflare.com\/dns\/manage-dns-records\/reference\/ttl\/\">developers.cloudflare.com<\/a>)<\/p>\n<p>A practical plan:<\/p>\n<ol>\n<li>Two or three days before launch, list current DNS records.<\/li>\n<li>Lower TTLs for records you expect to change, such as the root <code>A<\/code> record and <code>www<\/code> record, if your DNS provider allows it.<\/li>\n<li>Do not delete old records until you know what they do.<\/li>\n<li>Prepare the new records but do not publish them early unless you understand the effect.<\/li>\n<li>At launch, change only the necessary records.<\/li>\n<li>Keep the old host active during propagation and rollback period.<\/li>\n<\/ol>\n<p>Cloudflare notes that proxied records use an automatic TTL set to 300 seconds, while DNS-only records can have configurable TTLs within provider limits. It also cautions that local DNS cache may make changes appear slower to an individual user than the record TTL suggests. (<a href=\"https:\/\/developers.cloudflare.com\/dns\/manage-dns-records\/reference\/ttl\/\">developers.cloudflare.com<\/a>)<\/p>\n<p>Common mistake: changing nameservers and host records at the same time without exporting the old zone. If you move DNS providers, all required records must exist at the new DNS provider before the registrar points to it. That includes records for email, verification, CDN, payment services and subdomains\u2014not just the website IP.<\/p>\n<p>Practical check: use more than one DNS lookup source after launch. Google also recommends using public DNS checking tools and watching traffic move from old servers to new servers during a hosting change. (<a href=\"https:\/\/developers.google.cn\/search\/docs\/crawling-indexing\/site-move-no-url-changes?hl=en\">developers.google.cn<\/a>)<\/p>\n<h2>5. Confirm SSL\/TLS before live traffic arrives<\/h2>\n<p>A new host needs a certificate that matches every public hostname you will serve, commonly the root domain and <code>www<\/code>. If the old host had HTTPS, the new host must be ready for HTTPS before you send users there.<\/p>\n<p>Check:<\/p>\n<ul>\n<li>Certificate covers all required hostnames.<\/li>\n<li>HTTP redirects to HTTPS work as intended.<\/li>\n<li>Mixed content warnings are absent.<\/li>\n<li>HSTS settings are understood before launch.<\/li>\n<li>CDN and origin TLS modes are compatible.<\/li>\n<li>Renewal automation works on the new host.<\/li>\n<li>Port 80 or DNS validation requirements are met.<\/li>\n<\/ul>\n<p>Let\u2019s Encrypt explains that certificate issuance requires proving control of the domain through ACME challenge types. HTTP-01 is often handled automatically by an ACME client, while DNS-01 requires placing a TXT value under <code>_acme-challenge<\/code> and is useful for cases such as wildcard certificates. Let\u2019s Encrypt also warns that DNS validation automation should avoid broad DNS API credentials on a web server when possible. (letsencrypt.org)<\/p>\n<p>Common mistake: waiting until after DNS cutover to request a certificate, then discovering the new host cannot validate because traffic is still cached toward the old host, port 80 is blocked, or the DNS provider API is not configured.<\/p>\n<p>Practical check: browse the staging site over HTTPS, inspect the certificate hostname and expiry, and test both <code>https:\/\/example.com<\/code> and <code>https:\/\/www.example.com<\/code> equivalents before launch.<\/p>\n<h2>6. Protect email routing and third-party callbacks<\/h2>\n<p>Many migrations break email because the person moving the site copies only web records. Email may be handled by a separate provider and usually depends on DNS records that should not be replaced by the web host\u2019s defaults.<\/p>\n<p>Verify:<\/p>\n<ul>\n<li><code>MX<\/code> records still point to the intended mail provider.<\/li>\n<li>SPF <code>TXT<\/code> record includes the correct sending systems.<\/li>\n<li>DKIM selectors still exist.<\/li>\n<li>DMARC record remains in place.<\/li>\n<li>Web forms send through an approved SMTP or mail API.<\/li>\n<li>Transactional messages do not rely on blocked local PHP mail.<\/li>\n<li>Any domain verification records for email platforms remain present.<\/li>\n<\/ul>\n<p>Cloudflare\u2019s email DNS documentation explains that MX records are used for receiving email through the selected provider, and that SPF, DKIM and DMARC records help receiving mail servers verify messages and reduce spoofing risk. It also notes that exact mail record values depend on the email provider. (developers.cloudflare.com)<\/p>\n<p>For ecommerce and membership sites, also list callbacks and webhooks. WooCommerce payment gateway documentation describes callbacks where a gateway calls a store URL to report order status. If those callback URLs fail after migration, payments and order updates may not reconcile correctly. (developer.woocommerce.com)<\/p>\n<p>Practical check: after staging, send a contact form message, a password reset, a test order email and any relevant transactional message to an external inbox. For ecommerce, use the payment provider\u2019s sandbox or test mode where available, and confirm webhook delivery logs.<\/p>\n<h2>7. Check database export\/import and app configuration<\/h2>\n<p>Database migrations fail in quiet ways. A site may load while recent orders, user accounts, media references or serialized settings are missing.<\/p>\n<p>For database-backed sites, verify:<\/p>\n<ul>\n<li>Export completed without errors.<\/li>\n<li>Import completed without errors.<\/li>\n<li>Character set and collation are compatible.<\/li>\n<li>Table counts are plausible.<\/li>\n<li>Recent records exist.<\/li>\n<li>Application config points to the new database host, name, user and password.<\/li>\n<li>Read\/write actions work, not only read-only page views.<\/li>\n<li>No hardcoded paths still point to old server directories.<\/li>\n<\/ul>\n<p>MySQL documentation describes <code>mysqldump<\/code> as a way to create backup files and, with certain options, table data and <code>CREATE TABLE<\/code> statements. The exact export and import method should match your database engine, host limits and site size. (dev.mysql.com)<\/p>\n<p>Worked WordPress example:<\/p>\n<ol>\n<li>Put the old site into a low-change window, or pause publishing and orders if possible.<\/li>\n<li>Export the database.<\/li>\n<li>Copy files including <code>wp-content\/uploads<\/code>, themes, plugins, <code>.htaccess<\/code> and <code>wp-config.php<\/code>.<\/li>\n<li>Import the database on the new host.<\/li>\n<li>Update <code>wp-config.php<\/code> only for the new database credentials.<\/li>\n<li>Test admin login, permalinks, media, forms and plugin functions.<\/li>\n<li>If the domain changes, use a WordPress-aware search-replace method rather than a raw text replacement that may break serialized data. WordPress specifically flags serialized data as a risk during URL replacements. (<a href=\"https:\/\/developer.wordpress.org\/advanced-administration\/upgrade\/migrating\/\">developer.wordpress.org<\/a>)<\/li>\n<\/ol>\n<p>Worked static-site example:<\/p>\n<ol>\n<li>Build the production artifact from the same commit you intend to deploy.<\/li>\n<li>Upload to the new host or object storage.<\/li>\n<li>Confirm routes, redirects, custom error page, headers and cache rules.<\/li>\n<li>Check that forms, search and comments are not secretly dependent on the old host.<\/li>\n<li>Point DNS only after the preview URL or host-file test passes.<\/li>\n<\/ol>\n<p>Worked ecommerce example:<\/p>\n<ol>\n<li>Freeze catalog edits during the final sync.<\/li>\n<li>Export and import the database as close to launch as practical.<\/li>\n<li>Test checkout in sandbox mode.<\/li>\n<li>Confirm webhook or callback URLs are reachable.<\/li>\n<li>Confirm mail records and transactional email sending.<\/li>\n<li>Keep the old host available until payment, order and email logs show normal behavior.<\/li>\n<\/ol>\n<h2>8. Write a rollback plan and monitor after launch<\/h2>\n<p>Rollback should be written before launch, not invented during an outage.<\/p>\n<p>Your rollback note should say:<\/p>\n<ul>\n<li>Which DNS records will be changed back.<\/li>\n<li>What old IP or host target to restore.<\/li>\n<li>Who has registrar, DNS, host and CMS access.<\/li>\n<li>Where the last known-good backup is stored.<\/li>\n<li>Whether database writes must be reconciled before rollback.<\/li>\n<li>What condition triggers rollback.<\/li>\n<li>Who decides.<\/li>\n<\/ul>\n<p>Rollback is simple for a static site if no data changed. It is harder for ecommerce, forums, learning platforms and booking systems because users may create data on the new host after launch. In those cases, plan a maintenance window, a write freeze or a clear decision about how new writes will be handled.<\/p>\n<p>After DNS cutover, monitor:<\/p>\n<ul>\n<li>Uptime checks.<\/li>\n<li>Server access and error logs.<\/li>\n<li>DNS resolution for root and <code>www<\/code>.<\/li>\n<li>HTTPS certificate status.<\/li>\n<li>404 and 500 errors.<\/li>\n<li>Form submissions.<\/li>\n<li>Email delivery.<\/li>\n<li>Checkout or payment logs.<\/li>\n<li>Search Console crawl and indexing reports.<\/li>\n<li>Old server traffic falling and new server traffic rising.<\/li>\n<\/ul>\n<p>Google recommends keeping an eye on logs from both old and new servers as DNS propagation shifts traffic. That is one of the simplest ways to see whether users and crawlers are actually reaching the new infrastructure. (<a href=\"https:\/\/developers.google.cn\/search\/docs\/crawling-indexing\/site-move-no-url-changes?hl=en\">developers.google.cn<\/a>)<\/p>\n<p>For high-risk migrations involving regulated data, payment data, security incidents or business-critical uptime, get qualified help. This article is general operational guidance, not a managed migration service or legal\/security advice. See the site\u2019s <a href=\"https:\/\/superhostingai.com\/?page_id=10\">Disclaimer<\/a> for the site\u2019s general information limits.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Answer box: What should I verify before I move a live site or point DNS to a new host? Before changing DNS, verify that you have a current restorable backup, a tested staging copy, a complete DNS inventory, a lower TTL plan, valid SSL\/TLS coverage, working email records, a checked database import, a rollback path, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":23,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/posts\/24","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/superhostingai.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=24"}],"version-history":[{"count":0,"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/posts\/24\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/superhostingai.com\/index.php?rest_route=\/wp\/v2\/media\/23"}],"wp:attachment":[{"href":"https:\/\/superhostingai.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/superhostingai.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/superhostingai.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}