DNS cutovers rarely fail because DNS is mysterious. They fail because people rush the order of operations.
I have seen teams obsess over TTL values and then trip over the real problem: certificates not ready, origin assumptions not tested, old records left behind, or a cutover happening before anyone has a clear rollback path.
If you want to move DNS to a new edge provider without downtime, the job is less about speed than sequencing.
The real danger is the half-moved state
This is the state that causes the most pain.
Not fully old. Not fully new. Some traffic sees one path, some another. Certificates are valid in one place and missing in another. Cache behavior changes midstream. The team is now debugging three systems at once while pretending this is still a simple DNS update.
That is the state you want to avoid.
A clean cutover is not just "the new record resolves." A clean cutover means:
- the edge is ready
- the origin assumptions are correct
- certificate state is understood
- rollback is possible
- the team knows what healthy looks like after the switch
Why rushing the DNS step is the classic mistake
People get impatient because DNS is the visible switch.
They want to flip it and feel progress.
The problem is that the visible switch is not the preparation work. If you cut over before the edge side is actually ready, you create the kind of incident that looks random from the outside and painfully obvious in hindsight.
My opinion here is strong: moving traffic before the new edge is validated is one of the most avoidable self-inflicted outages in infrastructure work.
What should be ready before traffic moves
Before I would point real traffic at a new edge layer, I would want confidence in these areas:
- hostname and certificate expectations
- origin host behavior
- redirect behavior
- cache assumptions
- bypass behavior for dynamic paths
- any admin or authenticated routes likely to behave differently
This is why FirePhage CDN and onboarding flows matter as an operational system, not just a performance feature. The value is not only the end state. The value is making the move readable and staged instead of improvisational.
Why rollback planning matters more than aggressive confidence
The teams that say "we won't need rollback" are usually the teams that end up improvising rollback under stress.
A real rollback plan is simple:
- you know which records would need to change back
- you know what the old working target was
- you know which signals would tell you to reverse course
- you can do it without debating the basics in the middle of the issue
This is not negativity. It is discipline.
You are more likely to have a calm cutover when the team knows it has an exit path.
TTL helps, but it does not rescue a bad sequence
This is another place people get distracted.
Yes, reasonable TTL handling matters. It helps you shorten the cleanup window and react faster if something goes wrong.
What TTL does not do is fix:
- bad origin configuration
- incorrect host handling
- incomplete SSL setup
- untested routing assumptions
I have seen people lower TTL and act as if they bought insurance. They did not. They just made a future correction slightly faster.
Useful, but not sufficient.
What a safer cutover looks like
A healthier migration flow is boring in the best way:
first validate the new edge setup, then move traffic, then verify the live path, then clean up leftovers.
The important part is that each step has a purpose. Validation is not ceremonial. Verification is not optional. Cleanup is not something you "get around to later" after leaving stale records behind.
One of the quietest causes of future problems is leftover DNS or origin history after a migration. The site works, so the team moves on. Months later, an old record becomes the easiest way around the new protection layer.
WordPress and WooCommerce add their own cutover traps
Application behavior matters more on these sites than people expect.
WordPress and WooCommerce cutovers can expose:
- odd redirects
- admin or authenticated path surprises
- cache issues on dynamic routes
- checkout/account behavior that looked fine in a generic probe but not in real use
This is why a safe cutover is not just a network exercise. It is an application exercise too.
On a WooCommerce store, I would care less about a static asset loading five milliseconds slower and far more about whether account, cart, and checkout paths behave predictably under the new edge assumptions.
The operational test I trust most
After traffic moves, I want to know whether the site is healthy from both directions:
- does the public path behave correctly
- does the origin path still make sense under the new setup
Teams often do the first check and forget the second. Then they discover later that the move solved one problem while leaving a new routing or origin-exposure issue behind.
That is not a finished migration. It is just a working-looking one.
The better mindset
Think of DNS cutover as controlled routing change, not a record edit.
That framing helps because it keeps attention on the real risks:
- wrong target
- wrong timing
- wrong assumptions
- incomplete verification
A site almost never goes down because someone lacked bravery. It usually goes down because somebody skipped the boring validation step they were sure would be fine.
Move DNS last, verify aggressively, and keep rollback ready. That is how you avoid turning a routine edge migration into a weekend outage story.