{"id":3812,"date":"2025-12-31T14:59:45","date_gmt":"2025-12-31T11:59:45","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/domain-and-dns-migration-checklist-when-changing-hosting-provider\/"},"modified":"2025-12-31T14:59:45","modified_gmt":"2025-12-31T11:59:45","slug":"domain-and-dns-migration-checklist-when-changing-hosting-provider","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/domain-and-dns-migration-checklist-when-changing-hosting-provider\/","title":{"rendered":"Domain and DNS Migration Checklist When Changing Hosting Provider"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Changing hosting provider is often the right move for performance, cost or support reasons, but many teams hesitate because of one fear: breaking DNS and taking the site offline. The good news is that with the right domain and DNS migration checklist, you can switch hosting providers with zero or near-zero downtime. In this guide, we walk through a practical, step-by-step process we use at dchost.com when moving customer domains, DNS zones and websites between servers and platforms. We\u2019ll look at how to inventory your existing DNS, plan TTL changes, sequence nameserver and A\/AAAA record updates, protect email delivery and keep SEO intact. Even if you are not a DNS expert, you\u2019ll see how to treat this as a predictable, reversible change instead of a risky leap.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#1_Understand_What_Youre_Migrating_Domain_DNS_and_Hosting_Roles\"><span class=\"toc_number toc_depth_1\">1<\/span> 1. Understand What You\u2019re Migrating: Domain, DNS and Hosting Roles<\/a><\/li><li><a href=\"#2_PreMigration_Inventory_Create_a_DNS_and_Domain_Snapshot\"><span class=\"toc_number toc_depth_1\">2<\/span> 2. Pre\u2011Migration Inventory: Create a DNS and Domain Snapshot<\/a><ul><li><a href=\"#21_List_all_domains_and_subdomains_affected\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 2.1. List all domains and subdomains affected<\/a><\/li><li><a href=\"#22_Export_your_current_DNS_zone\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2.2. Export your current DNS zone<\/a><\/li><li><a href=\"#23_Capture_domain_and_security_settings\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 2.3. Capture domain and security settings<\/a><\/li><\/ul><\/li><li><a href=\"#3_Decide_Scope_DNS_Change_Only_vs_Full_Domain_Transfer\"><span class=\"toc_number toc_depth_1\">3<\/span> 3. Decide Scope: DNS Change Only vs Full Domain Transfer<\/a><ul><li><a href=\"#31_Scenario_A_Keep_registrar_and_DNS_where_they_are_change_only_AAAAA_records\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 3.1. Scenario A: Keep registrar and DNS where they are, change only A\/AAAA records<\/a><\/li><li><a href=\"#32_Scenario_B_Change_DNS_to_the_new_hosting_provider_keep_registrar\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 3.2. Scenario B: Change DNS to the new hosting provider, keep registrar<\/a><\/li><li><a href=\"#33_Scenario_C_Full_move_registrar_DNS_and_hosting\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3.3. Scenario C: Full move \u2014 registrar, DNS and hosting<\/a><\/li><\/ul><\/li><li><a href=\"#4_Plan_TTL_and_Propagation_Make_Changes_Reversible\"><span class=\"toc_number toc_depth_1\">4<\/span> 4. Plan TTL and Propagation: Make Changes Reversible<\/a><ul><li><a href=\"#41_Lower_TTL_before_the_migration_window\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 4.1. Lower TTL before the migration window<\/a><\/li><li><a href=\"#42_Understand_DNS_propagation_expectations\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 4.2. Understand DNS propagation expectations<\/a><\/li><\/ul><\/li><li><a href=\"#5_Prepare_the_New_Hosting_Environment_Before_DNS_Cutover\"><span class=\"toc_number toc_depth_1\">5<\/span> 5. Prepare the New Hosting Environment Before DNS Cutover<\/a><ul><li><a href=\"#51_Sync_website_files_and_databases\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 5.1. Sync website files and databases<\/a><\/li><li><a href=\"#52_Test_the_site_on_the_new_server_without_DNS_changes\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 5.2. Test the site on the new server without DNS changes<\/a><\/li><li><a href=\"#53_Prepare_DNS_zone_at_the_new_provider_if_changing_nameservers\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 5.3. Prepare DNS zone at the new provider (if changing nameservers)<\/a><\/li><\/ul><\/li><li><a href=\"#6_StepbyStep_DNS_Cutover_ZeroDowntime_Playbook\"><span class=\"toc_number toc_depth_1\">6<\/span> 6. Step\u2011by\u2011Step DNS Cutover: Zero\u2011Downtime Playbook<\/a><ul><li><a href=\"#61_Case_1_Only_changing_AAAAA_records_DNS_provider_stays_the_same\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 6.1. Case 1: Only changing A\/AAAA records (DNS provider stays the same)<\/a><\/li><li><a href=\"#62_Case_2_Changing_nameservers_to_a_new_DNS_provider\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 6.2. Case 2: Changing nameservers to a new DNS provider<\/a><\/li><li><a href=\"#63_Reenable_DNSSEC_if_you_use_it\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 6.3. Re\u2011enable DNSSEC (if you use it)<\/a><\/li><\/ul><\/li><li><a href=\"#7_Email_SPFDKIM_and_Other_Gotchas_During_Domain_DNS_Migration\"><span class=\"toc_number toc_depth_1\">7<\/span> 7. Email, SPF\/DKIM and Other Gotchas During Domain &amp; DNS Migration<\/a><ul><li><a href=\"#71_Decide_whether_email_is_moving\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 7.1. Decide whether email is moving<\/a><\/li><li><a href=\"#72_Preserve_or_update_MX_SPF_DKIM_and_DMARC\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 7.2. Preserve or update MX, SPF, DKIM and DMARC<\/a><\/li><li><a href=\"#73_Beware_of_domain_transfers_that_change_nameservers_automatically\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 7.3. Beware of domain transfers that change nameservers automatically<\/a><\/li><\/ul><\/li><li><a href=\"#8_SEO_and_HTTPS_Considerations_During_DNS_Migration\"><span class=\"toc_number toc_depth_1\">8<\/span> 8. SEO and HTTPS Considerations During DNS Migration<\/a><ul><li><a href=\"#81_Keep_content_and_URLs_identical_across_old_and_new_hosts\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 8.1. Keep content and URLs identical across old and new hosts<\/a><\/li><li><a href=\"#82_Ensure_SSLTLS_is_active_on_the_new_host_before_cutover\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 8.2. Ensure SSL\/TLS is active on the new host before cutover<\/a><\/li><\/ul><\/li><li><a href=\"#9_PostMigration_Checklist_Verify_Monitor_and_Then_Decommission\"><span class=\"toc_number toc_depth_1\">9<\/span> 9. Post\u2011Migration Checklist: Verify, Monitor and Then Decommission<\/a><ul><li><a href=\"#91_Technical_verification\"><span class=\"toc_number toc_depth_2\">9.1<\/span> 9.1. Technical verification<\/a><\/li><li><a href=\"#92_Application-level_checks\"><span class=\"toc_number toc_depth_2\">9.2<\/span> 9.2. Application-level checks<\/a><\/li><li><a href=\"#93_Monitoring_and_logs\"><span class=\"toc_number toc_depth_2\">9.3<\/span> 9.3. Monitoring and logs<\/a><\/li><li><a href=\"#94_Clean_up_and_raise_TTLs\"><span class=\"toc_number toc_depth_2\">9.4<\/span> 9.4. Clean up and raise TTLs<\/a><\/li><\/ul><\/li><li><a href=\"#10_Putting_It_All_Together_A_Calm_Repeatable_Domain_and_DNS_Migration\"><span class=\"toc_number toc_depth_1\">10<\/span> 10. Putting It All Together: A Calm, Repeatable Domain and DNS Migration<\/a><\/li><\/ul><\/div>\n<h2><span id=\"1_Understand_What_Youre_Migrating_Domain_DNS_and_Hosting_Roles\">1. Understand What You\u2019re Migrating: Domain, DNS and Hosting Roles<\/span><\/h2>\n<p>Before touching any setting, clarify which parts you are actually moving. Three components are involved:<\/p>\n<ul>\n<li><strong>Domain (registrar level)<\/strong>: where the domain is registered and renewed.<\/li>\n<li><strong>DNS hosting (nameservers)<\/strong>: where A, MX, CNAME, TXT and other records live.<\/li>\n<li><strong>Web and email hosting<\/strong>: the servers that actually serve your website and handle email.<\/li>\n<\/ul>\n<p>These three can live in the same place or at different providers. Many customers come to us with:<\/p>\n<ul>\n<li>Domain at Registrar A, DNS at Registrar A, website and email at Host B<\/li>\n<li>Domain at Registrar A, DNS at Provider C, website at Host B, email at a separate SaaS provider<\/li>\n<\/ul>\n<p>Zero-downtime migration starts with knowing that separation. If you only change <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a> but leave DNS and email where they are, your plan is much simpler than a full <a href=\"https:\/\/www.dchost.com\/domain\/transfer\">domain transfer<\/a> plus DNS move.<\/p>\n<p>For a quick refresher on how these components work together, our post <a href='https:\/\/www.dchost.com\/blog\/en\/web-hosting-nedir-domain-dns-sunucu-ve-ssl-nasil-birlikte-calisir\/'>what web hosting is and how domain, DNS, server and SSL work together<\/a> is a good background read.<\/p>\n<h2><span id=\"2_PreMigration_Inventory_Create_a_DNS_and_Domain_Snapshot\">2. Pre\u2011Migration Inventory: Create a DNS and Domain Snapshot<\/span><\/h2>\n<h3><span id=\"21_List_all_domains_and_subdomains_affected\">2.1. List all domains and subdomains affected<\/span><\/h3>\n<p>Make a list of every hostname that depends on the hosting you\u2019ll change. This often includes more than just <strong>example.com<\/strong> and <strong>www.example.com<\/strong>:<\/p>\n<ul>\n<li>Blog or shop subdomains: <strong>blog.example.com<\/strong>, <strong>store.example.com<\/strong><\/li>\n<li>API and app endpoints: <strong>api.example.com<\/strong>, <strong>app.example.com<\/strong><\/li>\n<li>Mail-related names: <strong>mail.example.com<\/strong>, <strong>smtp.example.com<\/strong>, <strong>webmail.example.com<\/strong><\/li>\n<li>CDN or static asset subdomains: <strong>cdn.example.com<\/strong>, <strong>static.example.com<\/strong><\/li>\n<li>Admin\/staging: <strong>admin.example.com<\/strong>, <strong>staging.example.com<\/strong><\/li>\n<\/ul>\n<p>Anything that resolves via the DNS zone you\u2019re changing must be considered in the plan.<\/p>\n<h3><span id=\"22_Export_your_current_DNS_zone\">2.2. Export your current DNS zone<\/span><\/h3>\n<p>Next, capture the exact DNS configuration as it exists today. Ideally, use the export function in your current DNS control panel (often called \u201czone file export\u201d). If that\u2019s not available, manually copy all records or use tools like <code>dig<\/code> or <code>nslookup<\/code> to query them:<\/p>\n<ul>\n<li><strong>A \/ AAAA<\/strong> records: web, API, FTP, mail servers<\/li>\n<li><strong>CNAME<\/strong> records: www aliases, CDN hostnames, SaaS integrations<\/li>\n<li><strong>MX<\/strong> records: mail exchangers and their priority<\/li>\n<li><strong>TXT<\/strong> records: SPF, DKIM, DMARC, verification tokens (Google, Microsoft, etc.)<\/li>\n<li><strong>SRV<\/strong> records: some VoIP, chat, or directory services<\/li>\n<li><strong>CAA<\/strong> records: which CAs can issue SSL for your domain<\/li>\n<li><strong>NS<\/strong> records inside the zone (rare but possible)<\/li>\n<\/ul>\n<p>If you\u2019re not fully comfortable with record types, our article <a href='https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-nedir-a-aaaa-cname-mx-txt-ve-srv-rehberi\/'>DNS records explained step\u2011by\u2011step (A, AAAA, CNAME, MX, TXT and SRV)<\/a> will help you recognise what you\u2019re looking at.<\/p>\n<h3><span id=\"23_Capture_domain_and_security_settings\">2.3. Capture domain and security settings<\/span><\/h3>\n<p>At the registrar and DNS level, record:<\/p>\n<ul>\n<li><strong>Registrar lock \/ transfer lock<\/strong> status<\/li>\n<li>Current <strong>nameservers<\/strong> (e.g. ns1.example-dns.com, ns2.example-dns.com)<\/li>\n<li>Whether <strong>DNSSEC<\/strong> is enabled and configured (DS records present at the registry)<\/li>\n<li>Any <strong>WHOIS privacy<\/strong> and contact details<\/li>\n<\/ul>\n<p>When you later change DNS or transfer the domain, you\u2019ll need to know which of these security features must be adjusted. Our detailed <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/'>domain security best practices guide<\/a> explains how registrar lock, DNSSEC and WHOIS privacy interact during migrations.<\/p>\n<h2><span id=\"3_Decide_Scope_DNS_Change_Only_vs_Full_Domain_Transfer\">3. Decide Scope: DNS Change Only vs Full Domain Transfer<\/span><\/h2>\n<p>There are three common scenarios when moving to a new hosting provider like dchost.com:<\/p>\n<h3><span id=\"31_Scenario_A_Keep_registrar_and_DNS_where_they_are_change_only_AAAAA_records\">3.1. Scenario A: Keep registrar and DNS where they are, change only A\/AAAA records<\/span><\/h3>\n<p>In this case, your domain stays at the current registrar, DNS stays on the current nameservers, and you only point the web records to your new hosting server IP (for example, a new shared hosting plan, VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> at dchost.com).<\/p>\n<p><strong>Pros:<\/strong><\/p>\n<ul>\n<li>Fastest and simplest option<\/li>\n<li>Almost no risk of breaking email or other services<\/li>\n<li>No registrar transfer or DNS provider change required<\/li>\n<\/ul>\n<p><strong>Cons:<\/strong><\/p>\n<ul>\n<li>Your DNS panel remains at the old provider<\/li>\n<li>You depend on their DNS uptime and performance<\/li>\n<\/ul>\n<h3><span id=\"32_Scenario_B_Change_DNS_to_the_new_hosting_provider_keep_registrar\">3.2. Scenario B: Change DNS to the new hosting provider, keep registrar<\/span><\/h3>\n<p>Here the domain remains registered where it is, but you move DNS management to the new hosting provider\u2019s nameservers (for example, to dchost.com nameservers). You will recreate the DNS zone in the new panel and then switch the domain\u2019s nameserver records at the registrar.<\/p>\n<p><strong>Pros:<\/strong><\/p>\n<ul>\n<li>Single place for hosting and DNS management<\/li>\n<li>Often better DNS tooling and integration with hosting panel<\/li>\n<\/ul>\n<p><strong>Cons:<\/strong><\/p>\n<ul>\n<li>Requires careful zone copy and nameserver cutover planning<\/li>\n<li>DNSSEC and glue records (for private nameservers) need special attention<\/li>\n<\/ul>\n<p>For choosing between hosting DNS and third-party DNS, see our comparison of <a href='https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/'>Cloudflare DNS vs hosting DNS and nameserver strategies<\/a>.<\/p>\n<h3><span id=\"33_Scenario_C_Full_move_registrar_DNS_and_hosting\">3.3. Scenario C: Full move \u2014 registrar, DNS and hosting<\/span><\/h3>\n<p>Sometimes you want a clean slate: transfer the domain, move DNS, and change hosting all together. This is fully doable without downtime, but requires the most disciplined checklist:<\/p>\n<ul>\n<li>Domain transfer (EPP code, transfer lock management)<\/li>\n<li>DNS zone recreation at the destination<\/li>\n<li>Hosting migration (files, database, email)<\/li>\n<li>DNS cutover for web and mail<\/li>\n<\/ul>\n<p>Our article <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-transferi-nasil-yapilir-epp-kodu-transfer-kilidi-ve-kesintisiz-gecise-sakin-bir-rehber\/'>how to transfer a domain without downtime<\/a> covers registrar-level details; in this post we\u2019ll focus more on DNS and hosting interaction.<\/p>\n<h2><span id=\"4_Plan_TTL_and_Propagation_Make_Changes_Reversible\">4. Plan TTL and Propagation: Make Changes Reversible<\/span><\/h2>\n<p>DNS changes don\u2019t apply instantly worldwide. Each record has a <strong>TTL (Time To Live)<\/strong> value that tells resolvers how long they may cache the answer. To make your migration painless and reversible, you must control TTLs in advance.<\/p>\n<h3><span id=\"41_Lower_TTL_before_the_migration_window\">4.1. Lower TTL before the migration window<\/span><\/h3>\n<p>Our usual playbook looks like this:<\/p>\n<ol>\n<li><strong>7\u201348 hours before cutover<\/strong>: Lower TTLs on critical records (A\/AAAA for www &amp; root, MX if mail servers move, some TXT records) to something like 300\u2013600 seconds (5\u201310 minutes).<\/li>\n<li><strong>Wait for the old TTL period to elapse<\/strong>: For example, if the old TTL was 4 hours, wait at least 4 hours after lowering it before you trust the shorter TTL to be respected globally.<\/li>\n<li><strong>Perform the migration<\/strong> during a maintenance window when the shorter TTL is active.<\/li>\n<\/ol>\n<p>This way, if you make a mistake, you can revert the record and most users will see the fix within a few minutes. Our dedicated article <a href='https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/'>TTL playbook for zero\u2011downtime migrations<\/a> dives deeper into realistic TTL values and timing.<\/p>\n<h3><span id=\"42_Understand_DNS_propagation_expectations\">4.2. Understand DNS propagation expectations<\/span><\/h3>\n<p>Even with short TTLs, some recursive resolvers or local systems cache longer than they should, and some networks have their own DNS peculiarities. For business-critical sites, we recommend assuming that:<\/p>\n<ul>\n<li>Most visitors will see the new destination within minutes<\/li>\n<li>A small percentage might continue to hit the old server for up to a couple of hours<\/li>\n<\/ul>\n<p>That\u2019s why a true zero-downtime migration normally keeps both old and new hosting environments online in parallel during the transition. For a clear explanation of why \u201c24 hours\u201d is often quoted and how to monitor propagation, see <a href='https:\/\/www.dchost.com\/blog\/en\/dns-yayilim-suresi-nedir-neden-24-saat-surer-ve-nasil-hizlandirilir\/'>what DNS propagation is and why it takes time<\/a>.<\/p>\n<h2><span id=\"5_Prepare_the_New_Hosting_Environment_Before_DNS_Cutover\">5. Prepare the New Hosting Environment Before DNS Cutover<\/span><\/h2>\n<p>Never start DNS changes before your new hosting environment is fully prepared and tested. On dchost.com this typically means:<\/p>\n<ul>\n<li>Web space \/ virtual host created for the domain<\/li>\n<li>PHP, database and caching configured for the application<\/li>\n<li>SSL\/TLS certificate installed (or ready via Let\u2019s Encrypt)<\/li>\n<li>Database imported and application config updated with new DB credentials<\/li>\n<\/ul>\n<h3><span id=\"51_Sync_website_files_and_databases\">5.1. Sync website files and databases<\/span><\/h3>\n<p>Copy your site content to the new server using SFTP, rsync or control panel migration tools. For dynamic sites (WordPress, WooCommerce, Laravel, custom apps):<\/p>\n<ul>\n<li>Take a fresh backup of the database on the old host<\/li>\n<li>Import it on the new host<\/li>\n<li>Update config files (e.g. <code>wp-config.php<\/code>, <code>.env<\/code>) with new DB host, user and password<\/li>\n<\/ul>\n<p>If you\u2019re moving from shared hosting to a VPS, our post <a href='https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingden-vpse-sorunsuz-gecis-rehberi\/'>moving from shared hosting to a VPS without downtime<\/a> covers application-side details like background jobs and cache.<\/p>\n<h3><span id=\"52_Test_the_site_on_the_new_server_without_DNS_changes\">5.2. Test the site on the new server without DNS changes<\/span><\/h3>\n<p>You can usually test the new hosting by:<\/p>\n<ul>\n<li>Using a temporary URL or preview link (if your panel provides one), or<\/li>\n<li>Editing your local <code>hosts<\/code> file to map <strong>example.com<\/strong> and <strong>www.example.com<\/strong> to the new server IP<\/li>\n<\/ul>\n<p>Browse the entire site, including login, checkout, forms, and any custom flows. Check logs and fix any errors before touching DNS. If you\u2019re using a CDN, verify that it can reach the new origin server and that cache rules work as expected.<\/p>\n<h3><span id=\"53_Prepare_DNS_zone_at_the_new_provider_if_changing_nameservers\">5.3. Prepare DNS zone at the new provider (if changing nameservers)<\/span><\/h3>\n<p>If you\u2019re moving DNS to your new hosting provider, create the DNS zone but <strong>do not<\/strong> change the registrar nameservers yet. Recreate all records from your earlier export:<\/p>\n<ul>\n<li>For web: root and <strong>www<\/strong> A\/AAAA records pointing to the new server IP<\/li>\n<li>For email: same MX records (if mail stays where it is) or updated MX (if mail moves)<\/li>\n<li>All TXT, CNAME, SRV, CAA and other records from the old zone<\/li>\n<\/ul>\n<p>Double-check that nothing is missing, especially TXT records for SPF, DKIM and DMARC.<\/p>\n<h2><span id=\"6_StepbyStep_DNS_Cutover_ZeroDowntime_Playbook\">6. Step\u2011by\u2011Step DNS Cutover: Zero\u2011Downtime Playbook<\/span><\/h2>\n<p>The exact steps depend on which scenario you\u2019re in. We\u2019ll cover the two most common: \u201cA\/AAAA change only\u201d and \u201cnameserver change\u201d. In both cases, we assume you already lowered TTLs.<\/p>\n<h3><span id=\"61_Case_1_Only_changing_AAAAA_records_DNS_provider_stays_the_same\">6.1. Case 1: Only changing A\/AAAA records (DNS provider stays the same)<\/span><\/h3>\n<ol>\n<li><strong>Confirm TTLs are low<\/strong> (e.g. 300\u2013600 seconds) for the records you\u2019re about to change.<\/li>\n<li><strong>Update A\/AAAA for the root and www<\/strong>: Set them to the new server IP.<\/li>\n<li><strong>Update any other hostnames<\/strong> that should now point to the new server (api, admin, staging, etc.).<\/li>\n<li><strong>Wait 5\u201315 minutes<\/strong> and test from multiple networks (home, mobile, VPN) using <code>dig<\/code>, <code>nslookup<\/code> or online tools to confirm that most resolvers now return the new IP.<\/li>\n<li><strong>Keep the old server online<\/strong> for at least several hours (ideally 24 hours) to serve visitors who still hit the old IP due to caching.<\/li>\n<li>Once you\u2019re confident all traffic has shifted, you can <strong>raise TTL<\/strong> back to more cache-friendly values (e.g. 1\u20134 hours).<\/li>\n<\/ol>\n<h3><span id=\"62_Case_2_Changing_nameservers_to_a_new_DNS_provider\">6.2. Case 2: Changing nameservers to a new DNS provider<\/span><\/h3>\n<p>This is slightly more complex, because you switch the entire DNS authority from one provider to another.<\/p>\n<ol>\n<li><strong>Ensure new DNS zone is complete<\/strong>: Every record from the old zone must exist in the new one, with updated IPs where necessary.<\/li>\n<li><strong>Temporarily disable DNSSEC<\/strong> at the registrar if it\u2019s currently enabled and your new DNS stack is not yet set up for DNSSEC. Failing to do this correctly can cause resolution failures.<\/li>\n<li><strong>At the registrar, change nameservers<\/strong> to the new provider\u2019s NS values (for example, dchost.com\u2019s nameservers).<\/li>\n<li><strong>Monitor propagation<\/strong> using <code>dig @resolver<\/code> against various public resolvers and online tools. You should see more and more resolvers querying the new nameservers over time.<\/li>\n<li><strong>Keep the old DNS zone active<\/strong> at the previous provider for at least 48\u201372 hours<\/li>\n<\/ol>\n<p>During this overlap period, some users may still look up records from the old NS set, but because both old and new zones contain valid records pointing to working servers, they won\u2019t see downtime.<\/p>\n<h3><span id=\"63_Reenable_DNSSEC_if_you_use_it\">6.3. Re\u2011enable DNSSEC (if you use it)<\/span><\/h3>\n<p>After most resolvers are using the new nameservers and the new DNS provider supports DNSSEC, you can:<\/p>\n<ul>\n<li>Enable DNSSEC for the zone at the new DNS provider<\/li>\n<li>Obtain the DS record details (key tag, algorithm, digest type, digest)<\/li>\n<li>Add\/update the DS record at the domain registry via your registrar<\/li>\n<\/ul>\n<p>Follow the provider\u2019s instructions closely to avoid a misconfiguration that could cause DNS failures. If DNSSEC is a core part of your security posture, our guide <a href='https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-ne-ise-yarar-alan-adiniz-ve-hostinginiz-icin-adim-adim-dnssec-kurulum-rehberi\/'>what DNSSEC is and how to enable it step\u2011by\u2011step<\/a> provides an operator-friendly walkthrough.<\/p>\n<h2><span id=\"7_Email_SPFDKIM_and_Other_Gotchas_During_Domain_DNS_Migration\">7. Email, SPF\/DKIM and Other Gotchas During Domain &amp; DNS Migration<\/span><\/h2>\n<p>Most migration issues we see are not about the website but about email. When DNS or domain settings change, it\u2019s easy to accidentally break MX records, SPF\/DKIM or IMAP\/SMTP hostnames.<\/p>\n<h3><span id=\"71_Decide_whether_email_is_moving\">7.1. Decide whether email is moving<\/span><\/h3>\n<p>Ask yourself:<\/p>\n<ul>\n<li>Is email staying on the old provider, or moving to the new hosting provider?<\/li>\n<li>Is email hosted on a separate SaaS platform (e.g. a cloud email suite) that should <strong>not<\/strong> change?<\/li>\n<\/ul>\n<p>If email is <strong>not<\/strong> moving, make sure your new DNS zone keeps the existing MX records and related TXT records exactly as they are.<\/p>\n<h3><span id=\"72_Preserve_or_update_MX_SPF_DKIM_and_DMARC\">7.2. Preserve or update MX, SPF, DKIM and DMARC<\/span><\/h3>\n<p>Pay particular attention to:<\/p>\n<ul>\n<li><strong>MX records<\/strong>: They must point to your active mail servers with correct priority values.<\/li>\n<li><strong>SPF (TXT)<\/strong>: Should allow the IPs and sending domains that actually send emails for your domain (web server, transactional services, marketing tools, etc.).<\/li>\n<li><strong>DKIM (TXT)<\/strong>: Copy selector records (e.g. <strong>default._domainkey.example.com<\/strong>) from the old DNS zone if the mail server remains the same.<\/li>\n<li><strong>DMARC (TXT)<\/strong>: Make sure policy and reporting addresses remain correct.<\/li>\n<\/ul>\n<p>For a deeper dive on sender authentication, check our guide <a href='https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/'>SPF, DKIM and DMARC explained for cPanel and VPS email<\/a>.<\/p>\n<h3><span id=\"73_Beware_of_domain_transfers_that_change_nameservers_automatically\">7.3. Beware of domain transfers that change nameservers automatically<\/span><\/h3>\n<p>Some registrars change your nameservers during a domain transfer (for example, to their default DNS) if you\u2019re not careful. That\u2019s one of the most common reasons <strong>email suddenly stops working<\/strong> after a domain move. We\u2019ve covered this in detail in <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-tasirken-e%e2%80%91posta-kesintisini-onlemek\/'>why domain transfers break email and how to avoid it<\/a>.<\/p>\n<p>The short version: when transferring a domain, explicitly confirm which nameservers will be used after the transfer, and ensure the correct DNS zone (with MX, SPF, DKIM, etc.) exists and is active there.<\/p>\n<h2><span id=\"8_SEO_and_HTTPS_Considerations_During_DNS_Migration\">8. SEO and HTTPS Considerations During DNS Migration<\/span><\/h2>\n<p>DNS and hosting changes, if done correctly, should not harm your SEO. The two big risks are:<\/p>\n<ul>\n<li>Prolonged downtime or serving errors (4xx\/5xx) to crawlers<\/li>\n<li>Serving different content or broken redirects on the new host<\/li>\n<\/ul>\n<h3><span id=\"81_Keep_content_and_URLs_identical_across_old_and_new_hosts\">8.1. Keep content and URLs identical across old and new hosts<\/span><\/h3>\n<p>During the parallel-running phase, both old and new servers should serve the same URLs and content. That way, regardless of which IP a user or search engine hits during propagation, they see a consistent site.<\/p>\n<p>If you plan a redesign or URL structure change, do that <strong>after<\/strong> the hosting migration is stable. Trying to change everything at once increases the chance of SEO impact.<\/p>\n<h3><span id=\"82_Ensure_SSLTLS_is_active_on_the_new_host_before_cutover\">8.2. Ensure SSL\/TLS is active on the new host before cutover<\/span><\/h3>\n<p>Install and test HTTPS on the new server before you point traffic to it. Verify:<\/p>\n<ul>\n<li>Certificates match the domain and intermediate chains are correct<\/li>\n<li>HTTP to HTTPS redirects work exactly as on the old host<\/li>\n<li>No mixed-content errors on key pages<\/li>\n<\/ul>\n<p>If you\u2019re using Let\u2019s Encrypt or another ACME-based setup, prepare challenges and automatic renewals ahead of time so that you don\u2019t hit certificate errors right after the move.<\/p>\n<h2><span id=\"9_PostMigration_Checklist_Verify_Monitor_and_Then_Decommission\">9. Post\u2011Migration Checklist: Verify, Monitor and Then Decommission<\/span><\/h2>\n<p>Once DNS changes are live and traffic is flowing to the new hosting, don\u2019t rush to delete the old environment. Use a structured post-migration checklist.<\/p>\n<h3><span id=\"91_Technical_verification\">9.1. Technical verification<\/span><\/h3>\n<ul>\n<li>Check the site from multiple networks and locations<\/li>\n<li>Confirm that <strong>A, AAAA, MX and TXT records<\/strong> resolve correctly from different public resolvers<\/li>\n<li>Send and receive test emails from various providers (Gmail, Outlook, corporate accounts)<\/li>\n<li>Verify SSL\/TLS status using browser tools and online checkers<\/li>\n<\/ul>\n<h3><span id=\"92_Application-level_checks\">9.2. Application-level checks<\/span><\/h3>\n<p>Walk through all business-critical actions:<\/p>\n<ul>\n<li>Log in \/ log out<\/li>\n<li>Contact forms and lead capture forms<\/li>\n<li>Shopping cart, checkout and payment gateways<\/li>\n<li>File uploads and downloads<\/li>\n<li>Admin actions (creating posts\/products, editing settings)<\/li>\n<\/ul>\n<h3><span id=\"93_Monitoring_and_logs\">9.3. Monitoring and logs<\/span><\/h3>\n<p>For at least a few days after cutover:<\/p>\n<ul>\n<li>Watch error logs (web server, PHP, application logs)<\/li>\n<li>Monitor resource usage (CPU, RAM, disk, database performance)<\/li>\n<li>Keep uptime monitoring active for key URLs and services<\/li>\n<\/ul>\n<p>If you see any persistent errors or slow paths that didn\u2019t exist before, investigate quickly while the old environment is still available as a reference.<\/p>\n<h3><span id=\"94_Clean_up_and_raise_TTLs\">9.4. Clean up and raise TTLs<\/span><\/h3>\n<p>Once you\u2019re confident everything is stable:<\/p>\n<ul>\n<li>Increase DNS TTLs to reduce query load and take advantage of caching (e.g. 1\u20134 hours for most records)<\/li>\n<li>Decommission the old hosting environment (after taking final backups)<\/li>\n<li>Document the new architecture (where domain, DNS, web and email now live)<\/li>\n<\/ul>\n<h2><span id=\"10_Putting_It_All_Together_A_Calm_Repeatable_Domain_and_DNS_Migration\">10. Putting It All Together: A Calm, Repeatable Domain and DNS Migration<\/span><\/h2>\n<p>Domain and DNS migrations don\u2019t have to be scary or mysterious. When you break the process into clear stages\u2014inventory, TTL planning, environment preparation, careful cutover and structured verification\u2014you can move between hosting providers with little or no user-visible downtime. In real projects at dchost.com, the most successful migrations are the ones treated as <strong>planned change management<\/strong>, not emergency surgery: all records documented, TTLs lowered early, both environments running in parallel, and a simple rollback plan ready if something looks wrong.<\/p>\n<p>Whether you\u2019re moving a single business site or dozens of customer domains, you can reuse the checklist above to make the next migration far less stressful. If you decide to move your domains, DNS or hosting to dchost.com, our team can help you review your current DNS, design a safe TTL and cutover strategy, and execute the migration step by step so your visitors and email users barely notice anything changed\u2014except for the faster, more stable hosting on the other side.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Changing hosting provider is often the right move for performance, cost or support reasons, but many teams hesitate because of one fear: breaking DNS and taking the site offline. The good news is that with the right domain and DNS migration checklist, you can switch hosting providers with zero or near-zero downtime. In this guide, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3813,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3812","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3812","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3812"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3812\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3813"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3812"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3812"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3812"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}