A few recommendations based on my experience of a few global SharePoint upgrade projects:
* Timeline - Don't be in a huge hurry - it can take as long as a year or longer for a large migration (eg. 50K users, 50K+ sites). Break into 2-3 phases and provide plenty of time for testing. At the minimum you are going to need phases: planning, optimization, migration testing, and upgrade, with some overlap.
* Customizations - not just unghosted pages but any SharePoint objects written to the content DB, will cause some grief. You may need to write custom code to detect and list any of these, besides of course the upgrade tool. Then decide on a course of resolution for each type.
* Past History - How "clean" is your MOSS 2007 environment? This is the other "gotcha" - if there was no proper governance, rules enforcement by SC Admins, and users had too much access, you have a headache. You will need to resolve those errors that have been put off for oh so long. A well maintained SharePoint or event log on the other hand is a great positive.
* Test Environment - Build robust Dev and QA Farms for real testing, involve your entire Staff and SCA's. In addition, you may, for a while, need to maintain two separate environments for development work - for example one for VS 2008/.net 2.0/MOSS 2007 and the other for VS 2010/.net 3.5/SP 2010. This needs to be planned as individual pieces are individually migrated and quality tested, ready for upgrade.
* Separation of Areas - database migrations (content DB, user profile DB), development work (features, web parts, custom pages), site administration (security, permissions, network access, service applications), and branding (look and feel, site themes, site definitions, navigation) should ideally be done by separate teams or individuals with specialized skill sets in those areas.
This is of course a short list, by no means a complete one. Good luck with your upgrade project!
* Timeline - Don't be in a huge hurry - it can take as long as a year or longer for a large migration (eg. 50K users, 50K+ sites). Break into 2-3 phases and provide plenty of time for testing. At the minimum you are going to need phases: planning, optimization, migration testing, and upgrade, with some overlap.
* Customizations - not just unghosted pages but any SharePoint objects written to the content DB, will cause some grief. You may need to write custom code to detect and list any of these, besides of course the upgrade tool. Then decide on a course of resolution for each type.
* Past History - How "clean" is your MOSS 2007 environment? This is the other "gotcha" - if there was no proper governance, rules enforcement by SC Admins, and users had too much access, you have a headache. You will need to resolve those errors that have been put off for oh so long. A well maintained SharePoint or event log on the other hand is a great positive.
* Test Environment - Build robust Dev and QA Farms for real testing, involve your entire Staff and SCA's. In addition, you may, for a while, need to maintain two separate environments for development work - for example one for VS 2008/.net 2.0/MOSS 2007 and the other for VS 2010/.net 3.5/SP 2010. This needs to be planned as individual pieces are individually migrated and quality tested, ready for upgrade.
* Separation of Areas - database migrations (content DB, user profile DB), development work (features, web parts, custom pages), site administration (security, permissions, network access, service applications), and branding (look and feel, site themes, site definitions, navigation) should ideally be done by separate teams or individuals with specialized skill sets in those areas.
This is of course a short list, by no means a complete one. Good luck with your upgrade project!
