Fixing Hardcoded IPs and Absolute URLs After a Move

The vast majority of sites work immediately after migrating, because database names and file paths are preserved. The occasional exception is a site with a hardcoded server IP or absolute URLs baked into its code or config. This guide helps you find and fix those rare cases.

Why hardcoded values cause trouble

Your server’s IP changes when you move to iWebVault — that’s expected and is why DNS needs updating. If your application has the old IP written directly into a config file or database (rather than referencing a hostname), it’ll keep trying to reach the old server until you update it.

Where hardcoded values hide

• Application config files referencing a database by IP instead of localhost
• Absolute URLs (full http://oldserver/... links) saved in a database
• API integrations or webhooks pointing at the old server IP
• Hardcoded paths that include the old server’s hostname

Finding them

Search your codebase and configuration for the old server’s IP address and hostname. For database-stored URLs, a careful search of the relevant tables (or a reputable search-replace tool for your platform) reveals absolute links. Knowing your old IP makes this a quick, targeted search rather than a hunt in the dark.

Fixing them the right way

1. Replace a hardcoded old IP for the database with localhost where the database is local
2. Update absolute URLs to your domain (or make them relative/protocol-relative)
3. Point external integrations at your domain, not a raw IP, so future moves don’t break them
4. Re-test the affected feature after each change

Preventing it next time

Wherever possible, reference services by hostname or domain rather than raw IP, and use relative URLs in your site. That way a future migration — to a new server or back — needs no code edits at all.

Why this is rare but worth knowing

Modern applications are written to avoid hardcoding server-specific values precisely because it makes moving hosts painful. WordPress, for instance, uses localhost for the database and stores its site URL as a domain, not an IP. So most migrations need zero edits. The exceptions are older sites, bespoke applications, or setups where someone hardcoded an IP for a quick fix and never changed it back.

A systematic way to find hardcoded values

If you suspect hardcoded values, search methodically. Know your old server’s IP and hostname, then search your application’s files and configuration for both. For values stored in a database (like absolute URLs in content), use a reputable search-and-replace tool built for your platform rather than editing raw tables by hand.

• Search config files for the old IP and old hostname
• Search the codebase for absolute http:// URLs containing the old server
• Check API/webhook settings for the old IP
• For databases, use a platform-appropriate search-replace tool

Fixing without breaking

The safest fixes favour portability: point local database connections at localhost, change absolute URLs to your domain or make them relative, and reference external services by hostname rather than raw IP. Each change should be followed by testing the affected feature, so you catch any mistake immediately rather than discovering it later.

The WordPress-specific note

For WordPress, after a like-for-like migration you generally don’t need any of this. If you also changed your domain, that’s when a URL search-replace applies — and a trusted plugin or WP-CLI’s search-replace handles it safely, including serialised data. A straight host move with the same domain needs nothing.

Designing for the next move

The lasting fix is to stop hardcoding. Reference your database as localhost, use relative or domain-based URLs, and point integrations at hostnames. Do that and future migrations — whether to a new server or a rollback — require no code changes at all, which is exactly how a portable site should behave.

What’s next

• Migrating a WordPress Site
• How Your Databases Are Preserved
• What to Check After Your Migration Completes

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.

Key takeaways

Most sites need no edits after migrating because database names and paths are preserved. The rare exception is a hardcoded old server IP or absolute URL in config or the database — search for the old IP and hostname, replace local DB references with localhost, make URLs relative or domain-based, and back up before any database search-replace. Reference services by hostname so future moves need no edits.

How do I know if my site has hardcoded values?

If your site works immediately after migrating, it doesn’t — and most don’t. If a specific feature fails (a database connection, an integration), search your config and database for the old server’s IP and hostname. Finding the old IP somewhere is the sign; replacing it with localhost or your domain is the fix.

Common mistakes to avoid

• Editing a database directly without taking a backup first
• Replacing a hostname-based reference that didn’t need changing
• Missing absolute URLs stored inside database content
• Leaving integrations pointed at the old raw IP

Remember that this whole topic is the exception, not the rule — most sites need none of it. If your site works the moment it’s migrated, there’s nothing to do here. Only chase hardcoded values when a specific feature misbehaves, and when you do, back up first and prefer portable references so the next move needs no edits at all.