There is no single approach to SharePoint migration. The process involves design, engineering and development. Therefore this document is a guide, providing high-level documents that can be tailored for use in the Microsoft Office SharePoint Server (MOSS) 2007 to Microsoft SharePoint Server 2010 migration process.
Upgrade Methods and Downtime Mitigation
SharePoint Server 2010 requires 64-bit hardware and software regardless of the type of upgrade. If the hardware and software involved are not 64-bit, a plan will need to be prepared to upgrade those first.
Microsoft sets forth four types of upgrade from MOSS to SharePoint Server 2010:
- In-Place – this method retains the farm’s configuration and settings, upgrades the entire farm, is somewhat riskier than other methods, and requires complete farm downtime during the migration
- Database Attach – this method does not retain the farm’s configuration and settings, is less risky, and does not require entire farm downtime during the conversion
- Hybrid 1 – this method involves an in-place upgrade with database attach; this method makes the farm available faster but not all content
- Hybrid 2 – this method involves a database attach with read-only databases; the difference between this and the Database Attach is that while the upgrade is in process, the MOSS farm can still be available in read-only mode
Note: Posters of the Upgrade Methods and other Design Principles can be found on Technet at the following URL: http://technet.microsoft.com/en-us/library/cc263199.aspx inVisio, PDF, and XPS formats.
The tables below are the topology and product requirements for Upgrade to SharePoint 2010 versions.
SharePoint Portal Server 2003/WSS 2.0 cannot be upgraded directly to SharePoint 2010 versions. Attach the SharePoint Portal Server 2003/WSS 2.0 databases to the MOSS 2007 farm in order to upgrade them to a version supported for upgrade to 2010 versions.
|Starting topology (Office SharePoint Server 2007)||Supported ending topology (SharePoint Server 2010)||Unsupported ending topology (SharePoint Server 2010)|
|Stand-alone server with SQL Server 2005 Express Edition||Stand-alone server with Microsoft SQL Server 2008 Express||Any farm|
|Single server with SQL Server||Single server with SQL Server||Stand-alone server with Microsoft SQL Server 2008 Express|
|Any size farm||Any size farm||Stand-alone server with Microsoft SQL Server 2008 Express|
|Starting product||Supported ending products||Unsupported ending product|
|Windows SharePoint Services 3.0 with SP2||Microsoft SharePoint Foundation 2010
SharePoint Server 2010 (by using database attach upgrade only)SharePoint Server 2010 (by using in-place upgrade)SharePoint Foundation 2010SharePoint Server 2010 Microsoft Search Server 2008SharePoint Server 2010 or Microsoft Search Server 2010SharePoint Foundation 2010Microsoft Office Forms Server 2007SharePoint Server 2010SharePoint Foundation 2010Microsoft Office PerformancePoint Server 2007SharePoint Server 2010 Microsoft Office Project Server 2007 with Windows SharePoint Services 3.0 with SP2 or Office SharePoint Server 2007 with SP2SharePoint Server 2010, Enterprise Edition plus Microsoft Project 2010SharePoint Foundation 2010 plus Project 2010
Hardware and Software Upgrades
- The MOSS 2007 environment must be upgraded to Service Pack 2 prior to upgrading to SharePoint Server 2010
- All hardware must be 64-bit
- All software versions must be 64-bit including: Windows Server 2008 (R2) x64, SQL Server 2005 x64 CU3 SP3, SQL Server 2008 (R2) x64
Full requirements can be found here.
Document the Current MOSS 2007 Environment
Use the attached spreadsheet, if needed, or assessment document to gather inventory information from the existing MOSS 2007 installation. A high-level list of information required is as follows:
- SSP Settings
- Web Applications
- Site Collections
- Large Lists
- Custom Views
- Search Settings
Complete information will be gathered from the PreUpgradeCheck output. It may be easier to use just this output, the files above, or some combination of the two. Out of the box, the command is:
stsadm -o preupgradecheck
-[rulefiles <rule file name>]
This command can be used with a -rulesfile parameter (See Resources section for rules file parameters) and a -local parameter. The local parameter is used for a single server as opposed to the entire farm. Without additional parameters the preupgradecheck utility command will return all rules for all servers in the farm.
The preupgradecheck utility command output provides the following files:
These two files are output to the 12 Hive\Logs folder. The log file is text and the xml file uses an xslt file to convert to html for output to the browser.
Environment Health Cleanup
It’s not only important to ensure that the existing environment components can be successfully upgraded, but it’s also important to ensure the MOSS 2007 environment is performing optimally. Also, not all of the existing MOSS 2007 environment data will need to be upgraded if there are duplicated data, unneeded sites, etc. Cleanup all of the following in the existing MOSS 2007 environment:
- Content that will not be upgraded
- Orphaned sites or data
- Large lists and large ACLs
- Remove extraneous document versions
- Remove any unused templates, features and Web Parts
There are many potential customizations that can exist in any given farm. Using the following table determine which customizations exist in the environment.
After the customizations have been inventoried, decide which ones are relevant and useful and need to be migrated and which can be forgone in favor of new out of the box features.
The following table lists some common customizations and recommendations for remediating them.
|Site templates (.stp files)||Site templates (.stp files) are a deprecated feature in SharePoint Server 2010. New site templates in SharePoint Server 2010 are saved as .wsp files (solution packages).
A site that was provisioned by using a site template will be upgraded, but you will be unable to create new sites that are based on that template. If you want to be able to create new sites, you can create and deploy a solution package instead. Site definitionMigrate sites to a supported, predefined site definition, then apply custom features by using solution deployment.
You can also continue to use a custom site definition. You do not have to create a new site definition that is based on SharePoint Server 2010.
If a Web Part is located on a page but not in a Web Part Zone (so that it is, basically, HTML code embedded directly in a page), it will not work if you revert the page to the default template.ServicesTest to determine whether any actions are required. Redesign or adjust code, as needed.Authentication providersTest to determine whether any actions are required. Redeploy the provider on a test farm and ensure that it works correctly with claims authentication.
The following customizations are not supported and must be replaced using a supported method before upgrading. Otherwise, you might experience upgrade issues that cannot be fixed:
- SharePoint bits (binaries), features, or site definitions that have been modified.
In tandem with the other preparation tasks, this is an ideal time to ensure that everything is in place for the new environment (this assumes database attach or hybrid-2 upgrade).
- Is all of the equipment in place for all environments?
- Have OS’s been installed?
- Are all the servers named?
- Do all of the servers have IP addresses and DNS entries?
- How are URLs being handled – new or reused?
- Have external domains been ordered, if required?
- Are certificates in place for SSL sites?
- How is load balancing being implemented?
- Are new versions of 3rd party solutions required?
- Are service accounts in place?
- Is a plan in place to support the Help Desk Call Center and for call logging regarding the upgrade?
Install New Environments
At this point all of the information required has been gathered and a rough plan has been created for the migration process. It is not likely that the upgrade will be of the in-place variety, rather a database attach or hybrid-2, where the MOSS environment is still available in read-only mode.
The first step is to install the new SharePoint Server 2010 environment. In most cases there will be multiple environments to install: good guidance will be to install the development environment(s) or ensure that the developers have their own development installations. In this way, Testing can take place while installation and configuration of the Test/QA and Production environments are being built.
Test the Migration
In a development or test/qa environment, preferably a development environment, ensure that the web application to be tested has been created and configured; the empty database can be removed in Central Administration using Manage Content Databases. Also ensure that as many solutions and features as possible are installed. Any errors regarding solutions and features not installed can be ignored for now, especially if new versions are not in yet, or customizations are not ready for upgrade yet.
The following list steps through the process at a high level:
- Restore a backed up copy of the Content Database to be tested to the new database server
- On the console of the development server open the SharePoint PowerShell window
Use the following command to output to an html file (for readability):
test-spcontentdatabase -name WSS_Content –webapplication http://sitename | ConvertTo-Html | Out-file c:\directoryname\filename.htm
Upgrade Blocking is a key column because it lists anything that will cause the upgrade to fail.
Once upgrade blocks, if any, are remediated the database can be upgraded using the following command:
mount-spcontentdatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename
- The output from the Mount command will merely be a percentage counter from 0-100%
- Monitor Progress in SharePoint Server 2010 using Central Administration, Upgrade and Migration, Check Upgrade Status
- Document the process of upgrade and include any watch-outs
- Document the back-out process for recovery situations
After testing each of the content databases as many times as is necessary, an expectation can be set for the duration of the upgrade as a whole. After everyone involved in the process has signed off on the readiness of each area, then a plan can be made to carry out the actual upgrade.
Ascertain the following:
- Is the SharePoint environment completely configured to mirror the existing MOSS environment (services, web applications, etc.)?
- Are all solutions, features, third-party applications, and custom applications in place and tested?
- Are the Test/QA and Production environments configured exactly alike?
- Who will be available during upgrade for support (developers, designers, engineers, management)?
Have final backups of the MOSS environment been scheduled?
Once everything is in place, the upgrade can be performed. In a sense it’s already been done in the testing phase and unexpected errors will be fewer because of the testing effort. Here are some guidelines for the upgrade:
- Verify backups (if unsure of quality, backup databases after they are set to read-only
- Set MOSS content databases to read-only (if required)
- Copy databases or backups to new database server
- Attach or restore databases to new SharePoint database instance
- Run test-spcontentdatabase
- Run mount-spcontentdatabase (use multiple SharePoint Management Shell Windows on multiple application servers where available) beginning with the databases that are most critical or important to the organization
- Begin staggered testing
- Begin issue logging
- Begin monitoring using Event Viewer and ULS Logs
Issues will need to be resolved as they come up or worked around until resolution. A SharePoint list on an intranet IT site is most likely to be used to track these issues. Coordinate with all persons involved to ensure that complete testing and post upgrade remediation has been completed. By now, end users are involved and a local call center will probably need support and will need to provide a report of logged calls pertaining to the upgrade.
If MOSS databases are to be moved to the new environment, perform the following:
- Stop SQL Services on the MOSS Database server
- The services that run the SQL Server Installation will need to be stopped before the databases can be moved
- If the Instance is NOT the default instance stop only the services relating to that instance
Locate the .mdf and .ldf files on the MOSS Database server
- It’s unlikely that the files will be located on drive C: (a good thing) so ask the DBA if unsure where the files are
- It’s unlikely that the files will be located on drive C: (a good thing) so ask the DBA if unsure where the files are
- Copy or Move the .mdf and .ldf files to the new SharePoint Server 2010 Database Server
- If MOSS database backups are to be used, restore the backup files to the new SharePoint Server 2010 Database Instance
SSP Shared Services and Service Applications
Ensure that all the new Service Applications and proxies have been created
User profile and taxonomy data from the SSP database is upgraded when the SSP database is attached, but the database is not copied and renamed. You can copy the taxonomy data into a Taxonomy database for use by the Managed Metadata service after upgrade is complete by using the Move-SPProfileManagedMetadataProperty PowerShell utility.
If Administrator-approved InfoPath forms and .udcx files have been deployed in Central Administration, these will need to be exported and then imported into the new environment using the following STSADM commands:
Stsadm.exe -o exportipfsadminobjects –filename <path to export CAB>
Then, using Powershell on the new Central Administration server:
MOSS 2007 BDC connections will not be updated during the upgrade so engineers or developers will need to make the necessary changes before they can be used in the new environment. Because of the effort involved, ensure that upgrading is truly a better method than recreating.
- Export application definitions that the solution requires from the Office SharePoint Server 2007 Business Data Catalog.
- After upgrading, update the solution to use the object model and features of the Microsoft Business Connectivity Services. This includes updating the application definitions to become BDC models, which are compatible with Microsoft Business Connectivity Services.
- Import the updated BDC models into the Business Connectivity Service service application.
Migrate 3rd Party Applications
Nintex Workflow 2007
The Nintex Workflow upgrade is simple but the steps must be followed exactly for a successful upgrade. The process includes:
- Moving the database to the new server
- Editing fields in the Database Table within the Nintex Workflow database
- Verifying the database setup in the Nintex Workflow Configuration in Central Administration
Quest Web Parts
Verify that upgrading will not remove web parts that are currently in use.
If a newer version of Quest Web Parts does not contain the same web parts, make arrangements for those with an engineer or developer.
When upgrading Quest Web parts, version to version, uninstall the existing version and install the new version.
Afterward run the configuration manager and configure for each web application that requires the web parts.
Troubleshooting the Upgrade
As a result of the testing prior to the upgrade most serious errors and upgrade blocks will have already been remediated. But some issues may still remain. They can’t all be covered here because of environmental differences between each upgrade, but some are listed here.
- Database is up to date, but some sites are not completely upgraded
If necessary, manually run the following command to restart or complete the upgrade process
Upgrade-SPContentDatabase [[-ForceDeleteLock] <SwitchParameter>] -Name <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-NoB2BSiteUpgrade <SwitchParameter>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-SkipIntegrityChecks <SwitchParameter>] [-UseSnapshot <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Post-Upgrade Testing and Verification
Post-Upgrade testing can begin for basic SharePoint Server 2010 operation at any time during the migration, beginning with monitoring operations, and post-upgrade site testing as soon as migration has completed for one or more databases.
- Verify Administrator and Delegated Permissions for all Service Applications
- Upgrade profile properties to taxonomy data and update the photo store for Profile Services
- Create the Excel Services unattended service account
- Create and configure the Secure Store service application and migrate SSO data to the Secure Store service
- Upgrade solutions that depend on the Business Data Catalog
- Update links that are used in any upgraded InfoPath form templates
- Have users migrate private My Links to private tags (Optional)
- Setup Outgoing E-mail – this will be used for alerts and workflow.
- Configure search settings
- Start User Profile Synchronization Service
- Add Trusted File Location for Excel Services
- Add AAM entries (if required)
- Modify BlobCache location in web.config file
- Fix People-Picker (only if multiple forests/domains are used)
- Configure Quota Templates
- Add warmup script to task scheduler
- Set object cache user account