Beta and pilot testing routines are critically important to any migration. In addition to gathering technical and usability feedback, beta and pilot tests are great opportunities to build interest and enthusiasm for the new desktop.  But you'll want to ensure thorough testing - missing something, especially in beta, can be painful down the road. Here's some key points:

• Be clear about what you want to achieve in beta
• Make sure you have a check list of items you want specific individuals to test  
• Give as much information  as you can and be clear about what you are NOT giving in the beta and/or pilot. Users often overlook critical flaws because they obsess about what the desktop looks like (or other cosmetic type changes).  
• If there is an organizational customization everyone uses (notification for email on the desktop, etc.) you might want to think about adding it - not having critical functionality like that often distracts testers.

And make use of all feedback - it's priceless to both the project and end user experience:

• Listen to feedback carefully, don't dismiss it because it isn't about the image
• Build in time to accommodate feedback and retest
• Make note of critical feedback and promote it to the next group of users - "We adjusted this based on the feedback from beta or pilot."  Users feel like you are listening to them.
• Document feedback.  Keep a document that keeps track of feedback and adjustments and differences between builds - this is essential for troubleshooting, training, documentation, and communication.

In addition to testing well, you'll want to take advantage of the opportunity to promote the benefits of the new OS,  so make sure you sing benefits - like shortened login time - from the rooftops when you engage testers. 

A good, detailed beta informs a good pilot - which makes the whole migration process go more smoothly.  Rarely has a sloppy pilot (without time to adjust) equaled a smooth rollout.