If you’ve been managing a website previously and would like to move it to a SharePoint Foundation 2010 environment, you have two choices for bringing over the content: upgrade and migration. Upgrade and migration are often confused because they both cover moving content into SharePoint; however, there are distinct differences between the two. Understanding the choices available to you will help make the decision easier when you do choose to plan and execute a move.
Note
For more details, download the Microsoft TechNet Guide “Upgrading to Microsoft SharePoint Foundation 2010,” which is tailored to administrators and IT professionals who are upgrading to SharePoint Foundation 2010. You can download the guide at http://go.microsoft.com/FWLink/?Linkid=196159.
Microsoft supports upgrades from Windows SharePoint Services Version 3 to SharePoint Foundation 2010.
If your current site or sites are running on Windows SharePoint Services Version 3 with at least Service Pack 2 installed, you and your IT staff might have two approaches to choose from when directly upgrading to SharePoint Foundation: in-place upgrade and content database upgrade.
If you are directly responsible for all of the sites in one Windows SharePoint Services farm, you might work directly with IT to execute an in-place upgrade. The entire farm will be upgraded at one time with this approach—for better or worse. A coordinated effort is necessary if the farm to be upgraded supports multiple groups within an organization.
An in-place upgrade is a lot like upgrading your personal computer’s operating system from one major version to another. In some cases, it can seem like the simplest option, but (as with a personal computer upgrade) you are using the same computer before, during, and after the upgrade.
There are good reasons to think twice before taking what might seem like the easy upgrade path. If the upgrade fails, the entire SharePoint environment will be unavailable until either, a) the failure is corrected, or b) the environment is restored to its previous state from backups.
Before using this approach there are some important steps you and your IT staff must take to safeguard your content. These steps are outlined in the Caution elements that follow.
Caution
If something goes wrong during the upgrade, you risk being left without a working system in Windows SharePoint Services or SharePoint Foundation. You must have a tested backup and restore process before you attempt an in-place upgrade. Ask the IT staff to show you the restored SharePoint sites from a test restore before executing an in-place upgrade on your production data. If the restored sites match your existing sites to your satisfaction, you can be sure that an in-place upgrade can be repeated if it fails. Regardless of your upgrade approach, verifying the completeness of your restore process is a great way to ensure that you have working backups of your important information contained in your SharePoint sites.
Tip
INSIDE OUT Old hardware and software can negate the simplicity of the in-place upgrade approach
Your existing SharePoint farm must meet hardware and software requirements that were not common in 2007 when many systems were built with the previous version of SharePoint. The requirements might make it impossible to run an in-place upgrade on many existing Windows SharePoint Services installations without upgrading both hardware and dependent software such as the Windows Server Operating System and SQL Server.
If this is the case for your environment, you might choose to use the second approach (described in the next subsection). When upgrading hardware or other software in combination with a SharePoint upgrade, the complexity has already increased and a content database upgrade might help decrease complexity in some cases.
Caution
An in-place upgrade can take a long time to run, and the content in the farm will be unavailable to users while it is running. For the most accurate time estimate, ask your IT staff to test the in-place upgrade process on similar hardware prior to executing an in-place upgrade on your production data; this upgrade test can be combined with the restore test previously mentioned. As part of the upgrade preparation, your IT staff has tested the restore to a new farm. A test of the upgrade on the second farm should produce similar upgrade result and timing if using similar hardware to the production farm.
If you’ve read the section on SharePoint structure, you’ve seen one explanation of the connection between the content database and SharePoint sites:
All of the information you see when you use your SharePoint site is held in a content database.
Each content database can hold more than one collection of sites.
Each Site Collection is stored in one, and only one, content database.
This second approach is called a content database upgrade because each content database can be upgraded individually by using this approach.
When IT executes a direct upgrade from Windows SharePoint Services Version 3, you can choose not to upgrade every content database in a farm at the same time. If you have more than one content database, this offers some flexibility for a phased upgrade.
For example, you might choose to move the database containing your most important sites first. Or, you might choose a less important database as a first upgrade to refine your process and become more familiar with the steps involved.
A benefit of the content database upgrade approach is the option to leave the existing content available for viewing only while the upgrade is being performed. Because the content database can be copied to the new server, the original copy is still available for read-only use while the new copy is being converted to the SharePoint Foundation format. This is especially helpful for large content databases that require a long time to upgrade.
This approach requires that the customizations applied to your Windows SharePoint Services installation are well documented and ready to move to the new environment. It also requires a strong understanding of the configuration settings on the farm and web application level. In many organizations, this might not be a problem, because configuration and customization documentation are also both required for disaster recovery.
The content database upgrade occurs on a new SharePoint Foundation 2010 farm. This means additional hardware is required besides the hardware currently running Windows SharePoint Services farm. Besides being a requirement, it is also a benefit to have two environments available because the upgrade can be tested and repeated on the new hardware before committing to the final move from the old hardware.
Visual Upgrade is a new feature of the SharePoint 2010 products that can keep your upgraded site looking a lot like your old site.
While the back-end and some menus will be changed after upgrade, the default state for all upgraded sites is a look and feel that is very close to SharePoint 2007. The reason for this old look in your new upgrade is to allow time to update your old sites to the new visual features of SharePoint 2010.
SharePoint 2010 makes some important and wide-ranging changes to the visual layout of pages on a site. It will take some work to create new master pages, page layouts, and style sheets for your old site. You can test your upgraded sites in the 2010 style with the Visual Upgrade menu options in your site settings.
While you are testing the new “look,” only you will be able to see it. Once you are happy with the new look of your upgraded site, you can commit the change for everyone to see.
Tip
INSIDE OUT Be prepared to execute a Visual Upgrade plan before your SharePoint 2010 Upgrade on the back-end
While Visual Upgrade is a great feature that gives you some time to get up to speed with some of the new layout and style changes in SharePoint Foundation 2010, it is only meant to be a temporary fix. You will find that some features are not supported until you’ve used the Visual Upgrade menu options to move to the new style. Being prepared to move out of the SharePoint 2007 mode as soon as possible after the back-end upgrade of your systems will give you the full advantage of your upgrade.
If you have content on websites that are not running Windows SharePoint Services Version 3, you have two options for moving that content to SharePoint Foundation 2010. You can migrate the content manually to a SharePoint Foundation 2010 farm or you can do it with a third-party tool.
Note
For the purposes of this chapter, an upgrade is moving from Windows SharePoint Services Version 3 to SharePoint Foundation 2010. Any other move is considered a migration. In either case, customizations, including installed third-party add-ons and branding, must be considered separately from the content. The migration steps that follow discuss moving content.
Note
You can find more help for branding and customizing SharePoint Foundation in Chapter 14, which covers branding with respect to master pages and cascading style sheets. Chapters Chapter 15 and Chapter 16, cover authoring customizations.
For sites that have a small amount of content, manual migration can be a good option. You might choose to replicate the previous sites as closely as possible through the creation of lists and libraries first and adding content second. Or, you can take the chance to redesign the information architecture of your site. If you take the time to review the site to be upgraded, you might find that you only need to move over a small amount of information that is still relevant and useful to you and your users now.
Manual migration is often a team effort. You might want to involve site designers to work on a new look that matches or builds on the previous look. You want to plan for some testing, even if it’s just to get a second set of eyes on the work you do yourself. Breaking up the repetitive parts like copying and pasting documents or text from old to new can help make this go faster.
Tip
INSIDE OUT Manual migration might sound hard, but it can be a great option
It could be easy to dismiss manual migration as an unacceptable option for moving your content. After all, it can be hard enough to motivate yourself to do repetitive manual work for any period of time—motivating a team can be harder, still.
If your team is excited about the new capabilities of the platform, as many are, this one time division of labor can pay off with big dividends. Often, the time saved in the future with modern tools provided by SharePoint 2010 can be a great reward when you’ve become frustrated with the technology you’ve been using for a long time to update your old site. Keep in mind that even with automated migration tools, you will want to do extensive testing to ensure that your content has moved over correctly. When you move over content manually, you can be confident that everything you’ve moved over went to the right place.
There are more than half a dozen migration tools specifically built and sold by third-party software companies to move content into new SharePoint 2010 sites. The basic premise of tool-assisted migration is no different than that of the manual migration. You can still choose to try to replicate the site that you are migrating from or you can take the opportunity to re-assess your site and build into a new design that fits SharePoint 2010 better.
The big difference is that these tools help do some of the repetitive manual work that is involved in migrating to SharePoint Foundation. In fact, you might find yourself appreciating one of these tools so much that you keep it around to help you reorganize your content in SharePoint Foundation long after the initial migration is complete.
There are two kinds of third-party migration tools available. The simplest kind treats the source website as a collection of HTML webpages. Using this kind of tool, you move each page over, one by one, into a document library in SharePoint Foundation. That method really only works if all you have is content in pages, as opposed to items in lists or documents in libraries.
On the other hand, many of the third-party tools have specific features that target particular sources of information from which to migrate. You can find tools that help you pull data from older versions of SharePoint, competing products like Lotus Notes, and other technologies used to share information like Networked File Shares and Exchange Public Folders.
Each tool available works a little differently than the other, so it’s best to go to the vendor for information on how to use the tool you choose. They are all happy to provide product demonstrations and many provide trial versions so that you can test them out on your actual content.
Note
The websites www.EndUserSharePoint.com and www.SharePointReviews.com both have great collections of information on third-party migration tools. Look in both the Migration and Content Organization categories.