Site migrations are thankless work. Nobody notices when they go right. Everyone notices when they go wrong.
1. Don't handle your URL redirections until after the fact
Some of the worst situations I've seen in twenty years came from devs who moved an entire site to a new URL scheme and didn't bother mapping redirections.
It breaks every previous link to your content: internal documents, email signatures, bookmarks. It destroys your organic SEO rankings by confusing crawlers and leaving broken links in the search results.
How I know:
I've cleaned up migrations where companies lost six months of rankings because nobody thought to check Google Search Console or talk to stakeholders about non-obvious landing pages.
The fix:
Build a spreadsheet. Old URL, new URL, HTTP response code. Check your analytics for what actually gets traffic.
- Network layer: Cloudflare page rules
- Web server/load balancer: Nginx or equivalent
- Application layer: CMS or framework routing
2. Don't bother testing your forms, they probably work fine
Did you test forms after launch? Did you enable CAPTCHA? Is the POST destination updated for production?
How I know:
"We haven't been getting any leads for a few weeks. Normally we get a couple a day. Our PPC conversions have tanked too."
The fix:
Test forms in staging. Test them again after launch. Test with multiple people. Fill them out yourself. Watch submissions flow into your CRM or email.
RULE #1: DON'T BLOCK THE MONEY.
3. Assume your asset paths are okay if you can see images
Asset paths (images, videos, PDFs, hyperlinks) often still point to old infrastructure after migration.
You're looking at paths like: staging.example.com/white-paper.pdf instead of example.com/white-paper.pdf
The fix:
After launch, validate all asset paths. Crawl the site with Screaming Frog. Check every image, every PDF, every embedded resource.
4. Don't coordinate schedules with the person changing DNS
You need to coordinate with someone to "flip the switch." Sometimes you need a support ticket. Sometimes it's a person in another time zone.
The fix:
Coordinate not just the launch, but access for rollbacks or updates. Find out where the DNS contact is physically located. Understand their availability. Make sure TTL is set short enough for quick reversions.
5. Don't test from different locations if it works fine on your machine
DNS propagation depends on a lot of things. ISP caching, propagation delays, corporate firewalls—these are all reasons why you see the new site and someone else doesn't.
The fix:
Get third-party validation. Use tools like GeoPeeker. Connect via VPN to test from different geographies. Ask people on Slack.
Hire a pro
Migrations are high-stakes. If your site has any meaningful traffic or revenue attached to it, hire someone who's done this before.
A few other things:
- Don't make launch announcements before validating everything works
- Cut over traffic gradually if possible, don't flip everything at once
- Keep your composure. Every launch has turbulence.
Measure twice, cut once.
Cookie Preferences