I don't have/use a checklist Jill, but the number one thing is redundant backups.
Do not count on a single backup. If it fails... than oops!
PHP MySQL dumps are famous for not importing correctly.

I would move things, test, than transfer the DNS for each site.
What you have for assets and what your running will certainly make your checklist flexible.

A few simple things:
FTP OR SFTP to server, backup all assets and verify.
Using a database? Dump the database and verify. (You might dump the DB in several formats.. Gzip, sql, etc)
If using WordPress, good idea to export. Also create a full backup using something like BackupBuddy.
Some people feel comfortable creating full backups in Cpanel. ??... me not so much.
However, you can never have too many backups.
I personally build and test everything locally in conjunction with a private repository (github, bitbucket, etc..) , so going live is very easy
I wouldn't cancel anything until the new hosting is up, live, and tested.

• Download all assets incl. databases
• Verify integrity of all that.
• Create lists of all emails, email forwarders, ssh keys, etc.. you might have setup on current host.
• Setup new hosting environment
• Move all assets to new host
• Setup the details (email, forwarders, etc...)
• Test the site (even without the name servers pointed here you can usually temp use the ip address)
• Modify the DNS for the new hosting

Worth noting for the WP blogs: If you just export from Tools => Export, and dump the DB in PHPMyAdmin, and move all the assets, you may lose many settings such as widgets, theme settings, etc... and you don't want to have to recreate all that.
A good cloning/backup plugin will make it so much easier to keep everything exactly as you have them now. I personally like BackupBuddy.
Verify your new host's php version. If it's older you may find plugins/themes breaking.

If you are using cPanel/WHM, just use the transfer accounts function.

Most new hosts will help you migrate. At least good ones will. Ask.

Who's the new host?
Who was the old one?

Most of the important points are above, but I'd just add a few things which are particularly relevant if you're trying to minimize downtime.

1. Set up DNS records for the new and old sites as subdomains of your domain name. Thus is your domain name is example.com, you'll have a record for old.example.com pointing to your current site and new.example.com pointing to the new site.
2. Set your DNS TTL for your root domain and www (assuming that's your primary subdomain) to a low value at least a day or two before the move. When I'm doing a move, I'll even set it as low as 60 seconds.
3. As much as you can script your move including (but not limited to) copying all your files, backing up your database and loading them onto your new server(s). If you don't know anything about scripting, "as much as you can" might be none at all, but the more you script your move, the less likely it'll be that you'll forget something or make a mistake when you're making the move.
4. Whether you use scripts or not -- rehearse your move, writing down (and crossing off) your own checklist as you go along. Do this until you are 110% comfortable with the move. Then do it again.
5. Don't forget to redirect traffic on the old server to the new server after you make the move (this is one reason why having those new and old subdomains is helpful). Even with a low TTL, DNS propagation can take a while since you can only suggest how long entries should be cached and not force it. The last thing you want is to have two sets of user data on two different servers and then have to merge them somehow.