Site migrations are thankless work. Nobody notices when they go right. Everyone notices when they go wrong.
Maybe you're getting a shiny new redesign from that all-in-one agency. Maybe you're moving hosting providers. Maybe you're consolidating two sites after a merger.
Every launch has turbulence. The goal is to avoid disasters. Here's how to guarantee you'll have one.
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. Secret URLs, old campaign pages, archived resources - all dead.
The fix: Build a spreadsheet. Old URL, new URL, HTTP response code. Check your analytics for what actually gets traffic. Use this as an opportunity to cull dead pages, simplify query strings, update robots.txt.
Then decide which layer handles redirects:
- Network layer: Cloudflare page rules
- Web server/load balancer: Nginx or whatever
- Application layer: CMS or framework routing (Craft, WordPress, Next.js. etc.)
Pick one. Document it. Make sure the other layers know the plan. Colliding redirect rules are hell to debug.
Use Screaming Frog to validate everything after launch. It's not just an SEO tool, it's a great general-purpose web dev debugging tool.
2. Don't bother testing your forms, they probably work fine
"Hey, we haven't been getting any leads for a few weeks. Normally we get a couple a day. Our PPC conversions have tanked too."
SHIT.
Did you test forms after launch? Did you enable CAPTCHA? Is the POST destination updated for production? Are validation rules working? Does the success redirect go somewhere real?
How I know: I've gotten this call from panicked marketing directors who just burned ad spend sending traffic to a broken form. Maybe reCaptcha or Turnstile wasn't toggled on. Maybe the CRM API wasn't whitelisted. Maybe submissions are posting to your staging endpoint.
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. Verify everything works.
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.
Iām looking at you WPENGINE!
If you're still hosting the old site publicly, everything looks fine. Then you sunset the old server a month later and every image breaks. Every PDF 404s. Every download link dies.
How I know: I've seen this on sites with hundreds of PDFs or thousands of product images. It's a nightmare to untangle, especially when you don't have clean backups or documentation of where everything lived.
You're looking at paths like:staging.example.com/white-paper.pdf instead of example.com/white-paper.pdf
And nobody notices until it's too late.
The fix: After launch, validate all asset paths. Crawl the site with Screaming Frog. Check every image, every PDF, every embedded resource. Make sure nothing points to old infrastructure.
4. Don't coordinate schedules with the person changing DNS
On smaller projects, the dev might be the chef, cook, and bottlewasher, controlling everything end-to-end. But most companies have internal IT or use an MSP for DNS, email, and security.
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.
How I know: I've dealt with East Coast vs. West Coast timing issues. I've coordinated with Italian IT vendors through language barriers. I've been stuck when someone flipped DNS and then left for the weekend, what a helpless feeling.
When things break badly on the internet, DNS is usually the culprit. Hell, Cloudflare had a massive outage today. AWS had one a few weeks ago. DNS is fragile.
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 that you can revert quickly if needed.
Also coordinate DNS for the old infrastructure, staging subdomains, legacy domains, whatever you're sunsetting.
Don't fiddle with DNS if you don't know what you're doing.
5. Don't test from different locations if it works fine on your machine
DNS propagation depends on a lot of things. Every dev has been burned by this.
"It works on my machine" is a trope for a reason. ISP caching, propagation delays, corporate firewalls, in-house DNS servers - these are all reasons why you see the new site and someone else doesn't.
How I know: I've seen launches where the dev team sees the new site but half the company still sees the old one. Or customers on mobile networks can't reach it. You think it's live. It's not.
The fix: Get third-party validation. Use tools like GeoPeeker (free). Connect via VPN to test from different geographies. Check on your phone using cellular, not WiFi. Ask people on Slack: "Does it load for you?"
Don't trust your local machine.
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 you've validated everything works
- Cut over traffic gradually if possible, don't flip everything at once
- Keep your composure. Every launch has turbulence. The goal is avoiding disasters, not perfection.
When migrations go right, nobody notices. When they go wrong, it's horrendous.
Measure twice, cut once.