Friday, November 16, 2007

Migrating SharePoint 2003 to SharePoint (MOSS) 2007

Overview
Approximately 3 years ago, we successfully completed a project to migrate the corporate intranet to SharePoint 2003. The project was primarily driven by IT, wherein we analyzed and selected a product which would meet the needs of the business; hence the business would thank us for finding a great product and adopt it. We selected the right people to be site admins and delivered training to these individuals with the mandate that they would drive adoption in their respective business units. However this did not turn out to be the case. We noticed that initially the user adoption increased but then started tapering off as users started finding little quirks in the product. Some of the notables were that search did not always get the most relevant results, it was cumbersome to navigate from one site to another or to get a feel for where you are in the site hierarchy, navigation links were not security trimmed leading to frustration etc. to name a few. We only branded the main areas of SharePoint 2003 but not the sites which led to an inconsistent look and feel. Finally, there was no governance committee to oversee the intranet and hence company colleagues were free to do what they liked. This amounted to information being stored in the form of documents in document libraries, which was hard to find without explicit instructions.

Below is an example image of how the SPS 2003 intranet looked earlier this year.














The MOSS 2007 opportunity
MOSS 2007 provided an enhanced feature functionality set. We performed an initial assessment against the pain points and determined that the MOSS enhancements/OOB features met IHS strategic goals. We went over the features and placed them into two buckets based on priority, ones that we need now vs. others that could wait. This helped us decide the licensing model for MOSS. We devised the hardware architecture and evaluated the different migration approaches/risks. At the end of this phase, we decided to go with the Content DB migration option. The reasons for this are follows:
1. IT initiative to consolidate to a single hosting center with leading practice hosting services and monitoring. Our intranet was hosted on 32 bit architecture and we preferred to move to 64 bit to utilize the performance benefits that it offers. Another motivator was that the cost difference between the two was minimal.
2. We had over 100 GB of data, but the majority of data was stored in WSS site collections, not in SPS areas. We only had a few areas and we were willing to lose those, as they did not contain any required information, they were just hooks into the appropriate WSS sites. We also had a few custom site definitions - but we were only interested in upgrading a couple of them.
3. We tried a couple of trial runs of the migration using the content database approach - and things migrated over pretty well for the most part.
4. Microsoft does not recommend the in-place upgrade because if something went wrong during the migration, it’s difficult to restore.
5. We did not want to go with the gradual migration approach as well because there was risk in our mind. This included installing both MOSS and SharePoint 2003 on one production server, performance issues this may have caused, disk space issues we may have run into given that we were running out of disk space on that server.
6. We also evaluated four 3rd party tools that we felt could assist us in the migration but turned them down because they did not meet our needs completely, or that significant post migration cleanup would be involved.

Finally, the intranet goals for IHS were:
1. Strategy / Governance
Define intranet as critical component to corporate communication strategy
Solidify our intranet strategy, usage and measures
Form an internal governance council and supporting processes
2. Content Migration / Foundation Upgrade
Coordinate migration with business to minimize user impact/downtime
Support customizations and integration points
3. Branding & Content Re-organization
Take a role/persona approach versus functional
Minimize user clicks / navigation to critical information
Implement a page based delivery
After finalizing the migration approach (which was our single biggest X factor), we went back to planning the migration and worked on the documenting the four phases that any SharePoint migration consists of: Planning, Preparation, Migration and Clean Up. A big misconception in people's minds is that the planning and preparation phases are very small and the actual migration and clean up phase is what matters. Nothing could be further from the truth. To the contrary, the planning and preparation phases are critical to the migration and should be allotted ample time. To underscore how important the planning phase is, here are some of the tasks we completed in the planning phase: understanding the big picture and defining future state, understanding the current deployment and usage, assessing SharePoint 2007 features, licensing, planning and validating architecture, getting buy in from all business units and executive sponsorship, choosing a migration option and running test migrations, planning customizations, creating a networking and domain name plan, creating a communication plan, creating a testing plan and training users on moss etc.


IHS Project Approach
Here we will provide a high level overview of the approach we took with the SPS 2003 to MOSS 2007 migration.
1. We used standard software lifecycle methodology (Design, Develop/Test, Deploy).
2. Solicited executive sponsorship and created a governance team. We also formed a collaborative project team (IT & Business). This gave us a big boost as the corporate communications and key business stakeholders "owned" the intranet migration and therefore took it upon themselves to push for governance and adoption. IT was no longer a driver, but a facilitator.
3. Gathered necessary requirements for design.
4. Defined scope – business approval. We effectively split the project into 2 phases: the as-is content migration to MOSS and then subsequent creation of the company brand. We separated these goals into 2 different projects to tackle each one individually and ensure nothing fell through the cracks juggling two sets of tasks.
5. Used content DB migration. The reasons for this decision are explained above.
6. Did not upgrade 2 out of 4 custom site definitions as we felt that MOSS would address these needs OOB. We wrote custom site definition and upgrade files so that the remaining site definitions would upgrade successfully.
7. Did not migrate MySites as the user adoption was very low and we discovered through communication that the users would not mind losing their SPS 2003 MySites.
8. Did not migrate any 3rd party Web Parts as these had to do with navigation. MOSS 2007 provided this functionality OOB.
9. Did 4 trial migrations to ensure that content migrated and the development team was comfortable with the result. This also allowed us to tweak our steps in the migration phases.
10. Established Training and Communication plans for end users and delivered worldwide training.
11. Created a testing plan and performed testing to ensure that the hardware would be able to serve our users and that there would be no performance concerns after go-live.
12. “Froze” SPS 2003 for 3 days as we moved the 100 GB database over and completed the migration, clean up and final testing for MOSS. This means that SPS 2003 was in a read-only state.
13. The DNS change was transparent as we just changed the entries to point to the new servers. The users entered the same URL and they were taken to the MOSS 2007 intranet instead. We still maintained the old intranet as a different URL if users wanted to compare or felt they had missed something. Fortunately the number of such requests was less than 5.
14. Performed migration in off hours and over the weekend. This limited the downtime as a small minority of users use our intranet over the weekend.
15. Re-architecting SharePoint content in terms of pages. As mentioned previously, without active governance our SPS 2003 had become more of a document repository than we were comfortable with. So the governance team took it upon themselves to engage colleagues from various business units who would build informational pages and links to next steps. This is an ongoing operation and will be discussed in part 2 of this series.


Here are the high level upgrade experiences
1. The upgrade took 4 hours. We migrated 800 sites and 100 GB of data.
2. All the WSS site content migrated with the same structure as SPS 2003.
3. Search scopes, keywords, best bets, audiences were recreated as these did not migrate.
4. We needed 2 days of post migration cleanup and tasks – links, web parts that were not migrated, scripts, integrations with other applications.
5. Communication had to be repeated as some users did not read that the intranet would be read-only.

To learn other migration Do's/Don’t's and if you need further information about the tasks we completed in each migration phase, please see the slides (from my September blog post) from a recent presentation at the Rocky Mountain SharePoint user group where we spoke about our migration experience.
After the migration, here is what our SharePoint intranet looked like. We added the Under Construction image to indicate that this was a temporary look before the final branding.




In part 2 of this series, I will talk about how we branded SharePoint 2007 for our intranet.

4 comments:

Anonymous said...

You mentioned about the third party tools but u never use them right? In which cases we need to use third party tools?

Regards,
Amit

Ernesto Gaia said...

Hello,

I´m writing from Brazil and would like to talk more about this Process. Can we exchange some experience? My email is: ernestogaia@gmail.com

tks

Ashwin Raj said...

I am encountering a problem which I don’t believe is an environment specific behavior. Essentially a document library, that existed before the migration, has content management disabled (which is to be expected since SPS2003 does not support content types). The document library is a regular one and not customized in any manner nor does it have any event listener implemented, etc. It has about 10 user created columns. When I enable content type management on the library, the Document content type is automatically added, which is expected behavior. However, the undesirable side-effect is that all the columns are being added to this Document content type. This should not happen. Would you have any insight into this behavior and how I can prevent it?

digital signature Microsoft said...

It's wonderful that you devote time to articles like this where so many people can truly benefit.