The need for SharePoint upgrade
SharePoint has become an essential need for most of the organizations trying to achieve professional portals or intranets managing their internal and world wide business. Going into the SharePoint domain makes a lot of hard and error-prone developments out of the box with built-in reliable features.
SharePoint 2010 brought us some major changes compared to MOSS 2007. Branding and customizations became a lot easier. Wider variety of out-of-the-box workflows has been included specially in SharePoint Designer 2010's built-in actions and steps for custom workflows. Service applications and their connectivity and configurations to specific web applications. Social collaboration and engagement is also one of the major new features in SharePoint 2010. There are much more new features in SharePoint 2010 than there in MOSS 2007, to have the full details please have a look at http://office.microsoft.com/en-001/sharepoint-server-help/what-s-new-in-microsoft-sharepoint-server-2010-HA010370058.aspx
This guide is written for all SharePoint fans, from highly sophisticated developers to beginners who have a slight idea about SharePoint structure and internals. This guide will give everyone good insights to what issues and cases that can be met in the SharePoint upgrade and migration journey.
There are two upgrade approaches from MOSS 2007 to SharePoint 2010. The first step in the migration plan is to decide which approach will be followed and will be the best fit according to your different organization factors. The choice between the two approaches depend on your organization's requirements, infrastructure and business.
Before going into details with the different upgrade approaches, there is an important term that's going to be widely spread across the SharePoint upgrade guide posts that needs to be highlighted. It's the SharePoint farm.
What's the SharePoint structure and the farm?
This section is for the SharePoint beginners. If you find yourself familiar with these terminologies please skip this part and continue to the next section.
If you are an ASP.NET developer, you used to build your web applications using some ASPX pages with some custom server-side code written for every page to handle a particular problem or logic. I will assume you have also a database that's connected to your web application and connections are placed there in <connectionstrings> section in the configuration file Web.config. In addition to a mail server that the web application uses to send emails to different users.
The SharePoint structure in a nutshell is that since it's built over ASP.NET. You will find some similarities between the above structure for the ASP.NET web applications and the SharePoint web applications except for some differences in the structure. SharePoint does not have any physical server-side written pages or sites. For every SharePoint web application provisioned on the IIS it has a content database on the database server, where it stores the content for every site collection and sub site in the web application. Also connection to mail server can be specified and configured from the site settings page on the SharePoint site itself. Also there will be an Active Directory server, that's connected to the SharePoint web server and the database server, that contains the organization's accounts and structure. Of course these are the normal differences between any ASP.NET custom web application and a content management system (CMS).
Your organization may have more than one server as a host for the SharePoint web application. That's where the load balancing comes from to achieve high performance and reliability.
The SharePoint web server(s), database server, email server and active directory server are your SharePoint farm.
Back to the SharePoint upgrade strategies and approaches. The two approaches are the In-Place upgrade model and the Database-Attach upgrade model.
1. In-Place upgrade model
In this approach you upgrade your SharePoint version from MOSS 2007 to 2010 using the same farm. This can be done using the new SharePoint 2010 setup file. This model gives you the advantage of keeping the same farm settings with the same customizations but, in return, this upgrade model has no roll-back if it's started and you may lose everything if it has failed during the upgrade for any reason.
2. Database-Attach upgrade model
In this approach you will create a new farm, preferably with the same specifications, and you will install the new SharePoint 2010 on it, you will move all your customizations to this new farm and upgrade your MOSS 2007 databases to be used by the new upgraded SharePoint 2010 web applications. This approach will give you the advantage of being safe from any failures. You always have your old farm there untouched as a back up but, in return, it will cost you building a new farm with new settings and extra steps for upgrading the SharePoint content databases and the customizations.
Every approach has its own advantages and drawbacks. According to your organization's nature and based on which one is your organization's best fit, you can choose one to follow. In this post the Database-Attach upgrade model will be chosen with in-depth illustration and details.
The Database-Attach upgrade strategy
- The new farm topology and specifications: Knowing nothing about the old farm structure, how can you use SharePoint administration and built-in tools to find out how the old MOSS 2007 farm looks like and based on it, you will build the new SharePoint 2010's farm.
- Moving old farm installations to the new farm: To have the new farm ready for SharePoint upgrade you have to install on the new farm everything that was installed on the old farm. This topic will guide you through this.
- Applying SharePoint customizations: This is the heart and the most difficult part in the SharePoint Database-Attach upgrade model journey. This topic will guide you from knowing nothing about the customizations that are there on the old MOSS 2007 farm to having them all on the new SharePoint 2010's farm.
- Upgrading content databases: The actual upgrade to the old MOSS 2007 content databases to be applicable for SharePoint 2010 is done in this topic. This part usually takes a lot of time depending on the old content database size.
- Shared-Services Provider (SSP) migration and my sites: Upgrading user profiles from MOSS 2007 to SharePoint 2010 and my sites.
- Visual upgrade: When you reach this part, you will find your upgraded web application will have no difference in user interface and user experience. It will be the same as your old MOSS 2007 user interface. This topic will guide you to visually upgrade the web application's user interface (like including the SharePoint 2010 ribbon) and user experience.
- Post upgrade checks: The final and most important step in the whole migration plan is this step. It's about finalizing your upgraded site and testing it against any issues.
Following the above steps you will have your old MOSS 2007 web application upgraded to SharePoint 2010.
Enjoy SharePoint 2010's new features
If you have performed all the steps in the previous section successfully, then congratulations... You have upgraded to SharePoint 2010. Enjoy the new features and advantages.