It probably seems logical that you should avoid moving servers if you can. Unfortunately, sometimes you just can't avoid it. In that case there are some things you can do to make your experience more trouble-free.

The Easy Way to Migrate Servers

If you use cpanel or Plesk, each offers a migration tool. Use that tool on the new server to automatically transfer your entire domain from the old server. It *should* pull all relevant data, email accounts, cron jobs, databases, etc. After successful completion, merely check that the new site is working properly (under the site preview option or the direct IP address if you are running a dedicated IP). Once everything looks good, go to your domain registrar and make the nameserver changes to specify your new server's nameservers.

One note: double-check the DNS table entries after migration. I have noticed on some of my migrations that the NS1 retained the original server IP.

Another note: I also noticed that, at least with Plesk, some junk files get added to the migrated domains, namely css, img, picture_library, plesk-stat, and test folders. They won't do any harm, but I prefer to delete them.

Final note: The migration tool has its own set of rules. One of the Plesk rules is that you can only transfer a domain with a dedicated IP to another dedicated IP and a shared IP to a shared IP. You might try creating a test domain on the old server and trying to move it over as a test to make sure the migration tool is working properly and you understand it's process completely.

The Hard Way – Manually Moving Severs

Things to Do Before DNS Switch

Action	Status
Read Moving to a new web host by Google's Matt Cutts for a recommended way to move to a new webhost or IP address without having problems in Google
Verify IP address not blacklisted; attempt to whitelist if appropriate (http://www.mxtoolbox.com/blacklists.aspx). It's best to do this first as you may be able to request a clean set of IP addresses from your new host before starting the migration work.
Backup entire relevant directory and sub-directories (e.g., httpdocs on a Plesk setup) and import to new server. To do a compressed archive use the following: tar -zcvf archive.tar.gz * To restore the archive on the new server use: tar -zxvf archive.tar.gz I believe this should maintain the existing file permissions and ownership rules, but you should verify this is the case. In the event you are using a secure connection (https) for your site, remember to backup the httpsdocs directory as well.
If you have any server-side scripts outside of your main directory, remember to backup and transfer those as well (e.g., automysqlbackup)
Email Accounts setup (individual accts, catch all, bounce, postmaster, aliases)
Customized 404 page(s) if appropriate
php.ini file modifications if necessary (timeout, default index, magic_quotes, etc.); if moving servers, download copy of old server php.ini file as reference
Web analytics setup (may need to move log files from old server if moving servers)
FTP / Secure Shell accounts
Password protect relevant directories
Apache settings (no viewing directories, etc.); if moving servers, download copy of old server http.conf file as reference
cron jobs (note that some hosting companies provide special versions of WGET, etc. so if your old server does make sure to convert the cron commands to whatever is appropriate on the new server)
SSL certificate(s)
Setup and copy database(s). If possible, try to maintain the same username/passwords. If not possible, change any scripts that access the DBs. Also, though not common, if external websites are authorized to access a database, be sure to add relevant permissions when setting up the database on the new server. To move your database content, first dump it on the old server using the following command line command: mysqldump –u username –p password database > database.sql Then use FTP, scp or whatever method you prefer to physically transfer the dumped database file to your new server. Finally, import the dumped database file data into your newly created database on the new server using: mysql –u username –p password database < /path/to/database.sql
Make sure any relevant third party scripts are installed on the new server (e.g. phpMyAdmin, openx, AWStats)
Optimize MySQL both in server side configuration and in your scripts' SQL statements (especially use of indexes)
If you have SpamAssassin or other control panel features enabled be sure to note the current settings and setup on new server control panel accordingly
If you use any scripts that require special server configuration (e.g., ioncube), verify the new server is configured for it properly and that you test the script/application before going live.
Plan for the possibility of an outage in advance by creating a error page (in html in case there is a problem with the scripting engine) that fits the look and feel of your site, and containing a message about how you are improving the site and apologize for the temporary inconvenience. Add the following lines to your htaccess file: #ErrorDocument 503 /absolute/path/to/errormsg.html #RedirectMatch 503 .* If you have downtime, simply delete the "#" at the beginning of each line. Once the issue is corrected, reapply the # and your site will resume normal operation.
A week before you do the move set your DNS refresh times to around an hour. Then down to 15 minutes, 24 hours before the move. Change the times back a few days after the move.
Make the actual DNS change with your domain registrar.

Things to Do After DNS Switch

Action	Status
Test code for CSS, HTML integrity via W3C
Verify all of your cron jobs are working correctly
If you use SSL certificate(s), verify they are working properly on the new server
Use Google Webmaster Tools to verify no problems with the new server
Run a complete DNS report (http://intodns.com/, http://www.iptools.com/, http://www.pweb.cz/en/dns-test/ http://www.checkdns.net/quickcheckdomainf.aspx) and a reverse DNS check (http://postmaster-us.aol.com/tools/rdns.html)
Run SPF / SenderID test (http://www.openspf.org/Tools, http://www.vamsoft.com/spfcheck.asp, http://senderid.returnpath.net/how.php; or simply send an email from the domain with SPF to test to check-auth@verifier.port25.com. An Authentication Report will be sent back to the email account inbox after a few minutes with complete details and results of summary, SPF check, DomainKeys check, DKIM check, and Sender-ID check.
Verify any ad code (e.g., Google AdSense, TextLinkAds, etc.) is working on the new server
Verify any third party monitoring scripts (e.g., Google Analytics) is working on the new server.
Leave your existing server active for approximately 72 hours. At the end of that period, set the old server to respond to requests with a "Bad Request" message. This should force search engines to update their cache immediately, and guarantee that the engines get the correct new information.
Delete the site from the old sever and test again. It's not likely but possible that broken code and improperly migrated databases worked because they were on the old site too. Sometimes linking will be by IP also, and you won't catch that until you delete the site from the old server.