This guide is quite detailed and covers some services that may or may not be specific to the situation you're in.
This guide covers moving mailboxes, email forwarders, and a site. Specific site migration instructions aren't covered in this guide as how you move a site varies entirely according to how it has been created. Please take this in to account when reading this guide.
This guide is also order specific and works around DNS caching and provider specific policy based service termination based on domain transfers.
It's advisable to read all of this guide prior to taking any migration specific actions (this is chiefly because we don't have visibility of how losing providers operate).
1) Buy the hosting account placing the order against the domain on which the site will run (if you don't want to be financially responsible for this, open a new account in the name of the party who will be financially responsible, and place the order from within the newly created account). If there's the need you can register a new account here:
https://my.netnerd.com/register.php
2) Add the/any additional domains (that are only going to be used for mailboxes or email forwarders) as aliases to the hosting account that's been purchased.
3) Upload the site, then if you want to work on it prior to repointing DNS edit your local hosts file (it needs to be purchased to allow us to specifically advise with regard to this point), when you're happy with the site in the account held with us...
4) Create all required email forwarders and mailboxes.
5) Take a local backup of all mailbox content (via the mail client currently used to access email) on a per mailbox basis.
6) Make all nameserver changes (immediately after step 5) via the old/loosing provider.
7) Reconfigure the mail client being used to connect to mailboxes held in the account with us using IMAP.
8) Import the email data backed up in step 5 to the mailboxes added to mail for mac in step 7.
9) Place orders in for the domains to be transferred via the respective netnerd account (or ask us to do it, providing the names and email address specific to the account you'd like them allocated to when doing so). For most domains (.com, .net, .org etc) you'll need to unlock the respective domain, and provide it's EPP code when setting up the transfer, then pay for the transfer to be initiated. For .uk domains, simply place the domain transfer order, then...
10) Change the IPS tags against all domains being transferred via the old/loosing provider (for .uk domains only).
When you make the nameserver change (step 6) there's a period of 24 hours where some mail may route to mailboxes with the old provider. This can't be avoided, and may dictate the need to access webmail to check for these (speak to the old provider for any clarity in this capacity). During this 24 hour period site traffic may also route to the old provider. Again this can't be avoided and may dictate the need to leave the old site on line during this period.
If you operate in the manner outlined above, it minimises the effect of DNS propagation. DNS dictates where the site loads from and where mail routes. The whole idea of the above is that you entirely prep the account held with us with everything prior to making DNS changes (nameserver changes). This also dictates the need for you to override public DNS with the hosts file edit on your computer to force it to load the site from our platform, while everyone else (who's using public DNS) sees the old site. Operating in the manner detailed above means no site downtime as visitors either see the old or the new site (but nobody sees no site) regardless of whether they have cached DNS or not (provided you don't cancel services with the old provider until you've allowed time for DNS to propagate post nameserver change, or that the old provider doesn't terminate services based on domain transfer).
Also, some providers terminate services should a respective domain be transferred away from them. We don't have visibility if this is the case or not in this instance (speak to the loosing provider for clarity if you need to). If you carry out the domain transfer as the last action, this mitigates this type of policy as best you can should you not know if it's in effect or not.
