Migration traffic drops need pre-defined thresholds, not panic
Summary
Brendan Bennett's migration disaster recovery framework argues that defining acceptable traffic loss thresholds before launch prevents post-migration panic and misdiagnosis.
Without pre-set benchmarks, every traffic dip feels like a crisis. The real work is calculating projected loss and revenue impact upfront, then comparing weekly actuals against those baseline numbers.
Set traffic, revenue, and lead thresholds before migrating and document rollback triggers in advance. Verify your analytics setup didn't change during the migration, then separate traffic metrics from business metrics to determine whether the drop is actually problematic.
What happened
Brendan Bennett, Principal SEO Consultant at Candour, published a [disaster recovery framework for site migrations](https://sitebulb.com/resources/guides/when-website-migrations-go-wrong-a-practical-guide-to-disaster-recovery) as part of Sitebulb’s three-part migration series. The framework centers on a simple argument: if you didn’t define acceptable traffic loss thresholds before the migration, every post-launch dip will feel like a crisis.
Bennett’s approach covers how to confirm whether a drop is genuinely problematic, how to verify your analytics data isn’t misleading you, and a “parity-obsessive” diagnostic method for isolating longer-term issues.
Why it matters
Most migration monitoring starts after launch, when someone notices a traffic graph heading south. Bennett argues the useful work happens before launch, when teams calculate projected traffic loss and estimated revenue impact. Those pre-migration numbers become the benchmark dataset for weekly comparison. Without them, post-migration monitoring is just staring at graphs and guessing.
The distinction between traffic drops and business metric drops is worth calling out. If revenue, transactions, and leads hold steady despite lower traffic, the migration may have shed low-value sessions. Panic in that scenario wastes time. If revenue is actually declining, that’s when exit plans and rollback decisions need pre-defined triggers.
Bennett points to the WooCommerce domain migration as a case study. At some point, WooCommerce presumably hit a threshold where waiting for recovery wasn’t viable and rolled back to the old domain entirely. He frames that not as failure but as a planned off-ramp that someone had the sense to define in advance.
Google’s own documentation says it takes around 180 days after submitting a change of address for the old domain to stop being treated as a primary entity. Bennett reports seeing migrations where recovery takes over a year, with long-tail impacts surfacing well after the main traffic line stabilizes. There is no universal recovery timeline.
What to do
Set thresholds before you migrate. Define acceptable ranges for traffic loss, revenue impact, and lead volume. Agree on these numbers with stakeholders in advance. Document what triggers a rollback decision versus what triggers a “wait and monitor” response.
Ask four questions before entering disaster recovery mode. Bennett suggests these checks:
- Have you hit any danger thresholds for revenue or leads?
- Have you given Google enough time to process the migration?
- Are metrics moving in the right direction, even incrementally?
- Is your data actually sound?
Verify your analytics configuration hasn’t changed. Migrations are one of the most common moments for GA4 settings to shift. Cookie consent configurations, event tracking, and tag placement can all change during a relaunch. If your measurement changed alongside the migration, you may be comparing different data sets and misdiagnosing the problem. Check Google Search Console data alongside GA4 to cross-reference. GSC measures impressions and clicks independently of your site’s analytics setup, so discrepancies between the two can reveal whether the problem is real traffic loss or broken measurement.
Separate traffic metrics from business metrics. Look at revenue, transactions, and lead volume before fixating on session counts. A traffic drop with stable conversions is a different situation from a traffic drop with declining revenue, and the response should differ accordingly.
Plan rollback criteria in advance. Define the conditions under which you would revert the migration. Having this documented before launch removes the emotional decision-making that happens when graphs are falling and clients are calling.
Watch out for
Analytics config drift during migration. GA4 cookie consent settings, event definitions, and tag placements frequently change during a site relaunch. If pre-migration and post-migration data aren’t measuring the same thing, your recovery analysis is built on bad comparisons. Audit your analytics setup as a first step before drawing conclusions from the data.
Premature panic over normal volatility. Some traffic loss and ranking instability after a migration is expected. Google needs time to recrawl, reindex, and consolidate signals. Reacting to a two-week dip by making further changes can compound the problem. Stick to your pre-defined thresholds and timelines before making additional interventions.