Get the new server up and running and configure anything that you need, like email before you start moving anything. Think of it like you would get the water and electricity going in a house before anyone moves in.
Use your existing backups and restore them to the new server. Leave msdb, model, tempdb and master alone. When you bring up the database on the new server, go to the old server and set the corresponding database to 'OFFLINE' or detach it. This prevents a surprising number of 'oops' problems. Leaving the old database files offlined or detached, but in place, gives you a possible way out if something unforeseen and catastrophic happens. (Failure of the new SAN, for example.)
Use SSMS to script out linked servers, operators, jobs and any other, similar server-level objects. Remember that SSMS will not script out a password in a linked server SQL login, so you will need to know what it is. If you can, use trusted security for logins.
Don't forget about DTS and SSIS packages.
If you have a lot of items to do, you might need to write a little scripting. If you are going from SQL 2000 to SQL 2005, it is a good idea to reindex everything once you get it onto the new server.
Use sp_help_rev_login to help recreate your logins on the new server. KB article describing sp_help_rev_login This will preserve passwords and SIDS for SQL Server users, if you are not using domain security.
Don't forget that you may have to update connection strings in any application that touches your databases. If you are going to "throw away" the old server, or reformat and use it for something else, talk to your network guy and ask him if he can recreate the old name as a "DNS C name", and have it point to your new server. This is a butt-saver when you have lots of connection strings (that might not be under your control, say in old Access databases on someone's desktop in some far-flung corner of the company) pointing to the old server.