A WordPress Migration Story About DNS Propagation, Missing Images, and Database/File Mismatches
WordPress migrations look simple – until they aren’t.
If you’re a web designer, developer, agency owner, or business owner dealing with a broken website, this story will feel uncomfortably familiar.
Every web professional has that migration story.
This one involved DNS propagation, WordPress media files, partial restores, and a MacBook that sounded like it was preparing for liftoff.
It Started as a “Simple” WordPress Migration
The task was routine:
- Database export and import
- WordPress files moved
- Admin access confirmed
- Local preview tested
The site loaded. Images appeared. Confidence was dangerously high. This is usually the exact moment the internet decides to humble you.
The Website That Only Worked Sometimes
Once the site went live, it existed in two parallel realities:
- In one version, everything worked perfectly
- In the other, every image had vanished
Same database. Same URLs. Same WordPress install. Completely different results.
This is where browser tabs multiply, terminal windows reopen, and you start wondering whether DNS is a technical system or an emotional one.
The Hosts File Lie (Also Known as False Hope)
Eventually, I did what developers do when logic fails: I edited my hosts file. Instant success.
- Images were back
- Pages rendered perfectly
- Everything looked fixed
Except for one small detail:
It only worked on my computer.
The rest of the world was still staring at broken images. At this point, my MacBook was at peak memory usage and quietly drafting a resignation letter.
The Part No One Explains Well About WordPress
Here’s the detail that causes most WordPress migration disasters:
WordPress stores content in two separate places:
- Image references live in the database
- Actual image files live on the server filesystem
If you restore:
- the database from one point in time, and
- the uploads directory from another point in time
You get a site that:
- Remembers images perfectly
- Cannot physically find them
No fatal errors. No warnings. Just empty image containers and quiet judgment.
Why Were NO Errors Showing?
This is what makes these issues so brutal:
- WordPress does not verify file existence on load
- Browsers don’t throw errors for missing media paths
- Hosting dashboards often show everything as “healthy”
To a business owner, it looks random. To junior developers, it looks cursed. To experienced developers, it smells like a partial restore.
The Fix Wasn’t Code (And That’s the Point)
The solution was not:
- Installing another plugin
- Reinstalling WordPress
- Clearing cache for the 30th time
- Touching a single line of PHP
The fix was restoring the correct filesystem snapshot that matched the database. Sometimes the problem isn’t development.
It’s infrastructure alignment.
Lessons Learned the Hard Way
- DNS is not instant and never will be
- “It worked locally” proves nothing
- Multisite history lingers longer than expected
- WordPress will happily run without media files
- If your laptop slows down, close tabs… or buy a new one
Why This Matters for Clients and Agencies
Most website disasters aren’t caused by bad code – sometimes.
They’re caused by:
- Partial backups
- Mismatched restores
- Invisible hosting layers
- Assumptions made under time pressure
This is exactly how:
- Business owners lose trust in their site
- Agencies inherit “mystery problems”
- Developers burn hours chasing ghosts
My Takeaway Here
These problems are fixable.
But they require:
- Experience with WordPress internals
- Understanding of hosting infrastructure
- Patience
- And occasionally, a very calm support ticket
Need Help With a WordPress Migration or Cleanup?
If you’re:
- Planning a WordPress migration
- Moving hosting providers
- Dealing with broken images or missing files
- Inheriting a site that someone else partially restored
This is exactly the kind of issue that experienced planning prevents.
If you want it done cleanly, without surprises, downtime, or laptop trauma, feel free to reach out.
