The Boring Bits That Break Migrations

Domain Ownership Determines Whether You Can Migrate at All

Your domain name ties your entire online presence together. Lose control of it, and you lose everything—your website, your email, your customer trust. Before any migration, verify and secure your domain ownership, because no technical preparation matters if you cannot point your domain where you need it to go.

Verify your registrar credentials. Many founders discover too late that their domain lives under a contractor's account, a former co-founder's email, or a web agency that closed two years ago. Log into your registrar directly and confirm the administrative contact email belongs to you. If someone else holds the keys, negotiate transfer before you begin any migration work. This conversation gets harder once you are mid-migration with a deadline approaching.

Check your transfer lock status. Most registrars impose a 60-day lock period after registration or transfer during which you cannot move the domain elsewhere. This lock prevents unauthorized transfers, but it can trap you if switching registrars is part of your migration plan. Check your registrar's policies and build that constraint into your timeline. A lock that expires three days after your planned launch date means your planned launch date is wrong.

Confirm your registration expiration date. An expired domain can be snatched by squatters within hours. Set up auto-renewal with a payment method that will not fail—not the corporate card that expires next month, not the account your finance team occasionally freezes for audits. Add calendar reminders for manual review. The $12 annual registration fee is the cheapest insurance you will ever buy.

DNS Configuration Determines Whether Users Reach Your New Server

DNS is the phone book of the internet. When someone types your domain, DNS tells their browser which server to contact. During a migration, you are changing your listing—and the world needs time to learn the new one. Misconfigure DNS, and your users reach the old server, the wrong server, or no server at all.

Reduce your TTL values 48 hours before migration. TTL (Time To Live) tells DNS servers how long to cache your records before checking for updates. If your TTL sits at 86,400 seconds (24 hours) and you change your server IP, some visitors will still reach your old server for a full day. Lower your TTL to 300 seconds (five minutes) well in advance. This gives the old, high TTL time to expire from caches worldwide, so when you make the actual change, propagation happens in minutes rather than hours.

Export your complete DNS zone file. Your domain likely has more than an A record pointing to a server. You probably have MX records for email, TXT records for domain verification, CNAME records for subdomains, and SPF/DKIM records for email authentication. Export everything before making any changes. Missing a single MX record can silently break email delivery for days—and by then, you have lost customer inquiries, password reset requests, and possibly a few deals.

Identify every record your new server must replicate. Walk through your exported zone file and confirm your new hosting environment can handle each record type. Some hosting platforms restrict certain DNS configurations or require specific record formats. Document gaps now so you can address them before cutover day, not during it when your Slack is filling with "is the site down?" messages.

SSL Certificates Determine Whether Browsers Trust Your New Server

SSL certificates encrypt the connection between your visitors and your server. Without valid SSL, modern browsers display a full-page warning: "Your connection is not private. Attackers might be trying to steal your information." Most visitors click "Back to safety" and never return. Search engines penalize these sites in rankings. A botched SSL transition makes your site appear compromised to every visitor who arrives.

Provision certificates before changing DNS. The most common migration mistake is changing DNS to point to a new server that lacks a valid SSL certificate. Visitors arrive, see the security warning, and leave. Your bounce rate spikes. Your support inbox fills with "I think you got hacked" emails. Use DNS-based domain validation or temporarily configure your new server to respond on a different port while you obtain certificates. Let's Encrypt provides free certificates, but they still require proper configuration before you redirect traffic.

Configure automatic renewal immediately. SSL certificates expire—typically every 90 days for free certificates or annually for paid ones. An expired certificate triggers the same browser warnings as no certificate at all. Configure automatic renewal using tools like Certbot, and set up monitoring to alert you if renewal fails. A 3 AM renewal failure alert is inconvenient; returning Monday to find bounce rates tripled and a support queue of 47 "is your site safe?" tickets is the alternative.

Verify your full certificate chain. A certificate is only valid if browsers can trace it back to a trusted root authority through intermediate certificates. Some server configurations omit these intermediates, causing the site to work in Chrome on your laptop but fail in Safari on your customer's iPhone. Use SSL Labs or similar testing tools to confirm your full chain is properly installed. Test from multiple devices and networks—your office WiFi might cache a working configuration that masks problems your customers will hit immediately.

Execution Sequence Determines Whether Users Experience Downtime

Understanding domains, DNS, and SSL separately is not enough. Executing them in the wrong order creates downtime. The correct sequence protects your users from ever seeing an error. The wrong sequence guarantees that some portion of your traffic hits a broken or insecure server.

Execute the cutover during low-traffic hours. Even with a low TTL, some users will experience the transition. Choose a time when your traffic is lowest—typically late night or early morning in your primary market. If 80% of your customers are in North America, 3 AM Eastern means you affect hundreds of users instead of thousands. This also gives you maximum runway to respond if something goes wrong before peak traffic returns.

Monitor both servers throughout the transition. After changing DNS, watch access logs on both your old and new servers. Traffic should gradually shift to the new server as cached DNS records expire worldwide. If you see error rates spiking on the new server—500 errors, SSL handshake failures, connection timeouts—you can quickly revert DNS while you troubleshoot. A five-minute TTL means a five-minute recovery time. A 24-hour TTL means a 24-hour problem.

Decommission the old server only after traffic fully shifts. Do not shut down your old server immediately after changing DNS. Some users will continue reaching it for hours due to cached DNS records, corporate proxy servers, or mobile networks with aggressive caching. Keep both servers running until access logs on the old server go quiet for at least 24 hours. Only then can you safely decommission it. The extra day of hosting costs is trivial compared to the support burden of users hitting a dead server.

Your Next Steps

1. This week, complete your domain audit. Log into your registrar. Verify the administrative contact email is yours. Check your transfer lock status and expiration date. Fix any issues before they become emergencies.
2. Next week, complete your DNS preparation. Reduce your TTL values to 300 seconds. Export your complete zone file. Walk through every record and confirm your new server can replicate it.
3. The week after, complete your SSL and cutover. Provision your certificates on the new server. Configure automatic renewal. Verify your certificate chain with external testing tools. Then—and only then—execute the migration.