What to Do With Your Old Hosting Account After You Move
Your old hosting account is not a single thing to cancel or keep. It is a bundle of services, and each one needs a separate decision after you move. The goal is to avoid three specific failures: downtime from a service you still depend on, data loss from deleting something you forgot to copy, and surprise charges from a renewal you did not cancel. Work through the list below in order, and you will know exactly what to do with old hosting account after moving.
Inventory every service on the old account before you touch anything
Log in to the old control panel and list every product line item. Most accounts show separate entries for web hosting, domain registration, email mailboxes, SSL certificates, database instances, and add-on services like backups or staging environments. Write them down, even the ones you think are irrelevant. A forgotten add-on is the most common source of a surprise charge, because it renews automatically and you never see a usage page for it.
For each item, ask one question: does the new account already provide an equivalent, or does this item still point to the old server? A domain name is the critical exception. If the domain is registered through the old host, you must transfer the registration to a dedicated registrar or to the new host. Do not simply change the nameservers and assume the domain is safe. Changing nameservers only redirects DNS traffic. The registration itself stays with the old host, and if that host goes out of business or the account is suspended, you can lose control of the domain. Start the transfer by unlocking the domain at the old registrar and requesting an authorization code. That code is a long string, and you will paste it into the new registrar’s transfer form.
whois example.com | grep -i "registrar\|name server"
# Look for the registrar line. If it matches the old host, you need a transfer.
# If it matches a separate registrar, you can leave the registration there.
Move the data you actually need, then verify it byte for byte
Do not rely on the old host’s backup tool as your only copy. Download a full backup of the web root and the database, then verify the archive is readable on your local machine. For a typical site, that means pulling the files with rsync or scp and dumping the database with mysqldump or pg_dump. The exact command depends on the old stack, but the shape is the same. For a MySQL database, run this on the old server or from a machine with database access:
mysqldump -u old_user -p old_database > old_database.sql
# Then verify the dump is not empty and contains table definitions:
grep -c "CREATE TABLE" old_database.sql
For files, use rsync with archive mode and checksum verification. The -c flag forces a checksum comparison instead of relying on file size and modification time, which can miss corrupted files on a flaky disk.
rsync -avzc /path/to/old/webroot/ user@newserver:/path/to/new/webroot/
# The -c flag compares checksums. If it finishes with no errors, the copy is verified.
After the copy, test the new site from a staging URL or a local hosts file entry before you touch DNS. Do not point the domain at the new server until you have confirmed the site loads, the database connects, and any cron jobs or background workers run correctly. This test is the only way to catch a missing PHP extension or a hardcoded absolute path before real traffic hits.
Decide which services to keep, not just which to cancel
Some services on the old account are worth keeping for a short window. Email is the biggest one. If you have mailboxes on the old host, do not delete them on day one. Forwarders and autoresponders can break silently when you move DNS, and you will not notice until a client complains. Keep the old mailboxes alive for at least a week after the DNS switch, and set up a forwarder from each old address to the new one. That gives you a safety net for messages sent to the old MX records during propagation.
SSL certificates are another case. If the old account has a certificate that is still valid and the new server can import it, you can reuse the private key and certificate files. But if the certificate is issued by the old host’s own authority, it will not be trusted by browsers on the new server. In that case, do not bother transferring it. Issue a fresh certificate on the new server and let the old one expire. The only reason to keep the old certificate is if you need to prove a past TLS configuration for an audit, and in that case you should export it to a file and store it locally, not leave it on the old server.
Databases on the old account that you no longer use should be dropped, but only after you have a verified dump file stored in two places. One copy on your laptop and one on an external drive or object storage bucket is enough. Do not keep the old database instance running just because you are unsure. The dump file is the source of truth, and the live instance is a liability.
Cancel the old account only after DNS has fully propagated
DNS propagation is not instantaneous, and it is not uniform. Different resolvers cache the old records for different lengths of time, typically from minutes to a day or two. If you cancel the old account immediately after changing nameservers, you will serve a mix of old and new responses, and some visitors will hit a dead server. Wait until you can query multiple public resolvers and see the new records consistently. Use a command like this to check from a few vantage points:
dig +short example.com A @8.8.8.8
dig +short example.com A @1.1.1.1
# Both should return the new server IP. If one still shows the old IP, wait.
Once both resolvers agree, you can safely cancel the hosting product. But before you click the cancel button, go back to the inventory list and check off every item. The domain registration should be transferred or intentionally left at a separate registrar. The email mailboxes should be forwarded or drained. The SSL certificate should be either imported or replaced. The database dumps should be verified and stored offsite. Only then is the account truly disposable.
What to do next after the old account is gone
Set a calendar reminder for the day after the old account’s billing cycle would have renewed. That is the moment when a forgotten add-on would have charged you. If nothing appears on your credit card statement, you are done. If something does appear, contact the old host’s billing department immediately and ask for a refund, citing the cancellation confirmation you saved. Keep that confirmation email in a folder you can find in a year, because billing disputes can surface months later. And finally, write down the new server’s IP, the new registrar’s login, and the location of your backup files in a place that is not the old host’s control panel. You will need that information the next time you move, and you will not have the old account to look it up.
