Why a month, and why weekly
Most migration problems on a course site are not visible on cutover day. Monthly renewals only run once a month. WordPress scheduled tasks run on page loads unless moved to a system scheduler, so a quiet night can hide a broken drip schedule. Google warns that crawl rate often dips temporarily right after a move, and its Page indexing report says fix validation typically takes up to about two weeks. A weekly rhythm catches each of these while the old host still exists as a fallback.
One timer runs longer than a month. Let's Encrypt certificates last 90 days and Let's Encrypt recommends renewing at 60 days, so a certificate issued at cutover will not renew inside your 30-day window. You cannot wait to see renewal succeed; instead confirm in week one that renewal is automated and who is alerted if it fails. WP Engine, for example, attempts renewal 22 days before expiry and opens a ticket if it fails.
Week 1: traffic, schedules, mail and certificates
| Check | How | Pass condition |
|---|---|---|
| Traffic has moved | Compare access logs on old and new hosts, as Google suggests | Old host traffic falling toward zero; new host rising |
| DNS seen worldwide | Public DNS checking tools for A, CNAME and MX records | Every resolver returns the new values |
| Scheduled tasks run | Schedule a test drip or reminder for the next hour; or check a system cron entry calling wp-cron.php | The task runs on time without anyone visiting the site |
| Renewal charge processed | Find a renewal due this week in your membership plugin and confirm the order, access extension and receipt | All three happen without manual action |
| Mail authenticated | Send a receipt and a password reset to a Gmail address and inspect the headers | SPF or DKIM passes; TLS used; arrives in the inbox |
| Certificate renewal automated | Read the host's SSL documentation or panel setting | You know the renewal mechanism and who is notified on failure |
Week 2: search crawling and errors
Open the Crawl Stats report in Search Console (Settings, Crawl stats). Its host status section covers robots.txt fetching, DNS resolution and server connectivity over the past 90 days, so any new problem after cutover shows up against your pre-move baseline. The report is only available for root-level properties, meaning a Domain property or a URL-prefix property at the site root. Google notes that sites with fewer than a thousand pages should not normally need it, but a host move is the exception worth a look because host status is where a blocked or unreachable server shows up first.
Then check the Page indexing report for new Server error (5xx) and Not found (404) entries. A 5xx spike points at the new server or a firewall blocking Googlebot; new 404s usually mean a redirect or permalink setting did not come across. Fix every instance before you click Validate fix, because validation stops if even one remaining instance is found.
- Crawl Stats host status shows no new robots.txt, DNS or connectivity problems.
- Total crawl requests have recovered toward the pre-move level, or are trending that way.
- No new 5xx or 404 clusters in Page indexing; any fixes submitted for validation.
- URL Inspection on your homepage and two course pages shows a recent crawl.
Week 3: prove the new backups
Until you have restored from the new host's backups, you only know they exist. Restore last night's backup to a staging or temporary environment, log in as a test student, open a lesson that student has completed, and check that the latest order is present. Note how long the restore took and whether it included the database, uploads and any host-specific settings such as redirects.
This is also the week to check retention against your risk. If the new plan keeps 14 days of daily backups, a corruption discovered on day 20 cannot be undone from host backups alone. Keep an independent off-host copy, and keep the final pre-cutover backup from the old host until the month is over.
Week 4: email health and the evidence file
Google's sender requirements apply to all senders: SPF or DKIM, valid forward and reverse DNS for sending domains or IPs, TLS, and a spam rate in Postmaster Tools kept below 0.3%. Senders of more than 5,000 messages a day to Gmail also need both SPF and DKIM, DMARC, From: alignment with SPF or DKIM, and one-click unsubscribe for marketing and subscribed mail. Review bounce and complaint figures in your sending service for the month; a jump after the move usually means a missing DNS record or mail sent from a server IP that lacks reverse DNS.
Then assemble the evidence file. It turns the decision to cancel the old host into a checklist rather than a hunch.
| Evidence | Where it comes from | Why keep it |
|---|---|---|
| Old host traffic at or near zero | Old host access logs or panel statistics | Google advises shutting old hosting only when its traffic reaches zero |
| A renewal processed on the new host | Membership plugin order and email log | Proves scheduled tasks and payment webhooks work |
| Crawl Stats and Page indexing screenshots | Search Console | Baseline if traffic later drops |
| A completed test restore | New host backup log and your notes | Proves you can recover without the old host |
| Final export from the old host | Database dump and files archive | Last resort for data the migration missed |
| Mail authentication results | Message headers and sending service reports | Shows the domain's mail survived the move |
| Renewal dates and cancellation terms | Old host account | Avoids an unwanted renewal charge |
Warning signs and where to look
| Symptom | Likely cause | First check |
|---|---|---|
| Drip lessons unlock late or not at all | WP-Cron only runs on page loads; system cron missing | Host cron setting, or crontab entry for wp-cron.php |
| Some students still see the old site | Cached DNS, or a record not updated | Public DNS checks; TTL on the old records |
| Password reset emails missing | Mail plugin not configured on new host, or outgoing ports blocked | Send a test; read the mail log |
| Search crawl requests dropping for weeks | Firewall or bot protection blocking Googlebot | Crawl Stats host status; URL Inspection live test |
| New 5xx errors in Search Console | PHP limits, timeouts or database errors | Server error logs at the times shown |
| Old host still receiving orders | Payment webhooks or API callbacks pointed at an old IP or hostname | Payment provider webhook settings |
Questions before you decide
When can I cancel my old host after a migration?
Google's guidance for a hosting move is to shut down the old hosting once traffic to it reaches zero. For a course site, also wait until a renewal, a backup restore and a month of crawl data have succeeded on the new host.
Why do drip lessons stop after moving hosts?
WordPress runs WP-Cron on page loads rather than continuously, so scheduled tasks can run late or not at all unless a system scheduler calls wp-cron.php. Check whether the new host runs cron for you or whether you must add it.
Is a drop in Google crawling after a move normal?
Google says a temporary drop in Googlebot's crawl rate immediately after launching on new hosting is normal, and it may later rise above previous levels. A drop that persists suggests Googlebot is being blocked.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Google Search Central: Site moves without URL changes Accessed 30 Oct 2026
- Google Search Console Help: Crawl Stats report Accessed 30 Oct 2026
- Google Search Console Help: Page indexing report Accessed 30 Oct 2026
- Google Workspace Admin Help: Email sender guidelines Accessed 30 Oct 2026
- WordPress Developer Handbook: Hooking WP-Cron into the system task scheduler Accessed 30 Oct 2026
- Let's Encrypt: FAQ Accessed 30 Oct 2026
- WP Engine Support: SSL Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.