Tutorial · migration-hosting · Published 2026-08-16 · 4 min read
What to check when your server IP address changes
A server IP change without downtime: lower TTL first, update A records, allowlists, email and any hardcoded IP you rely on.
The problem an IP change creates
A server IP change is a creeping cutover, not a single flag. The website's A record moves, but so do every DNS record, allowlist, email server config, firewall rule, and piece of monitoring that references the old number. Miss one and the symptom looks random: the site loads, but the mail server rejects the connection, or the payment gateway stops taking callbacks.
Plan the change like the DNS record moves one: sequence the TTL, point, verify, then clear the old. The failure mode that gets most sites is the ones that forget the caches.
Step 1: drop the TTL in advance
The TTL on your current record controls how long DNS resolvers hold it. Lower the TTL at least a day before the cutover (and for the record you are changing):
- Open the DNS provider's panel and set the A record TTL to 300 seconds, or 60 if your provider allows it.
- Wait the old TTL to flush, so the new value is already in force when you change the IP.
- Keep the low TTL during the cutover; raise it back to 3600 or 86400 once everything is stable.
Skipping this step means cached resolvers keep sending traffic to the old server for up to its old TTL, which is exactly the window where visitors get the old site or nothing.
Step 2: update the record layer
Change the IP at the DNS provider, not the domain registrar:
| Change | Where |
|---|---|
| A record (IPv4) | DNS panel |
| AAAA record (IPv6, if used) | DNS panel |
| CNAME targets, MX/SPF/TXT values | Only if they embed the old IP (rare but check SPF ip4: fragments) |
| Cloudflare proxied record | The edge IPs are stable; only update the origin under Cloudflare DNS |
If the domain uses Cloudflare in proxy mode, the A record still points at the origin IP but the visitor-facing answer is Cloudflare's edge. The proxy mode article explains why the origin IP change is then near-invisible. With plain DNS, the A record edit is the entire cutover.
Step 3: update everything that pins the IP
The strip-down list beyond the DNS panel:
- Email: the mail server config, SPF
ip4:include if either was the old IP, and any external service (Google Workspace, Outlook) that filters on the sender. - Firewall and security: the security group or firewall rule blocking the new IP instead of the old one, and the fail2ban/panel IP allowlist.
- Payment gateways and webhooks: any callback URL or IP verification that must reach your server from an external API over TLS with a hardcoded IP.
- Monitoring: uptime checks, pingers and the uptime monitor config all reference the old IP.
- Backups and cron: the backup job pushing to another server, the cron on the edge, and any source config that points at the old box.
- DNS-provider status: some panels have an "IP record" synced to the hosting account's own DNS, which is a separate place a stale IP hides.
Step 4: cut over and verify like a skeptic
On cutover day:
- Set the A record to the new IP and wait for the DNS change to apply (check with propagation tools, not the local cache).
- Verify HTTP over both HTTP and HTTPS, because a certificate on the old IP fails when the A record moves.
- Verify email send and receive, not the "server up" signal.
- Watch the error logs for the first 24 hours: connection refused (old IP still in use) or 5xx mean the overlap is not clean.
The single sign of success is that the search console crawl keeps finding the new IP, and that external callbacks still verify the handshake. Watch logs on the old server until its traffic drops to zero before you retire it.