Cancelling hosting is straightforward and irreversible. What makes it go badly is not the cancellation. It is discovering afterwards that something you needed was only on that server.
Work through this before you cancel anything, and do it while the account still works.
Take a complete backup, and check it opens
A full cPanel backup contains files, databases, email and settings in one archive. Download it and store it somewhere that is not the server you are leaving.
Then open it. An archive that will not extract is not a backup, and finding that out after the account is gone is the situation this whole article exists to prevent. Backing up and restoring explains generating one.
Take a separate database export as well. Databases are the part people most often need in isolation, and extracting one from a full archive is more work than having it already.
Email is the thing that gets lost
Files can usually be rebuilt. Mail cannot.
If mailboxes are IMAP, the messages live on the server and disappear with it. Export each mailbox to a local file from a mail client, or copy the folders into another IMAP account before you cancel.
Do this for every mailbox, including ones nobody uses. The address that has not been checked in two years is exactly the one that turns out to hold something.
Also write down the forwarders, autoresponders and filters. Those are configuration rather than data, so no export contains them. Migrating email explains moving mail properly if you are going somewhere else.
Record the configuration
The things that are not in any backup and that you will spend an afternoon reconstructing.
DNS records. Take a copy of the whole zone. A, MX, TXT, CNAME, everything. If DNS was managed here, all of it vanishes.
Cron jobs. What runs, when, and the exact command.
PHP settings you changed, and which extensions the sites need.
Redirects and .htaccess rules, which are in the backup but easier to find now.
A text file with those in it is fifteen minutes now and saves several hours later.
The domain is separate, check where it is registered
This is the one people get wrong, and it has a deadline attached.
If the domain was registered through the hosting provider, cancelling the hosting may not cancel the domain, and it may. Find out explicitly rather than assuming.
If you want to keep it, transfer it out before cancelling, or at minimum confirm in writing that it stays and auto-renews. A domain that lapses during a cancellation can be registered by someone else, and there is no support ticket that undoes that.
Transfers take days and require the domain to be unlocked with an authorisation code, so start early. See getting your EPP code.
Move first, cancel second
The order that avoids downtime and avoids losing the gap.
Set the new hosting up, test it through your hosts file, point DNS at it, confirm it works, then cancel. Keep the old account for at least a week after the switch: mail continues arriving there while DNS caches expire, and problems from a migration surface days later.
Cancelling on the day you switch means any mail delivered to the old server in that window is not delayed. It is gone. Migrating between providers sets out the sequence in more detail.
Check what else lives there
Accounts accumulate things nobody remembers.
Subdomains for a project that ended. A staging copy of another site. A cron job that emails a report to a client. Files a colleague uploaded for someone else.
Look at the full directory listing and the subdomain list before deciding the account holds only what you think it does.
Sort out the billing side
Download your invoices if you need them for accounts. They are usually available only while the account exists.
Then cancel the recurring payment properly, at the provider rather than only at your bank. Cancelling a card payment without cancelling the service can leave an unpaid balance in your name.
Check the refund terms and the notice period. Some providers bill a full cycle if cancelled after a date, which is worth knowing before you pick a day. Understanding billing cycles goes into the terms.
Say what you actually want
"Cancel my account" and "cancel my hosting but keep my domain" are different requests, and the second one needs saying explicitly.
Put it in writing, and keep the reply. A cancellation that removed more than you intended is much easier to discuss when the request is on record.
After it is gone
Confirm the new site works from outside your network, on a phone on mobile data instead of the machine you have been testing on.
Send a message to each mailbox and confirm it arrives. Mail is the part that fails silently, and nobody reports mail they did not receive. The launch checklist explains the rest of the post-move checks.
Then keep that final backup for a year. Storage is cheap, and the thing you need turns up months later.
If the site is going to someone else rather than to another host, the domain needs handling differently. How to Transfer a Website to a New Owner has the detail.
Test the backup somewhere else before you cancel
A backup taken from an account you are about to close has one chance to be correct, and the only way to know is to use it.
tar -tzf backup.tar.gz >/dev/null && echo "arsiv acilabiliyor" tar -tzf backup.tar.gz | grep -cE 'homedir/|mysql/' tail -2 mysql/*.sql | grep -i 'dump completed'
Better still, restore it onto the new host and open the site before the old account goes anywhere. That converts an assumption into a fact while the original is still available to take a second copy from.
The failure this prevents is specific: an archive that extracts but contains no databases, or a dump that ends mid table. Both look entirely normal until the moment they are needed, which by then is after the source has been deleted.
Write down what the old account was doing
Sites depend on things configured once and never looked at again, and those settings disappear with the account.
crontab -l ls -la ~/etc/*/ 2>/dev/null | head grep -rn 'API_KEY\|SECRET\|SMTP' ~/public_html/wp-config.php ~/public_html/.env 2>/dev/null | cut -c1-60
The list worth capturing: scheduled jobs and what they do, mail forwarders and filters, any address that redirects elsewhere, the PHP version and its limits, and every external service the site authenticates to.
Forwarders are the most commonly lost. They are invisible from the site, nobody remembers creating them, and mail addressed to those aliases simply stops arriving at the new host with nothing to indicate why.
Keep the old account until the new one is proven
The overlap is the cheapest insurance available and the one people decline in order to save a month.
Run both for a full billing cycle. Point the domain at the new host, watch the old one's logs to see what is still arriving there, and only cancel when that traffic has stopped.
tail -f ~/logs/example.com | grep -v ' 30[12] '
awk '{print $1}' ~/logs/example.com | sort -u | wc -l
Requests still reaching the old server after DNS has propagated are systems using a hardcoded address: a payment callback, a monitoring check, an integration configured years ago. Each one is something that will break the day you cancel, and this is the only period in which you can find them without an outage.