When your website origin IP changes, any integration that connects directly to the old numeric address can keep pointing at the old server. The usual suspects are firewall rules, payment and shipping callbacks, email authentication, uptime monitors, and publishing or sync tools set to an IP.
Your origin IP is the numeric address of the server that actually hosts your site files. Most visitors use your domain name, which follows the new address once DNS updates. Direct IP connections skip DNS, so they do not follow the move on their own.
Table of Contents
- Why DNS Updates Miss Some Connections
- Which Integrations Still Point at the Old Server?
- How Do You Find Hardcoded IP References?
- What Should You Update First?
Why DNS Updates Miss Some Connections
DNS maps your domain name to the new server. Browsers and most normal visits use that mapping.
Anything pointed straight at the IP never asks DNS, so it stays on the old path. That split often confuses teams. The site looks fine in a browser, yet orders, form alerts, or content syncs keep going to the old machine.
Which Integrations Still Point at the Old Server?
Start with places where someone typed the IP for speed or control. Firewalls, CDNs, and security filters often allowlist the origin IP. Payment gateways, shipping tools, CRMs, and marketing platforms may also send callbacks to a fixed IP.
WordPress and Drupal sites add a few more spots. Cache plugins, security plugins, cron jobs, XML-RPC clients, and custom modules can store the IP. Check scheduled tasks and staging-to-live sync profiles too.
- firewall and host allowlists for admin access, APIs, and staging
- CDN, proxy, or load-balancer origin settings
- payment, booking, shipping, and CRM webhooks
- outgoing email rules such as SPF, relays, and deliverability filters
- uptime, security, backup, and performance monitors
How Do You Find Hardcoded IP References?
Write down the old and new IPs before you change anything. Search site settings, plugin settings, theme functions, custom modules, and environment files for the old address.
Include documentation, deploy scripts, and team runbooks. Keep both servers readable in logs during the switch. Requests still hitting the old server reveal which integration you missed.
- search code and config files for the old dotted address
- review DNS, CDN, firewall, and hosting dashboards for origin entries
- check gateway, CRM, email, monitor, and backup dashboards for callbacks
- review cron jobs, workers, queues, and scheduled publishing tasks
- test forms, checkout, login, search, and media uploads after the move
What Should You Update First?
Update controls that block traffic first. Change firewall allowlists, CDN origins, access rules, and rate limits to accept the new IP. A blocked origin can look like downtime even when DNS is correct. Next fix two-way paths.
Update callbacks, API keys tied to an IP, email sending rules, and monitor targets. Repoint backups, sync jobs, staging links, and deploy scripts. Leave the old server online briefly and watch its access logs. Move any straggler to the new address, then shut down the old plan only after traffic stops.
