What to check after the move
After moving to new hosting, you need to verify that pages load, forms work, SSL is valid, email sends and receives, and cron jobs run. This guide covers each check and explains why DNS propagation timing matters for both web and mail.
Sarah FrankiewizcPanel, WordPress, migrations and backups
8 min read Updated 23 Sep 2026
What to check after the move
You do not cancel your old hosting the moment a site loads on the new server. DNS takes time to settle everywhere, and a site that looks fine to you from your own laptop can still be broken for other visitors, or for email, for a day or two. This checklist covers the six things worth confirming, and how long to sit on the old account before you let it go.
This picks up from a completed migration: your files and database are already on Hostworld's cPanel hosting and you have pointed the domain's DNS at us. If you have not done that part yet, that is a separate step and this checklist will not make much sense until it is done.
Before you start
Two things matter before any of the checks below are worth trusting.
- DNS propagation takes time. Most changes are visible everywhere within 24 to 48 hours, but some resolvers can take up to 72 hours depending on the record type and how the domain's TTL (time to live) was set before the change. If TTL was left high on the old records, propagation can genuinely take the full window. That is expected, not a fault.
- Mail and web don't move at the same speed. A/AAAA records (the ones pointing your domain at a web server) are commonly set to refresh every few minutes to an hour. MX records (the ones for mail) are often deliberately set to refresh every one to four hours, for stability. So it is entirely normal for the site to be live on Hostworld while mail is still arriving at the old server for a while longer. Treat the site and email as two separate checks with two separate timelines, not one job.
Keep the old hosting account active and unchanged while you run through this. Do not delete anything on the old server, and do not remove old DNS records, until every item below has passed.
Step 1: Check every page loads on the new server
Click through the site as a visitor would: the homepage, a handful of inner pages, anything behind a login, and any page with an unusual template or plugin. Do this from a phone on mobile data as well as a desktop browser, ideally on a different network to your office or home connection. Your own machine may have cached the old server's IP address in its DNS resolver or browser, which shows you the old site even after the real switch has happened.
A faster way to confirm the whole internet is seeing the new server, rather than just your connection, is to use a multi-location DNS checker (a site like whatsmydns.net) and look up the domain's A record. If it shows the new Hostworld IP address consistently across most locations, the site itself has propagated. A few stragglers are normal within the first day.
Step 2: Check forms actually send
A contact form, checkout, or booking form can look identical after a move but silently fail, usually because it relies on a mail function, an API key, or a file path that pointed somewhere specific on the old server. Submit every form on the site with a real test entry and confirm the message or order actually arrives where it should. If a form emails you on submission, that also doubles as a partial check that outbound mail from the new server works, which leads into Step 4.
Step 3: Check SSL is valid on the new server
cPanel hosting issues free certificates automatically through AutoSSL, but AutoSSL can only issue a certificate once your domain's DNS is actually pointing at the new server: it has to reach the domain over HTTP to prove you own it. If you check SSL in the first hour or two after switching DNS, before propagation has caught up, you can see a certificate error that has nothing to do with the certificate itself and everything to do with timing. Wait until Step 1 shows the domain resolving to the new server consistently, then check the padlock in a browser.
If the certificate still hasn't appeared once DNS has settled, an old certificate is the most likely cause. Let's Encrypt (the certificate AutoSSL installs) will not install over an existing certificate on the domain, even one that is expired or self-signed, so a leftover certificate needs removing before a new one can go on. You can also trigger the process manually rather than waiting for cPanel's schedule:
- Log in to cPanel.
- In the Security section, click SSL/TLS.
- Click Run AutoSSL.
Once a valid certificate is showing, force the site to redirect to the secure version if it isn't already, so visitors and search engines are always sent to the encrypted URL rather than being left on an insecure one. This step is easy to skip because the site "still works" without it, but leaving it undone means anyone landing on the plain http:// address gets an unprotected version of the site sitting alongside the secure one.
Step 4: Check email sends and receives
Email is the part people check last and regret checking late, because a broken inbox often isn't obvious until a customer email goes missing for a few days. Test both directions:
- Send a test email from a mailbox on the new server to an external address (a personal Gmail account, for instance) and confirm it arrives.
- Send a test email from that external address to your domain and confirm it lands in the new mailbox, not the old one.
If mail isn't arriving, the first thing to check is whether the domain has an MX record at all, since a domain cannot receive email without one. A migration mistake that causes exactly this kind of silent failure is removing the old MX records without the new ones fully in place, or adding new MX records but never removing the old ones, so mail keeps splitting between two servers. Use an MX lookup tool rather than your own machine's cache to see what the wider internet is actually resolving to, for the same reason described in Step 1.
Because MX records are often set to refresh more slowly than A records, do not be surprised if the site is fully working on Hostworld while mail is still routing to the old server for a further few hours. That is the expected pattern, not a sign the migration has gone wrong.
Step 5: Check cron jobs are running
If the old site had scheduled tasks (a backup script, a cache clear, a WordPress plugin that relies on WP-Cron being triggered externally), check they are actually running on the new server, not just present in the list.
- Log in to cPanel.
- In the Advanced section, click Cron Jobs.
- Check the jobs are listed with the correct schedule.
The most common reason a cron job looks correctly added but never actually runs is that it was copied across from the old server using a relative path or a shortcut that only worked in that server's specific setup. Cron does not run from inside your website's folder the way a browser request does, so a command needs the full path to the PHP binary and the full path to the script, for example /usr/bin/php /home/username/public_html/cron-script.php rather than just cron-script.php.
By default, cPanel emails you the output of each cron run, which is a genuinely useful way to confirm a job fired correctly straight after a move. Leave the Cron Email box on this screen populated with your address for a day or two, watch for the confirmation emails, then either clear that box or point it somewhere else once you're satisfied the jobs are running, so you're not left with a flooded inbox for a task you've already verified.
Step 6: Decide how long to keep the old account, then cancel
Once every check above has passed, consistently, across more than one location and more than one device, keep the old hosting for a further few days as insurance before you cancel it. This costs a little in overlap but protects you against the small number of visitors or ISPs still resolving old records, and against anything you haven't thought to test showing up late.
When you do go to cancel the old account, check how that host's own cancellation process actually works before assuming it is instant. Many hosting control panels queue a cancellation request rather than actioning it the moment you submit it, sometimes running it on the next scheduled system check rather than immediately, and even an "instant" option can still take a short while to process. If you submit the request and change your mind shortly afterwards because you've found something still needs fixing, check whether the old host lets you withdraw the request before it runs, most billing systems do.
Only remove the old DNS records, and only ask the old host to actually delete the account (rather than just cancel billing), once you are certain nothing is still pointing at it.
What next
With the site, SSL, mail and cron all confirmed on Hostworld, the next sensible step is making sure you have a proper backup schedule running on the new account rather than relying on the old host's backups, which you're about to lose access to. Our backup guides cover setting that up in cPanel. If anything in this checklist turned up a problem you can't resolve yourself, particularly around mail routing or an AutoSSL certificate that won't issue, open a support ticket and we'll look at it against your account directly rather than guessing from a description.
Common questions
How long should I actually keep the old hosting account?
A few days after every check in this list has passed consistently is usually enough, since most DNS propagation completes within 24 to 48 hours and rarely runs past 72. If you're not in a hurry, there's no harm keeping it a little longer, particularly if the old host bills monthly and you're already inside a paid period.
My site loads fine but email still isn't arriving. Is the migration broken?
Not necessarily. MX records are often set to refresh more slowly than the A record that points your website, so a working site with lagging email in the first day or so is a normal pattern. If it's still not working after 48 to 72 hours, check that an MX record exists at all and that old and new MX records aren't both present at once.
AutoSSL isn't issuing a certificate. What should I check first?
Confirm the domain is actually resolving to the new server everywhere, using an external checker rather than your own browser, since AutoSSL can only verify a domain it can reach. If DNS has settled and it's still not issuing, check for a leftover certificate on the domain, expired or self-signed certificates block a new one from installing, and remove it before running AutoSSL again from cPanel's SSL/TLS page.
A cron job is listed in cPanel but doesn't seem to run. Why?
The most common cause after a move is a relative file path that worked on the old server's setup but means nothing to cron on the new one. Edit the job to use the full path to PHP and the full path to the script, then check the Cron Email box to confirm it actually fires on schedule.
Can I cancel the old hosting and still come back to it if something goes wrong?
Once an account is genuinely deleted at the old host, no. Before that point, a submitted cancellation request can often be withdrawn if you act quickly, check the old host's own billing area for how to do that. It's a better habit to run the full checklist first and only submit cancellation once you're confident, rather than relying on being able to reverse it.