Migrate Subdomain Between Hosting Providers Without Downtime

## Why subdomain migration is needed Developers migrate subdomains between hosting providers for several reasons. The current host may have reliability issues, pricing may increase, or a new provider may offer better performance. Teams also migrate when their provider discontinues a service tier or when they outgrow resource limits. The core challenge is moving a subdomain without disrupting users or losing search rankings. This guide covers every step from preparation through verification. ## Pre-migration checklist Before touching DNS records, audit your current setup. Document every DNS record: A records, CNAME records, MX records, TXT records, and any SRV or CAA records. Export the complete DNS zone from your current provider. Pay attention to TTL values — TTL tells resolvers how long to cache a DNS response. If your TTLs are 3600 seconds or higher, lower them to 300 seconds at least 48 hours before migration so changes propagate within minutes. Verify your SSL certificate is active and note its expiry. Check your provider's transfer policies. Set up uptime monitoring — checks every 60 seconds give you a baseline and detect issues after switchover. ## Setting up the new hosting environment The safest approach is parallel deployment. Set up the subdomain on the new provider before changing any DNS records. Upload your website files, configure the server, and install an SSL certificate. If using a platform like is-cool-me, create the subdomain entry in the dashboard and confirm it resolves correctly. Test the application thoroughly at the staging URL — check every page, form, API endpoint, and static asset. Document the new provider's nameservers, IP addresses, and any platform-specific configuration requirements. ## DNS switchover strategies There are two strategies: atomic and gradual. An atomic switchover means updating all DNS records at once and accepting that propagation time determines the transition window. This works well when TTLs have been lowered and the new environment is fully tested. A gradual switchover uses weighted DNS routing if supported, sending a small percentage of traffic to the new server while monitoring for errors. For most subdomain migrations, the atomic approach is practical. Update DNS records at the registrar to point to the new host's IP or CNAME target. Ensure all record types are replicated — missed MX or TXT records are a common source of post-migration failures. ## TTL management for zero-downtime TTL management is the most important factor in zero-downtime migration. Forty-eight hours before switchover, reduce all relevant DNS record TTLs to 300 seconds so the DNS network flushes old cached values. During switchover, update records to point to the new hosting provider. Most resolvers will pick up new values within five to ten minutes. After confirming stability, increase TTLs back to 3600 or 86400 seconds. Never skip TTL reduction — migrating with high TTLs can leave users stranded on the old server for hours or days. ## SSL certificate considerations SSL certificates are tied to specific hosting environments and cannot be transferred between providers. Provision a new certificate on the new provider. Most modern platforms — including is-cool-me, Cloudflare, and Vercel — offer automatic SSL through Let's Encrypt, issuing certificates within minutes of DNS propagation. Ensure the old certificate remains valid until switchover is complete. During the transition window, both servers must serve valid HTTPS responses. If the old certificate expires before propagation completes, users will see browser security warnings. ## Testing the migration Test at multiple stages. Before the switchover, test the new environment using the staging URL. After updating DNS records, use the dig command to verify the subdomain resolves to the new IP. Run curl against the subdomain and inspect response headers. Check SSL certificate details for validity. Open the site in multiple browsers and devices. Test form submissions, login flows, and API calls. Monitor server logs on both hosts to watch for traffic shifts. Leave the old environment running for at least 48 to 72 hours to catch straggler traffic. ## Rollback plan Every migration needs a rollback plan. If something goes wrong after DNS has been updated, change the records back to the old server's IP. Because you left the old environment running, propagation at reduced TTLs restores traffic within minutes. Before starting, document the exact DNS record values for the old server. Test your rollback by temporarily pointing a test subdomain to the old server. A rehearsed rollback procedure transforms a high-stress situation into a controlled response. ## Post-migration verification After propagation has fully closed — typically 24 to 48 hours — run a comprehensive verification pass. Confirm all traffic is reaching the new server by checking access logs. Verify SEO signals are intact by checking canonical URLs, meta tags, and structured data. Test inbound links and redirects. Review error logs for 404s or 500s. Check email deliverability if the subdomain had MX records. Decommission the old environment only after you are fully confident. Keep a backup of the old server's data for at least 30 days. ## is-pro.dev specific tips If migrating to is-pro.dev, register your subdomain through the is-cool-me dashboard and link it to your GitHub repository for automatic deployment. The platform provisions SSL certificates automatically via Let's Encrypt within minutes of DNS propagation. Use the dashboard's DNS status indicator to confirm the subdomain resolves correctly before traffic arrives. For custom DNS records, configure them through the platform's DNS management panel. The is-cool-me community on Discord can help troubleshoot migration-specific issues. ## Conclusion with next steps Migrating a subdomain between hosting providers is a methodical process where preparation determines the outcome. Lower TTLs early, set up the new environment in parallel, switch DNS with confidence, and verify everything before decommissioning the old host. With the right approach, end users experience no downtime and search engines see a seamless transition. After migration, monitor performance, optimize caching, and document the process for future moves. ## FAQ **Q: How long does a subdomain migration typically take?** A: The actual DNS change takes seconds, but full propagation can take up to 48 hours depending on TTL settings. If you lower TTLs 48 hours in advance, most traffic switches within 5 to 10 minutes. Plan for a total window of 3 to 5 days including preparation, switchover, monitoring, and decommissioning. **Q: Will migrating affect my SEO rankings?** A: A properly executed migration with no downtime should not affect SEO. Search engines follow DNS resolution and will index the new server's content once switchover is complete. Ensure canonical URLs, robots.txt, and sitemap remain consistent between environments. **Q: Can I migrate without lowering TTLs?** A: Technically yes, but it is strongly discouraged. High TTLs mean resolvers will continue serving the old IP for hours or days, creating a split-brain situation. Always lower TTLs to 300 seconds at least 48 hours before migration. **Q: What happens to my SSL certificate during migration?** A: Your certificate is tied to the old environment and will not transfer. The new provider provisions a fresh certificate once DNS points to its infrastructure. Ensure the old certificate stays valid until switchover is complete. **Q: How do I know when propagation is complete?** A: Use dig or online DNS lookup tools that query resolvers from multiple locations. Monitor server access logs — when traffic on the old server drops to near zero, propagation is effectively complete.