Website Monitoring During a Migration: A Pre-Launch and Post-Launch Checklist

Most migration disasters aren't caused by the migration itself. They're caused by nobody watching closely enough during the narrow window when the old system is winding down and the new one is taking over the exact moment when a missed redirect, an incomplete DNS cutover, or a forgotten dependency does the most damage, silently, before anyone notices.

Website migration monitoring isn't a single tool or a single check. It's a discipline that spans three distinct phases before, during, and after each with its own specific risks and its own specific checklist. Treating a migration as "done" the moment the new site loads is how teams miss the problems that actually matter.

Why Migrations Need Their Own Monitoring Discipline

Ongoing monitoring is built around a stable baseline: you know what "normal" looks like, and you alert on deviation from it. A migration temporarily destroys that baseline on purpose. DNS is changing. Infrastructure is changing. URLs may be changing. In this window, your regular monitoring setup is often either not configured for the new environment yet, or still watching the old one that's being phased out leaving exactly the highest risk period with the least amount of real oversight.

Migration downtime is rarely one dramatic failure. It's usually a collection of smaller, individually survivable issues a missed redirect here, an unmonitored dependency there that compound into a worse outcome than any single mistake would have caused alone, precisely because nobody was watching closely enough to catch and fix them quickly.

The Operational Risk of Under Monitoring a Migration

A migration introduces specific failure modes that don't exist during normal operation:

• DNS propagation creates a window of inconsistency by design. Some visitors will hit the new infrastructure before others do, purely based on caching and TTL timing, which is normal but it also means a problem on the new side won't affect everyone at once, making it easy to miss in early spot checks.
• Redirects are trivial to get almost right, and almost right still breaks things. A redirect map covering 95% of old URLs sounds like a success until you consider that the missing 5% might include your highest traffic legacy pages, indexed by search engines and bookmarked by returning customers.
• Dependencies get forgotten in the excitement of the new system. A third party integration, a webhook endpoint, an API a partner relies on anything not front and center on the new site is easy to overlook until someone downstream notices it's broken.
• The rollback window is often shorter than people assume. The longer a problem goes unnoticed post migration, the more difficult (and sometimes impossible) it becomes to cleanly roll back, since the old system may already be winding down or losing data currency.

Without a deliberate, phased monitoring approach, teams typically discover migration issues the way they discover any unmonitored failure: through a drop in traffic, a customer complaint, or a search console warning usually after real damage (lost SEO equity, lost conversions, a frustrated partner integration) has already occurred.

Phase 1: Pre-Launch Checklist

Complete these before any DNS or traffic changes happen.

☐ Document every existing URL structure and its expected redirect destination.
Build a comprehensive redirect map before launch, not during this is the single highest leverage step in preventing lost SEO equity and broken bookmarks.

☐ Lower DNS TTL well in advance of the planned cutover.
Reducing TTL days ahead of the actual change means old cached records expire faster once you do make the switch, giving you a faster, more predictable propagation window.

☐ Set up monitoring on the new environment before it goes live.
Confirm uptime, SSL, and core functionality checks are already configured and passing against the new infrastructure while it's still only reachable internally or via a staging URL.

☐ Inventory every third party dependency and integration.
List every API, webhook, embedded script, and partner integration currently in use, and confirm each one has an equivalent, tested configuration on the new environment.

☐ Test the new environment's SSL certificate coverage.
Confirm the certificate covers every domain and subdomain that will actually go live, not just the primary domain.

☐ Prepare a rollback plan with a defined decision deadline.
Know in advance what conditions would trigger a rollback, and how much time you realistically have to execute one before it becomes impractical.

Phase 2: Cutover Checklist

Complete these during the actual DNS and traffic switch.

☐ Monitor DNS propagation actively, from multiple locations.
This is where dedicated DNS cutover monitoring earns its keep checking resolution from multiple geographic resolvers tells you where the new site is live and where the old cached record still hasn't cleared.

☐ Keep the old infrastructure running and reachable during propagation.
Don't decommission the old environment the moment DNS changes visitors still resolving to it need it to keep functioning until propagation is fully complete.

☐ Watch uptime and response time on the new environment in real time.
This is the highest attention window of the entire migration increase check frequency temporarily if your monitoring tool supports it, so you catch a problem within minutes, not the usual interval.

☐ Spot-check redirects live, not just in your pre-launch redirect map.
A redirect map is a plan; actually hitting a sample of old URLs post cutover confirms the plan was implemented correctly.

☐ Confirm SSL is serving correctly on every live domain and subdomain.
A certificate that tested fine pre-launch can still fail post-cutover if DNS changes affect which server is actually answering requests for a given hostname.

Phase 3: Post-Launch Checklist

Complete these in the days and weeks following cutover.

☐ Run full redirect validation across your complete URL inventory, not just a sample.
Redirect validation at scale checking every documented old URL, not a handful is how you catch the specific pages your pre-launch spot-check missed.

☐ Monitor search engine crawl behavior and indexing status.
Watch for crawl errors or a spike in reported broken links in search console tools, which often surface redirect gaps your own testing didn't catch.

☐ Confirm every third party integration is actually functioning, not just configured.
Configuration being present isn't the same as a webhook actually firing correctly or an API actually authenticating test real functionality, not just presence.

☐ Keep elevated monitoring frequency for at least one to two weeks post-launch.
Migration related issues don't always surface immediately, maintaining closer attention for a defined extended period catches delayed-onset problems before they become long standing ones.

☐ Formally decommission old infrastructure only after propagation and redirect validation are both fully confirmed complete.
This is the step most commonly rushed confirm, don't assume, that nothing is still depending on the old environment before turning it off for good.

☐ Document what went right and wrong for the next migration.
Every migration teaches something specific to your infrastructure and process; capturing it while it's fresh makes the next one measurably smoother.

A Practical Production Scenario

An agency migrates a client's ecommerce site to a new platform, with a well documented redirect map covering the vast majority of the old site's URL structure. The pre-launch checklist is followed carefully, DNS TTL is lowered in advance, and the cutover itself goes smoothly, with propagation completing within a few hours as expected.

Two weeks later, the client notices a specific product category's organic traffic has dropped sharply. Investigating reveals the redirect map, thorough as it was, missed an older, legacy URL pattern used only by a specific category that had been restructured years earlier and mostly forgotten internally but was still heavily linked to and indexed from an old marketing campaign.

Because the team maintained an elevated post-launch monitoring window and was tracking search console crawl errors as part of that process, the missing redirects are identified and fixed within days of the traffic drop becoming visible, rather than months later during a routine SEO audit. The redirect gap is added to internal migration documentation, ensuring the next migration's URL inventory process explicitly checks for legacy patterns like this one.

Recommended Monitor Setup

1. Configure uptime, SSL, and functional monitoring on the new environment before cutover, confirmed passing prior to any DNS change.
2. Monitor DNS propagation from multiple geographic locations during the cutover window itself.
3. Temporarily increase check frequency during and immediately after cutover, reverting to normal intervals only once things stabilize.
4. Run comprehensive redirect validation against your full URL inventory post-launch, not just a spot-check sample.
5. Maintain elevated monitoring attention for at least one to two weeks post-launch to catch delayed onset issues.

Best Practices for Migration Monitoring

Treat the pre-launch, cutover, and post-launch phases as genuinely distinct monitoring tasks. Each phase has different risks and requires different checks a single "monitor the migration" mindset misses the specific things that go wrong at each stage.

Build your redirect map before launch, and validate it comprehensively after. A documented plan and a verified implementation are two different things, and the gap between them is exactly where lost traffic and broken bookmarks come from.

Lower DNS TTL well before cutover, not on the day of. This single step has an outsized effect on how quickly and predictably your cutover actually propagates.

Temporarily increase monitoring frequency during the highest risk windows. The cutover itself and the days immediately following it deserve tighter check intervals than your steady state monitoring configuration.

Don't decommission old infrastructure until propagation and redirects are both fully confirmed. Rushing this step is one of the most common and most preventable causes of migration related downtime.

Document dependencies as thoroughly as you document the migration plan itself. Third party integrations and partner facing endpoints are easy to overlook precisely because they're not the focus of the migration itself.

Common Mistakes

Treating "the new site loads" as proof the migration succeeded. This confirms almost nothing about redirects, dependencies, DNS propagation completeness, or SSL coverage across every domain and subdomain.

Building a redirect map but never validating it at scale post launch. A plan and its actual implementation can diverge in ways a small sample check won't reveal.

Decommissioning old infrastructure too quickly. Visitors still resolving to the old environment during propagation need it to remain functional until the cutover is fully complete.

Not increasing monitoring frequency during the highest-risk window. Standard check intervals designed for steady state operation are often too infrequent to catch a fast moving cutover issue quickly.

Forgetting third party dependencies during migration planning. Integrations and partner endpoints that aren't visible on the site itself are easy to overlook until someone downstream reports a failure.

Letting elevated post launch monitoring lapse too early. Some migration related issues take days or weeks to surface, and reverting to normal monitoring intervals too soon can mean missing them until they've already caused damage.

Start Monitoring Your Next Migration Properly

A migration doesn't end when the new site loads. It ends when DNS has fully propagated, every redirect has been verified, every dependency has been confirmed functional, and enough time has passed to catch anything that surfaces late.

Start a 30 day Statixoup beta and configure monitoring across every phase of your next migration, from pre-launch through post-launch stabilization. The next cutover you run won't have to rely on hoping nothing broke.