The information here is based on a beta version. All details are subject to change.
With the release of SharePoint 2010 just around the corner, it's a good time to consider the upgrade and migration options, and take action to prepare your environment.As happens in most upgrade or migration scenarios, there are hundreds if not thousands of details to think about that increase complexity, ranging from network connectivity to third-party applications to business continuity. There are also various frameworks and scenarios you can use for moving to a new version, such as prepare-test-implement-validate, and deciding whether to upgrade in place or migrate.
The good news is that you still have time to plan your migration strategy, and prepare now to mitigate possible issues when you do move to SharePoint 2010.
This article covers some of the actions you can take now to prepare for SharePoint 2010 that will have the greatest impact. If you want to dig deeper, you can look at existing documentation for additional guidance or to help you develop a more comprehensive plan.
For example, Joel Oleson has released presentations and a white paper about upgrade preparedness on his blog at sharepointjoel.com, and Microsoft has published preliminary guidance.
The first action you can take to prepare your environment is to audit the existing software and hardware configuration to see if it is adequate for SharePoint 2010, and update your environment if it does not meet requirements. The most significant overall requirement is 64-bit hardware and SharePoint 2007 with at least the SP2 update.
You can do more, of course; consider updating your environment in accordance with the following best practices for front-end and application servers, back-end servers and clients.
For front-end servers, SharePoint 2010 requires 64-bit Windows Server 2008 or Windows Server 2008 R2, which uses the new Windows 7-based user interface. Many installations as of this writing run without major issues on Windows Server 2003, and if you're in that position, a large part of preparing for the transition to SharePoint 2010 entails upgrading the OS.
If you run Windows Server 2003 on 64-bit hardware already, you can reuse the servers and do an in-place upgrade for front-end, application and back-end servers. You can also add new servers to the farm and migrate the Central Administration Web site, front-end roles and application roles. If you plan to move to Windows Server 2008, you should consider the following best practices:
For back-end servers, SharePoint 2010 requires 64-bit SQL Server 2005 or later. SQL Express is supported, but moving to SharePoint 2010 provides an opportunity to re-examine the back-end infrastructure and optimize it.
The Standard and Enterprise editions of SQL Server provide management tools and high-availability features such as clustering.
In terms of client browser support, SharePoint 2010 discontinues support for Internet Explorer 6 and only supports standards-based browsers, such as IE7 or later. SharePoint 2010 also supports Firefox 3.x and Safari.
The next step after ensuring that front-end servers run Windows Server 2008 on 64-bit hardware, back-end servers run SQL Server 2005 or later, and that clients are using a standards-based browser, is to run stsadm -o preupgradecheck. PreUpgradeCheck is included with SP2 for SharePoint 2007 and uses rule files -- OssPreUpgradeCheck.xml for Microsoft Office SharePoint Server (MOSS) and WssPreUpgradeCheck.xml for Windows SharePoint Services (WSS) -- to check for configuration details and create a report.
Of course, before you can run PreUpgradeCheck, you must install SP2. The installation wizard is relatively straightforward, but there are several things to keep in mind. First, provide notice to users of planned downtime because you should stop the front-end IIS services on each server and back up and detach the content databases before proceeding. It's a good idea to back up front-end and application server files, too, especially if you have customizations.
Second, install the WSS SP2, cancel the configuration wizard, and then install MOSS SP2.
Finally, after the update processes complete, check for errors in upgrade.log, located in the version 12 hive logs directory. Look for instances of fail or error. If installation completes successfully, upgrade.log should include the strings shown in Figure 1. Click here for more information about updates..
After running PreUpgradeCheck, the detailed report it generates contains useful information about the details of your environment and includes specifics about farm topology, server configuration, Alternate Access Mappings (AAMs), databases, features, site definitions and so on. The immediate output in the command prompt also indicates if any categories do not pass; that is, they require you to make changes before moving to SharePoint 2010. The detailed .HTM file is helpful for finding out more about what you need to do to resolve the underlying condition. Look for the following details in the file that may need to be addressed:
Finished upgrading SPFarm Name=<ConfigDBName>
In-place upgrade session finishes. Root object = SPFarm=<configDBName> , recursive = True , 0 errors and 0 warnings encountered.
Figure 1: Succesful SP2 instalation entries from upgrade.log
It is relatively straightforward to resolve configuration orphans; detach the content DB and reattach it (stsadm -o deletecontentdb and stsadm -o addcontentdb).
Don't forget to run stsadm -o preparetomove beforehand in MOSS 2007 environments.
To resolve a content orphan where the site is mapped to the incorrect, empty content DB, back up and delete the incorrect content DB and attach the appropriate one.
To resolve a content orphan where orphaned content DBs exist, back up your production site, delete it, attach the orphaned content DB to make it accessible, and delete it. Then you can restore the backed-up site.
Check out KB articles 918742, 918744 and the STSADM commands -o databaserepair, -o deletecorruption, -o repairorphans and -deleteconfigurationobject -id <objectId> for more information.
Keep in mind that configuration details may differ among front-end servers, so run PreUpgradeCheck on each server and check for any configuration differences.
By running stsadm -o preupgradecheck -localonly, you can check an individual server, then compare the resulting .HTM reports using a tool such as WinDiff.
Find here more information about PreUpgradeCheck.
Customizations are one of the more time-intensive issues to address before moving to SharePoint 2010 because even in the simpler scenarios of minor site customizations, transitioning entails recording specifics, migrating, and then verifying and fixing issues.
For larger customizations, or for those using third-party tools, the increased complexity can turn migration of customizations into a full software development project.
From the IT pro perspective, standardizing where possible, documenting customizations, and cleaning up data and configuration details all help to mitigate issues for developers.
Figure 2: Customization Migration Best Practices
I covered some cleanup possibilities earlier. Checking for orphans, resolving feature and Web Part dependencies, optimizing lists, setting a hard database limit of 100GB and performing other optimizations will make the move easier.
Deleting unused sites, increasing quotas and starting a user-driven site cleanup initiative are additional opportunities to trim the migration size. You should also standardize solutions and features wherever possible, and consider if the best choice is to delete, reinstall or re-create customizations. Figure 2 shows some general best practices and options for customizations.
Because SharePoint 2010 is not released yet, there are limits to how much preparation and testing you can do for customizations.
The best approach for most environments is to plan to not upgrade in place, but to create a new farm, migrate content databases and then apply customizations.
With this approach, you could do a gradual upgrade and decommission previous servers as you migrate sites.
The convenience of virtualization and related management tools has made it possible to validate and verify migration plans before updating the production environment.
Perhaps the most obvious possibility with virtualization is to re-create the production environment on a much smaller scale as virtual computers, and validate the migration or upgrade strategy before implementing it in the production environment.
Virtualization provides features such as taking a snapshot of the OS and restoring it on demand. This makes it possible to document the full migration steps in detail, so that when you update the production environment, it becomes a matter of following the steps
I've covered readiness from a practical point of view and offered suggestions for actions you can take to prepare your environment for SharePoint 2010.
If you follow the key suggestions of moving to 64-bit, running the PreUpgradeCheck tool, resolving the discovered issues, and validating your plan in a virtual environment, you'll be in good shape for SharePoint 2010.
Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corp., a company that specializes in managed documentation and localization services.