1. Use a standard resource naming convention - The naming convention is not as important as keeping it consistent.  In other words, when you add resource names to your project, if you input them as "First Name Last Name", always enter them that way.  Not just in one project, but all project schedules.  Having a consistent naming convention will make the importing of projects into Project Server much smoother.  Using a standard naming convention could even help you in the stand alone world if you attempt to set up a shared resource pool.  So which naming convention should you use?  Based upon best practices in the industry, the recommended approach is "Last Name First Name".
2. Do Not use special characters in resource names - Notice in the naming convention above, that I did not insert a comma between Last Name and First Name.  Special character are BAD within the Project Server world.  They tend to cause problems within the database.  So what are the special characters?
   /";:<>|[],.'?~`!$%^&*()-+={}\,
3. Do Not use special characters in the project file name - Again, these will cause problems with the database.  The characters are the same as above.
4. Develop and use a standard template(s) - Every project is unique, right?  But that does not mean they don't follow standard phases.  Perhaps your organization has already documented a standard project life cycle.  Turn this into a MS Project template and use it as a starting point for all future projects.  If this does not exist, look across all the projects of your past to develop that standard template.  As a final alternative, simply use the PMI phases of Initiation, Planning, Execution and Closure (you could also add Control, but dealing with that phase in MS Project warrants another article!)
5. Baseline your schedule - Yes, I said it.  I know the word Baseline sends many people into a frenzy.  This frenzy is caused by fear.  Either fear of being punished for not meeting the baseline, or fear of the unknown for not fully understanding the baseline.  Either way, it is up to you to change the culture.  The baseline is nothing more than a snapshot in time.  Inevitably, projects will change causing us to drift away from our baseline.  It is up to the team to determine how best to get back on track.  But without the baseline, we will never know we are off track!  Changing culture takes time, but you can do it by being consistent; once you have an agreed-upon plan, baseline it! (Be sure to view a future article about "How to Develop a Realistic Schedule")
6. Manage the schedule - Don't just use MS Project to develop your initial plan then put it on the shelf once execution begins.  Keep it current.  The schedule is a living / breathing document.   Use it during status meetings with your team. You can filter it to examine tasks that should have completed, then update task completeness, and durations as needed.   You can look ahead to see what tasks are about to begin.  Finally, with the implementation of #5, you can compare your current schedule with your baseline to determine your progress.
7. Share your schedule - If you have been diligent with #6, then sharing your schedule should cause no worries.  The method for sharing your schedule may vary by organization.  You could copy and paste tasks into an email, create a PDF, save it to the web or send out as an .mpp attachment.  Either way, you want your team members to have the most current information about the project and their tasks. Sharing the schedule will also get team members more comfortable with looking at information within a MS Project format.  Being able to understand and manipulate data in a Project format will be valuable when you move to Project Server.  Within the Project Server world, each schedule is viewable through a web interface known as PWA (Project Web Access).  Any team member can view this version of the schedule online and manipulate it to get information that is valuable to them.  THE BEST PART IS they can not edit the data!

Realize that some of these things are tool related, while others are more process related.  But implementing any or all of these changes will help prepare you (and your organization) to move from Project on the desktop to Project Server.