Leaving a web host is four separate migrations that people treat as one: the site files and database, the email mailboxes, the DNS zone, and the domain registration itself. Only the first is what most migration guides cover, and it is the one hosts help with. Email is the hardest and the one that loses mail if rushed, and the domain carries a 60-day transfer lock under ICANN policy after a registrar transfer or a registrant change, which is the constraint most likely to stall a switch that was otherwise ready.
Disclosure: HostingDive earns a commission when you buy through our links, at no extra cost to you. Ratings come from independent testing.
The Short Answer
Do not cancel anything until the new host is serving the site correctly on a temporary URL and the mail is flowing. Overlap the two accounts by at least one full billing cycle, take a complete off-host backup before touching DNS, and keep the domain where it is during the move. Cancelling first is what turns a routine switch into a recovery.
The Four Things That Actually Have to Move
1. Files and database
This is the well-supported part. Most hosts offer a free migration on new accounts, and it usually works. Two conditions determine whether it is worth accepting: how many sites are included in the free tier, and whether the migration covers only the primary site or all add-on domains. The technical work here is a copy, not a transformation, so the risk is low and the rollback is simple as long as the old account is still running.
Take an independent backup regardless. A full export of site files plus a database dump, stored somewhere neither host controls, is the only thing that protects against both a failed migration and a support account being closed mid-move. Do not rely on the outgoing host's own backups for this: they live inside the account being cancelled.
2. Email
Email is where switches go wrong, and it goes wrong quietly. Mailboxes hosted with the web host do not move with the site. Their contents have to be copied mailbox by mailbox, usually over IMAP, and any mail that arrives after the copy but before the DNS change lands in the old mailbox where nobody is looking for it.
The sequence that works is: create the mailboxes on the destination first, copy the existing mail with an IMAP transfer tool while the old mailboxes are still live, change DNS, then run a second incremental copy afterward to catch the messages that arrived during the cutover. Skipping that second pass is the single most common cause of missing mail after a host change. Whether to keep email with the web host at all is a separate question worth settling before the move rather than during it, because moving mail to a dedicated provider during a host change turns two migrations into one.
3. DNS
DNS is the switch itself, and the only preparation that matters is lowering the TTL on the records being changed. A record with a 24-hour TTL will keep sending some visitors to the old server for up to a day after the change. Lowering the TTL to 300 seconds at least 24 to 48 hours in advance means the actual cutover propagates in minutes rather than a day, which shortens the window where two servers are both live and receiving traffic.
Record the full zone before changing anything. Beyond the A and MX records, most zones carry SPF, DKIM, and DMARC records for mail authentication, verification records for third-party services, and CNAMEs for subdomains. Missing an SPF or DKIM record is not visible on the website at all and shows up days later as outbound mail landing in spam.
4. The domain registration
The domain is the piece that does not need to move and frequently should not, at least not at the same time. If the domain is registered with the outgoing host, it can be transferred to a new registrar, but that is an independent process with its own timing: unlock the domain, obtain the authorization code, disable privacy if the registrar requires it, and approve the transfer, which typically takes up to five days.
The constraint to plan around is the 60-day lock. Under ICANN policy a domain generally cannot be transferred between registrars within 60 days of a previous transfer, and a change to the registrant's details can trigger a similar 60-day restriction. Attempting a domain transfer in the same week as a hosting migration is how a straightforward move acquires a two-month tail. Move the hosting first, confirm everything is stable, then move the registration if it needs moving at all.
Who Should Move Now (and Who Should Wait)
- Move if: the renewal quote is materially above what an equivalent plan costs elsewhere and the host will not match it. That conversation is worth having first, as covered in negotiating hosting renewal pricing, because a matched renewal costs a phone call rather than a migration.
- Move if: the site has outgrown the plan and the host's next tier is not competitive. Outgrowing shared hosting is a sizing problem before it is a vendor problem; the path is covered in the shared hosting to VPS migration guide.
- Move if: support has failed on something that mattered and the failure is a pattern rather than an incident.
- Wait if: the renewal is more than a month out. Migrating early wastes paid time on the old account for no benefit, and the overlap you want is one cycle, not three.
- Wait if: a launch, a seasonal peak, or a campaign is inside the next two weeks. The cutover window is the wrong thing to compress.
- Wait if: the domain transferred registrars or changed registrant details in the last 60 days. Move the hosting now if needed, but leave the registration alone until the lock expires.
The Fine Print
| Step | When to do it | What goes wrong if skipped |
|---|---|---|
| Full off-host backup, files plus database | Before anything else | No rollback once the old account closes |
| Export the complete DNS zone | Before any DNS change | Mail authentication and third-party verifications break silently |
| Lower record TTL to 300 seconds | 24 to 48 hours before cutover | Up to a day of split traffic across two servers |
| Create destination mailboxes and copy mail | Before the DNS change | Mail bounces or lands nowhere retrievable |
| Second incremental mail copy | After the DNS change | Messages received during cutover are stranded on the old server |
| Verify the new site on a temporary URL | Before the DNS change | The cutover becomes the first test |
| Cancel the old account and disable auto-renew | After one full overlapping cycle | Either an unwanted renewal charge or a deleted rollback |
Cancelling is a separate action from letting a plan lapse, and hosts differ on both. Some cancel at the end of the paid term, some cancel immediately and prorate, and some do not prorate at all. Account data, including the host's own backups, is typically purged shortly after termination. Confirm the effective date in writing, and take the final backup before submitting the cancellation, not after.
The Verdict
Sequence beats speed on a host change. The order that works is backup, build and verify on the new host at a temporary URL, migrate mail, lower TTL, cut DNS, run a second mail pass, watch for a week, then cancel. Every failure mode in this article comes from compressing that order: cancelling before verifying, changing DNS before copying mail, or transferring the domain in the same window as the hosting. The overlap costs one billing cycle on a plan that is being left anyway, which is the cheapest insurance available in hosting. Once the site is stable on the new host, revisit whether the plan tier is right using the small business hosting sizing guide rather than carrying over the old plan's assumptions.
Read the full host reviews on HostingDive, with current intro and renewal pricing before you commit to a new plan.
Frequently Asked Questions
- Should I cancel my old hosting before or after migrating?
- After, with at least one full billing cycle of overlap. The old account is the rollback path, and once it is terminated the host's own backups usually go with it. Disable auto-renew rather than cancelling immediately if the term still has time on it, and confirm the effective cancellation date in writing.
- Does my email move with my website?
- No. Mailboxes hosted with a web host are separate from the site files and have to be recreated at the destination and copied over, usually via IMAP. Anything that arrives between the copy and the DNS change stays on the old server, which is why a second incremental copy after cutover is a required step rather than an optional one.
- How long does DNS take to propagate after a host change?
- It depends on the TTL that was in place before the change, not the one set afterward. A record with a 24-hour TTL can keep some visitors on the old server for up to a day. Lowering the TTL to 300 seconds 24 to 48 hours ahead of the cutover reduces the actual switch to minutes.
- Can I transfer my domain at the same time as my hosting?
- You can, but it is usually a mistake to try. A registrar transfer is a separate process taking up to about five days, and under ICANN policy a domain generally cannot be transferred within 60 days of a prior transfer, with a similar restriction after a registrant change. Move the hosting, confirm stability, then handle the registration separately.
- Will I lose my SSL certificate when I move hosts?
- The old certificate does not travel, but this is rarely a problem. Most hosts issue a free certificate automatically once DNS points at them, which means there can be a short window after cutover before the new certificate is live. Issue or request the certificate on the new host before the DNS change where the host supports pre-validation, and check that HTTPS resolves cleanly within the first hour after the switch.