Upgrading from SharePoint Portal Server 2003 to SharePoint 2010 Part 1

In this post I will go through upgrading SharePoint sites from SharePoint Portal Server 2003 to SharePoint 2010 , I will include directions to use the most relevant upgrade approach, as start Upgrade from SharePoint Portal Server 2003 to SharePoint 2010 is really challenging as there is no direct path to upgrade from SPS 2003 to SharePoint 2010,  first it should be upgraded to SharePoint 2007 as first step then to proceed from 2007 to 2010 version.

One of the most important parts that need to be considered is the custom components ,In many cases, SharePoint 2010 has far more advanced and richer user interface elements which would definitely make the need for some of these custom components irrelevant

The other aspect of SPS 2003 customization was related to branding “look and feel” elements such as graphics and style sheets. Because SharePoint 2010 is dramatically different from SPS 2003 and it has the ribbon control it is recommended that the branding be completely redone using SharePoint 2010 native master pages and compliant style sheets. This will be an opportunity for a fresh look and feel for the portal signifying the additional ground-breaking features SharePoint 2010 will be introducing to the customer user community.

The following is one of the common upgrade paths from SPS 2003 to SharePoint 2007:

The following is the upgrade steps from the SharePoint 2007 environment to SharePoint 2010:

Typically where there are custom solutions like compiled components such as Web Parts and such, it is expected that these components might fail in SharePoint 2010. In some cases these components might seem to work well after the upgrade but it might not be desirable to keep these components in their pre-2010 binaries. For such components it is recommended that they be targeted for the SharePoint 2010 environment and then recompiled after the appropriate testing and validation to make sure that they can live side-by-side with other components in SharePoint 2010 without destabilizing the whole farm.

As mentioned above, there are many factors that make an upgrade from SharePoint Portal Server 2003 to SharePoint 2010 not an easy task. These include some of the following reasons:

• In-place upgrade are not possible because of the need for 64-bit hardware in SharePoint 2010
• It’s is a requirement to have an intermediate upgrade to SharePoint 2007 as there is no direct path from SPS 2003 to SharePoint 2010
• Some custom components might not be compatible with SharePoint 2010

For some of the reasons mentioned above, in this post we will follow an in-place upgrade from SPS 2003 to SharePoint 2007 and then a database attach method into the new SharePoint 2010 farm. The in-place upgrade will preserve as much functionality as possible during the upgrade to 2007. From SharePoint 2007 to SharePoint 2010 we have no choice but to use the database attach method as we cannot perform this upgrade on non-64 bit hardware. Even if it were possible, it better the upgrade to be performed on the final farm in which SharePoint will finally reside.

the following steps illustrates the In-place Upgrade from SPS 2003 to SharePoint 2007

• Run The Prescan Tool in Production
• Fix an Issues identified from the Prescan Tool
• Copy the production database to the Development Environment
• Make the Production Database Read-only
• Start the SharePoint 2007 in-place upgrade in the Development environment
• Test and validate all functionality and Web Parts in the SharePoint 2007 environment

Database Attach Upgrade from SharePoint 2007 to SharePoint 2010

• When all functionality has been validated in SharePoint 2007 move the Content database to the SharePoint 2010 function using the database attach method
• Test and Validate the portal in SharePoint 2010
• Remove and recreate features using SharePoint 2010 as needed
• Start the Feature Gap analysis process
• Enable 2010 Enterprise Search and add all existing Network File Servers as well as all existing internal sites and portals
• Create dedicated file store repositories for each department mapping or mimicking the current File Server directory structures for each department
• Enable use of SharePoint workspace in the portal

When performing the upgrade process, Current SharePoint environment should become in read-only mode to make sure no updates are taking place over the online version. Meanwhile, the upgrade process will take place in the lab environment. After a successful migration, the new portal will become available for users and the old environment will be taken offline to ensure that all users start using the new farm.

The upgrade process will be tested in the lab environment to make sure all issues will be identified, fixed and remedied before performing the actual upgrade. The customer team should be confident enough by performing the upgrade exercise more than once to avoid any complications in the actual upgrade process.

Planning is critical to a successful upgrade project. You must be methodical in your approach, because you will have to prepare all of the solution design areas, from requirements analysis to support. Prepare by assembling the right team, which should deliver business, technical, and project management skills. The team must then establish the working practices and resources that are necessary for the upgrade to complete successfully.

The Upgrade Cycle

Learn

Ensure that you fully understand—and your plan reflects—upgrade requirements such as 64-bit hardware and software. Use the available tools to preempt issues such as missing dependencies or lack of storage capacity. You should know and evaluate the update options for your farm or farms. This should include development of a plan for the completion of all of the tasks that are necessary for all of the versions of Office SharePoint that you must upgrade. You must also ensure that your plan reflects business requirements such as system downtime.

Prepare

Your upgrade plan should reflect what you have learned. It must have an exhaustive breakdown of events in chronological order, so that the administrators who implement your plan have all of the correct components in place. This plan should include all prerequisites. It should also include information about how to identify and manage any existing customizations and how to manage individual solutions and items.

Always establish a fallback position. An upgrade failure may be beyond your control, such as a hardware or power problem, so you must have a plan for ensuring that your business users can still work in the morning.

Test

If you are upgrading a business-critical system, you must always pretest your plan; this should be no different for SharePoint 2010 upgrades. If possible, you should build a test environment and test each component of your upgrade. This does, of course, take time. However, attempting to rebuild a business system after a failed upgrade will take longer, and it will cause greater problems for your organization.

Use copies of production data and hardware if possible, but you can sample data and virtual machines to do worthwhile upgrade testing.

Implement

When you have completed your tests and are satisfied with your mitigation plan, you should schedule the upgrade. You should have established how much time the upgrade will take through your test runs, but monitor the progress of your upgrade by viewing the status indicators. This will help you to assess any time differences between your tests and the upgrade exercises.

Validate

Always validate an upgrade by reviewing logs and testing applications. After a long upgrade, it can be easy to ignore apparently minor errors, but you must check everything thoroughly. As part of your upgrade, you should have experienced users who can test the validity of data to reveal any potential issues. You should also test for user experience (UX) in addition to UI changes. Note that the UX concerns the overall familiarity of your applications, and not just the visual changes in the UI. Your user acceptance testing must ensure that users are happy with any changes to working practices enforced by the upgrade. This will be of particular relevance to users who upgrade from Office SharePoint Portal Server 2003 or migrate from third-party platforms.

Planning an upgrade is more complex than planning a new deployment—it has all of the challenges of a fresh deployment and the additional problems of migrating existing business environments to the new platform. This means that in addition to planning to perform all of the installation tasks, you must also plan a complete review of your existing environments.

The list of tasks that you should perform when planning an upgrade includes:

• Gather business requirements.
• Plan business communications.
• Execute upgrade tools to gather information about the current environment.
• Test the upgrade.
• Perform environment cleanup.
• Build hardware.
• Perform pre-upgrade backups.
• Establish a project schedule.
• Test rollback and restore options.
• Perform post-upgrade activities.
• Establish launch and ongoing support management.

Now how to choose the upgrade path for your Farm

Migration and Upgrade Resource Center for Microsoft Office SharePoint Server 2007 contains the needed resources for IT pros to help migrate to Microsoft Office SharePoint Server 2007 from Microsoft Office SharePoint Portal Server 2003, Microsoft Windows SharePoint Services 3.0

For more information please follow the link http://technet.microsoft.com/en-us/office/sharepointserver/bb421259

The following table lists and compares different upgrade approaches

Approach	Description	Pros	Cons	Best for
In-place upgrade	Upgrades the content and configuration data in-place, at one time.	Easiest approach. Sites retain original URLs. Updates existing databases and servers using existing hardware.	Environment is offline while it runs. No ability to revert to original site.	Single server or small server farm.
Gradual upgrade	Installs the new version side-by-side with the previous version. The server administrator determines which site collections to upgrade and when to upgrade them.	Enables a more granular approach: You can upgrade at the site collection level. Reduces time any single user is affected. Sites retain original URLs. Can revert to original site. Uses existing hardware.	More complex and resource-intensive. Must redirect URLs during upgrade process, which causes issues for some client applications such as Microsoft Office. Requires extra storage in Microsoft SQL Server. Microsoft Windows SharePoint Services 2.0 scalable hosting mode is not supported.	Medium or large server farms (without shared services) with many sites for which you must limit downtime. If your environment has many customizations and you encounter problems, you can always revert to the original site.
Gradual upgrade for shared services	The same as gradual upgrade but with separate upgrade passes to upgrade parent and child portal sites.	Same as gradual upgrade, but allows you to upgrade parent and child portal sites individually.	Same as gradual upgrade, plus: Two search crawls are active at the same time for the Microsoft Office SharePoint Portal Server 2003 and Office SharePoint Server 2007 environments.	Server farm of any size with shared services.
(Advanced) Database migration	Requires the server administrator to install the new version on a separate farm or separate hardware, and then manually migrate the databases into the new environment.	Enables moving to new farm or new hardware. SharePoint Portal Server 2003 environment is available and is untouched by upgrade.	Complex process that requires many manual steps and a higher risk of error. Requires additional manual steps to retain original URLs for sites. Search scopes must be re-created and search settings must be reapplied. Requires new server farm, and twice the amount of SQL Server storage space.	Those who are moving to new hardware or a new architecture. Those who need to maximize upgrade throughput. This approach is required for Windows SharePoint Services 2.0 environments that are using scalable hosting mode or Active Directory directory service account creation mode. Moving from Windows SharePoint Services 2.0 to Microsoft Office SharePoint Server 2007.

Then for your next step of upgrade There are two basic approaches to upgrade: in-place and database attach. In addition, there are various techniques you can use to combine aspects of these basic approaches to mitigate downtime or potentially improve performance.

The following table compares the in-place and database attach approaches.

Approach	Description	Pros	Cons
In-place upgrade	You can install SharePoint Server 2010 on the same hardware. You can also upgrade the content and settings in the server farm as part of a single process.	Farm-wide settings are preserved and upgraded. Customizations are available in the environment after the upgrade, although manual steps may be required to upgrade or rework them.	Servers and farms are offline while the upgrade is in progress. The upgrade proceeds continuously. Consequently, you must allocate enough time for all content to be upgraded in sequence.
Database attach upgrade	You can upgrade the content for the environment on a separate farm. The result is that you do not upgrade any of the services or farm settings. You can upgrade the databases in any order and upgrade several databases at the same time. While each database is being upgraded, the content in that database is not available to users.	You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade. You can use a database attach upgrade to combine multiple farms into one farm.	The server and farm settings are not upgraded. You must manually transfer settings that you want to preserve from the old farm to the new farm. Any customizations must also be transferred to the new farm manually. Any missing customizations may cause unintended losses of functionality or user experience issues. Copying databases over a network takes time and bandwidth. You must plan for that. You need direct access to the database servers.