Document the environment, along with server customizations, plan the upgrade approach, and upgrade any necessary hardware and software.

• Document everything in the environment
• Plan an upgrade strategy
• Manage any server customizations

A great way that Microsoft has provided, to document the current environment and check for prerequisites/ compatibility issues, is the stsadm command line command called preupgrade check.  This command first appeared in Sharepoint 2007 SP2, and is utilized in order to discover the upgradability of a SharePoint environment.  This is a read only tool, and will not hurt the server or write anything to it.

How to run the preupgrade check

On the server, run the the following stsadm command: stsadm -o preupgradecheck

This tool will identify and report on the following information about the SharePoint environment:

• Farm components, number of servers and total amount of content (size)
• Search configuration info
• Alternate access mappings
• Features installed
• List of Site definitions
• Language packs

It will also report if any of the following issues are discovered

• Large lists
• Data orphans
• CAML views and CAML content types
• Modified content databases with improper schemas - unsupported
• Missing upgrade dependencies
• Unfinished gradual upgrade from SharePoint 2003 to 2007.

Here is a Microsoft website with a more detailed list.
After this command is run, the report will come out as a nicely formatted HTM file that can be viewed in the browser.

In summary, the environment needs to be documented, documented before delving into an upgrade.  Here are some basic questions to know the answer to:  How many site collections do you have? How many subsites? What’s the average size of a document? How many features are installed on the farm?

If SharePoint 2010 is already running in the environment, databases versions can be checked using a Windows PowerShell cmdlet, Test-SPContentDatabase.  Specify a database and web application, and it will let you know about data orphans, missing site definitions, missing features, and missing assemblies.  This cmdlet is read-only, and does not write any information to your system.  This command is meant to be a compliment to the preupgradecheck.

Upgrade Strategy

There are some things about the SharePoint environment to consider when thinking about the upgrade strategy:

• Amount of data - affects the upgrade performance.
• Server customizations - affects the time needed for the upgrade
• Dependent applications
• Downtime
• URL Changes

Amout of data and Complexity 

Not only is the upgrade performance directly proportional to the amount of data to be upgraded, the complexity of the upgrade is proportional to to the amount of server customizations there are in the environment. 

If an upgrade from SQL 2005 to SQL 2008 is part of your upgrade plan, it is recommended that this be done separately.  In other words, it’s a bad idea to do the SQL upgrade and then the SharePoint upgrade… all in one server outage weekend.  This way, if there are issues with the SQL upgrade, they will be simpler to isolate and troubleshoot, since they won’t be mixed in with any possible issues with the SharePoint upgrade.  Give SQL a little time, and make sure it’s stabilized first.

Server Customizations / Dependent Applications

First of all, a full audit of the SharePoint environment will be necessary, and the preupgrade check command will have been a good start to this process.  Some fundamental information about the current deployment will be needed, such as the number of farms and their topology, the current backup and disaster recovery strategy, how much data is there, and how many users there are.  Also, regarding the physical environment, it will be necessary to know if the current hardware is sufficient, what any new hardware plans are, and what the current network bandwidth and latency is.  Is this bandwidth going to be sufficient to support a double-crawl?

It is a good idea at this point to think about your future server topology (if any) ahead of time, instead of deciding to change it during the upgrade process.  Also, when documenting the network, make note of not only the bandwidth between servers, but the actual end user’s bandwidth experience.

Consider all of the third party applications, custom development, and custom web parts in the environment.  Some of these applications may even have dependencies on the old version, and may not be compatible wih SharePoint 2010.        

Downtime

When trying to decide whether to go with an in-place upgrade or the DB attach method, downtime is a big factor.  The DB attach method requires less downtime, and can be run simultaneously on multiple content databases.  It will need to be determined the duration of downtime that is acceptable to the business. 

Even with the DB attach or hybrid upgrade method, there is still a window of limited availability that will need to be planned for.  The following general steps can be taken when using the one of the two aforementioned methods:

1.     Backup the SharePoint 2007 database

2.     Set the old farm environment to read only, so that users may not modify any content during this critical phase.

3.     Perform the DB attach and then verify the installation

4.     Modify WINS/DNS in the environment.

URL Changes

Most businesses are tied to their current SharePoint URL, and are not okay with simply changing it to a new one when it’s time to put SharePoint 2010 in place.  In the planning phase, advise the business owners on all of the things that “won’t work” anymore, such as URL locations saved in users’ Favorites in their browsers.  Note that even the Office client won’t know to follow documents to a new URL location. 

·          In-place upgrade method – no URL change

·          DB attach or Hybrid method – URL can either remain the same, or can be changed to a new one if necessary.