The migration checklist we run before anyone touches DNS

Why pre-launch verification matters

Site migrations carry structural risk. When an enterprise platform changes domain architecture or URL patterns, organic traffic often collapses. We have spent twelve years managing technical programs and re-platforms for large retail and travel brands. The root cause of post-launch traffic loss is rarely the new platform itself. Traffic loss happens because engineering teams change DNS records before verifying the underlying technical foundation.

At Waverider SEO, we run a pre-DNS checklist on every engagement. This checklist forms the foundation of the Map stage in our Tidewater™ method. We do not permit DNS cutovers based on developer estimates or soft launch promises. Engineering receives green light sign-off only after every technical requirement meets our audit criteria.

When a US home-goods retailer with 1,800 SKUs and 12M sessions a year prepared for a platform migration, we applied these exact controls. The result was a zero-loss migration that grew organic revenue +63% in 11 months while cutting crawl waste down 71%. Achieving those outcomes requires systematic discipline well before traffic switches to new servers.

Building complete redirect maps

Redirect maps fail when teams rely on broad wildcard rules instead of explicit URL mapping. A broad regex rule often sends high-value legacy pages to irrelevant category pages or the homepage. That dilutes page equity and confuses search engines.

Mapping page equity to destination URLs

We build redirect maps from historic log files, web analytics, and comprehensive site crawls. Every indexable legacy URL must match a specific, relevant page on the new destination structure.

We verify that every target URL returns an HTTP 200 status code before launch. If a legacy page lacks a direct equivalent, we map it to the closest parent category rather than a generic landing page.

Testing redirect headers and chains

Redirect chains waste crawl budget and slow down indexation. We require direct 301 redirects from old URLs to new canonical destinations without intermediate steps.

We test redirect tables in an isolated staging environment. Our testing scripts send automated HTTP requests to verify that response headers contain correct location values without intermediate hops. We also verify that parameter strings transfer cleanly without causing infinite loops.

Executing staging parity crawls

A staging site must match production logic before code moves to live servers. We run full parity crawls across staging environments to spot silent structural errors.

Auditing canonical tags and indexation directives

Staging environments often leak configuration errors into production. We inspect every page template on staging to verify canonical tags match the target domain.

If canonical tags on staging point back to staging hostnames or staging IP addresses, search engines will index the wrong domain upon release. We verify that meta robots directives allow indexation on production while remaining restricted on staging through server header rules. Guides from developers.google.com/search outline standard HTTP response headers for crawler control.

Verifying structured data and link architecture

We compare structured data schemas across legacy and new page templates. Missing Schema.org markup removes rich snippet eligibility and damages entity understanding. You can inspect schema standards at schema.org.

Internal linking patterns must also maintain structural depth. We compare internal link counts per page between old and new environments. If new navigation elements strip links from deep product pages, those pages lose internal authority and crawl frequency immediately after launch.

Capturing server log baselines

Search engine spiders leave exact footprints in server log files. Before any DNS change occurs, we establish a clean log file baseline over weeks of normal site operation.

Measuring crawler behavior

Log baselines show how Googlebot and other crawlers discover, fetch, and render your estate. We track daily request counts, response code distributions, and crawl frequency by directory.

This baseline reveals how search engines allocate crawl budget across your infrastructure. Knowing normal crawl patterns allows us to identify anomalies within minutes of a DNS switch.

Preparing post-launch log monitoring

We configure real-time log ingestion pipelines prior to launch day. When DNS points to new IP addresses, our monitoring tools compare live spider requests against the historical baseline.

If spider activity drops unexpectedly or 404 response rates spike above baseline limits, engineering receives immediate alerts. Log analysis removes guesswork from migration monitoring.

Defining explicit rollback criteria

Every migration requires strict rollback criteria agreed upon before launch. Without pre-set boundaries, teams waste critical hours debating whether to keep a broken deployment live.

Setting technical threshold triggers

We define objective technical conditions that automatically trigger a launch pause or DNS rollback. Technical governance requires setting clear triggers before deployment. These triggers include:

• Redirect failure rates exceeding baseline limits on sampled legacy URLs.
• Canonical tag misconfigurations affecting core page templates.
• Server response times increasing significantly over baseline measurements.
• Server log files showing widespread 500 error spikes from search spiders.
• Unintended robots.txt blockages preventing search engine crawlers from reaching key sections.

Establishing the rollback protocol

Engineering must maintain a tested rollback path. We verify that old servers remain active and accessible during the cutover window.

If launch metrics breach our rollback triggers, the lead technical engineer executes the revert script immediately. Preserving search visibility takes priority over meeting arbitrary launch deadlines.

Running the formal go/no-go meeting

Prior to scheduled DNS updates, we host a mandatory go/no-go meeting. Attendees include the Head of Enterprise SEO, Lead Technical Architect, VP of Marketing, and Product Manager.

Reviewing checklist sign-offs

We review every item on the pre-DNS checklist during this meeting. Each functional lead must present verified proof of completion for their domain:

SEO leads verify redirect map completeness, staging parity crawl results, and canonical tag accuracy. Technical leads confirm server log monitoring pipelines, edge redirect rules, and DNS TTL reductions. Engineering leads validate staging environment parity, staging server stability, and rollback script readiness. Analytics leads confirm event tracking parity, revenue attribution tags, and baseline measurement dashboards.

Making the launch decision

Unanimous approval is required to proceed. If a single critical check fails or remains unverified, we postpone the DNS switch.

Pausing a launch to fix a redirect map error costs very little. Launching with broken technical architecture can damage organic revenue for quarters. Our pre-DNS checklist ensures that when DNS changes finally execute, your organic estate remains protected.