Before you migrate anything, contact your current host's retention or cancellations team and ask for the loyalty rate — many hosts will match or beat the renewal price to keep an existing account, with zero migration risk. If that doesn't work, or you've decided to move regardless, a site switch is safe as long as you follow one rule: never shut down the old host until the new one is fully verified and the DNS change has had time to propagate everywhere.
Key takeaways
- Asking costs nothing and carries no risk. A retention-team call takes a few minutes; a migration takes hours and introduces failure points a phone call doesn't have.
- Switching hosts doesn't hurt rankings — mistakes during the switch do. Downtime, a missing redirect, or a slower new server are the actual causes; the migration itself is neutral.
- You almost never need to change nameservers. Updating the A and CNAME records at your existing DNS provider is usually enough — nameservers are a separate, bigger move.
- Keep the old host live for 7-14 days after the switch. The same overlap window email migrations use, for the same reason: DNS propagation isn't instant or uniform.
- Test on the new host before any DNS change, using a local hosts-file edit or the new host's temporary URL — confirm the site actually works there before it's live.
Step one: ask before you migrate
Hosting renewal prices are set the way they are because switching feels like more hassle than paying the higher rate — that's the whole mechanism behind the renewal shock covered in the renewal pricing comparison. The counter-move most people skip: the inconvenience the host is counting on is also the reason retention teams exist. Keeping an existing account costs the host less than acquiring a new one, so there's often room to negotiate that a new customer would never see.
- Contact retention or cancellations specifically, not general support — these teams are the ones with authority to offer a reduced rate, and routing through them usually means saying you're considering cancelling.
- Have your renewal price and account tenure ready. A longer-standing account with a clean payment history is a stronger negotiating position than a brand-new one.
- Ask for a specific number, not a vague discount — "what's the best rate to keep this account active" gets a more useful answer than "can you lower my price."
- If they say no, you've lost nothing. No migration risk was taken, and you move to the switching sequence below with the same options you had before asking.
Deciding whether switching is worth it
If the retention offer isn't good enough, or the real problem is performance or features rather than price, switching is the right call. Two things worth checking before you commit to a specific new host: the renewal price of wherever you're moving to — so you're not just resetting the same clock — and whether the new tier actually matches what you need, which the hosting pillar guide's decision path covers in more depth than a price comparison alone can.
Before you touch any DNS record
The work that actually prevents a bad migration happens before the cutover — the same principle that applies to email migrations, applied to the site itself.
| Step | Why it matters |
|---|---|
| Back up files and database in full | A working backup is the one thing that makes every later step reversible if something goes wrong |
| Set up the site on the new host | Using its temporary URL or IP, not your live domain yet — this is where the new environment gets configured and tested |
| Test via a local hosts-file edit | Points your own browser at the new server while the domain's public DNS still resolves to the old one, so you can verify the site works before anyone else sees it |
| Lower DNS TTL to ~300 seconds | Done 24-48 hours ahead, this is what makes the actual cutover propagate in minutes instead of up to a day |
The cutover itself
With the new host tested and the TTL already lowered, the cutover is a small, specific set of DNS changes — usually not a full nameserver change.
- Update the A record(s) to point at the new host's IP address — this is the change that actually redirects where visitors and crawlers land.
- Update any CNAME records (www, subdomains) to match what the new host expects.
- Reissue or confirm TLS/SSL on the new host before traffic arrives there, so the first visitors after the switch don't hit a certificate warning.
- Leave nameservers alone unless you have a specific reason to also move DNS management itself — that's a separate, larger change with its own propagation window.
A switch that goes wrong almost never fails at the DNS record itself — it fails because the old host was shut down too early, or a redirect from an old URL structure was never set up, both of which are avoidable with the sequencing above.
The overlap window and what to verify
DNS propagation happens at different speeds for different resolvers around the internet, bounded by whatever TTL was in effect before you lowered it. Some visitors — and some search engine crawlers — can keep reaching the old server for days after the records change.
Bar length = recommended duration, scaled to the 14-day overlap window.
During the overlap, check that the new host is actually serving correctly — status code 200 on key pages, no broken internal links, analytics tracking firing — rather than assuming DNS resolving correctly means everything downstream works. Keep the old server running and unmodified so it can keep serving the fraction of traffic still arriving there until the propagation window closes.
If the old host also handles your email
Switching web hosting and switching email are separate decisions, even when the same provider happens to do both today — moving the site doesn't require moving mail, and vice versa. If you are moving both, treat them as two sequences run in parallel, not one: the business email migration guide covers the MX/SPF/DKIM/DMARC order specifically, which is different from the A/CNAME records a site move touches.
Documented vs. inferred vs. unsupported
| Claim | Status | Basis |
|---|---|---|
| Retention teams sometimes offer a reduced rate to keep an account | Inferred | Widely and consistently reported practice across the hosting industry, but no provider publishes a guaranteed discount or rate |
| A correctly executed host switch has no lasting SEO effect | Documented | Consistent with how DNS and crawling work — rankings are tied to the domain and content, not the hosting infrastructure behind it |
| Nameservers rarely need to change for a host switch | Documented | Follows directly from how A/CNAME records and nameservers function separately in DNS |
| A 7-14 day overlap window catches essentially all stale-record traffic | Inferred | A commonly recommended range — actual propagation tail depends on which resolvers cached the old record and for how long |
Who this sequence is for
- Facing a renewal increase and haven't called your host yet: start there — it's the lowest-effort, lowest-risk option and it's usually skipped.
- Decided to switch regardless of price: the sequence above applies the same way whether the reason is cost, performance, or support quality.
- Upgrading tiers at the same time (e.g. shared to VPS), not just changing providers: see the zero-downtime shared-to-VPS migration guide, which covers the extra server-configuration steps that a same-tier switch doesn't need.