Now that you created your lists, did your backups, signed up with a new host, and were activated with that new host, you are ready to begin the transfer:

1. Create Domains: Each host is a little different, but all of them have an equivalent step to "creating a domain".  Start by establishing the domain for your least impacted site that at least crosses over some significant common features (website, e-mail, FTP).  In this way, you can test the effectiveness of a single transfer before committing to the rest.  This "one-at-a-time" approach helped me a couple of times over the past couple of weeks.
2. Create Webs: Again, each host is a little different in how they let you set this up.  Some combine the "create domain" and "create web" step into one, and then allow you to specify "alias" domains to point to the original one you set up the web for.  Others keep these as separate steps, and allow you to set up and specify a domain as a "pointer" to another domain.  Again, try to review the host's control panel tool before starting the transfer process so that you are comfortable with the workflow.
3. Create FTP Account(s): You'll need to set up at least one FTP account in order to start uploading your website content.  Some hosts provide you with an initial account to use, but for others, you'll have to set one up yourself.
4. Find or Establish a Temporary URL: Here's another Catch-22.  You're ready to upload your content, but you're still hosting your site at the old host, and are not ready to transfer the domain.  Some hosts will provide you with a temporary URL, which may look something like this: MyDomain.com.Myhost.net.  Others require you to click a button to generate a temporary URL for the site.  Others may supply you with only the IP address of the shared host (most likely, on a budget plan, you'll be on a "shared host" plan, with several websites from several of their customers living on a single IP address).  Your login account would dictate the folder you'll be placed into upon FTP connection.
5. Connect Via FTP: Different hosts will provide you with a different folder structure to use.  Some will give you a root folder in which you need to create a subfolder for each site.  Others will require that you place your initial website into the root folder, and require you to create subfolders for your additional sites (making it seem like those other sites are second class citizens).  Others will provide you a different FTP account to access each site.  Personally, I prefer the first option, because it allows the convenience of maintaining all sites from a single login.  You could usually create separate FTP accounts on your own, if you want other individuals maintaining sites they're responsible for, without having access to all the sites.
6. Upload Site Content Via FTP: Most hosts provide a web-based control panel alternative to FTP, but those are usually very painful options that you should only use when in a bind, since you can usually only upload a single file at a time.  Others provide a web-based FTP client.  But with several free FTP tools available for download, I strongly recommend this option.  As you upload your content, save any database files for last.
7. Setup Databases: Depending upon the host, you may need to "initialize" or "setup" database areas explicitly (look for options like MS Access, SQL Server, MySQL, ODBC, etc.) before uploading your database files.  Take care when doing this to understand the implications.  One host I used only supported FileDSN instead of SystemDSN, requiring me to change code before uploading.  I ended up resorting to non-DSN coding changes in this case, because it never quite worked through DSN.  Yeah, I'm using Access for one of my sites.  I know, I know.  I plan on rewriting that site soon, anyway.
8. Set Web Server Settings: I'm only familiar with IIS right now, so I'll only mention that here.  Most control panels allow you access to the most commonly used IIS settings.  Anything not available via the control panel will require contacting technical support.  Start by setting up any virtual directories.  Then specify any "applications".  Then, specify the technology you will be running the site under.  These days, under IIS, you'll always have an option for ASP, you'll usually have options for PHP and CGI, and you'll usually have an option for ASP.NET 1.1 or 2.0.  Beware that some hosts only allow 1.1 OR 2.0 for a website, where others allow you to set this independently for each application.  On one of my hosts, I had to convert to ThinkJot for my blog instead of dasBlog, because the host did not allow for a mix of 1.1 and 2.0, and under 2.0, they did not allow for full trust rights.  ThinkJot is a converted version of dasBlog, equivalent in every way to dasBlog 1.8x except for the fact that it will run fine under medium trust.  A complete rewrite of ThinkJot in ASP.NET 2.0 is currently in alpha.  Then set the correct access rights to any folders for the site, if they stray from the default (usually when you need write rights).  Again, each host gives you different levels of control here.  In my current host, I had to give write rights to the entire site, just to be able to write content and log files under a couple of subfolders.  Finally, set any default page names you'd be using on the site.
9. Test the Website: Now is the first moment of truth.  Try hitting the site via the temporary URL or IP address.  Keep in mind that some sites may contain configuration settings that point to a known "home page" URL for certain functionality.  In these cases, temporarily change the config file to point to the temporary URL or IP address, or just trust that if the home page works, the other functions will work after converting the domain.  It depends upon your comfort level at this point.
10. Setup E-Mail Accounts: Now that the site seems to be working, you'll need to get the e-mail accounts setup to prepare for the cutover.  This can be a little tricky.  Setting up the accounts (lists, groups, forwards, etc.) is pretty straightforward (although some hosts require you to also specify a maximum mailbox size for each account, divided from your maximum allocation.  Still no big deal, and easy to change after the fact.  The tricky part is making sure that any leftover e-mail sitting at the old host can be accessed by everyone before cancelling the old host.  Usually, the old host's webmail can be accessed via a generic URL (only your e-mail account login should be required for accessing the old mailboxes).  I've had occasions where I was forced to go into someone else's mailbox and manually forward the leftover messages to their alternative address, in order to cancel the old host quickly.  I make it clear that I have access to other people's accounts for purposes such as this, only.

In my next post, I'll go through the steps for completing the transfer, beginning with the DNS change, and then discuss tying up any loose ends.

My Web Hosting Nightmares, Part 1 - Background
My Web Hosting Nightmares, Part 2 - Preparing for the Transfer
My Web Hosting Nightmares, Part 4 - Completing the Transfer
My Web Hosting Nightmares, Part 5 - My Continuing Story