Sharepoint 2013 : Upgrading to Sharepoint 2013 - Upgrade Considerations (part 1) - What You Can Upgrade

Each new version of SharePoint presents a new upgrade experience. Some parts are better, some parts are worse. Upgrading with SharePoint 2013 is the same way.

What You Can Upgrade

There are many pieces of SharePoint 2010 you may need to upgrade. It’s not all about getting those PowerPoint presentations into your new farm. Here are some different things you can upgrade.

Content

Like the versions of SharePoint that preceded it, it’s tougher to stump SharePoint 2013 when you’re upgrading content. It handles customizations better; and in situations where it can’t figure out what to do, it doesn’t simply fail, it gives you a meaningful error message, and then moves on gracefully. SharePoint 2013 is also more lenient about which version of SharePoint 2010 you upgrade from. In fact, it will upgrade from any of them. When upgrading from SharePoint 2007 to SharePoint 2010, the SharePoint 2007 farm had to be at least at Service Pack 2 (SP2). This caused some real problems for SharePoint 2007 farms that were unstable. If they weren’t already at SP2, upgrading the farm to that, just to immediately upgrade to SharePoint 2010, was painful and risky. That requirement was the source of much trouble and gnashing of teeth by SharePoint administrators. Fortunately, our cries were heard by the folks at Microsoft and they benevolently omitted any restrictions regarding which build your SharePoint 2010 farm needed to be at in order to be upgraded to SharePoint 2013. These are a few examples of what’s good. Now, on to what’s not so good.

When upgrading from SharePoint 2003 to SharePoint 2007 you had three options: upgrade SharePoint 2003 in place to SharePoint 2007; attach your SharePoint 2003 content databases to a SharePoint 2007 farm and upgrade your content; or do a side-by-side, or gradual upgrade, whereby both SharePoint 2003 and SharePoint 2007 were installed and running on the same hardware. You would then gradually move your site collections from SharePoint 2003 to SharePoint 2007. After the last one was upgraded, you would uninstall SharePoint 2003 and you had a happy SharePoint 2007 farm. The side-by-side approach was the most popular, but there was an option for almost all upgrade scenarios.

When SharePoint 2010 came out we lost the side-by-side upgrade option, and many tears were wept. This method had been an admin favorite, as it provided a great back-out option. If the upgrade to SharePoint 2007 went awry, the SharePoint 2003 version of the site collection was still there. However, we SharePoint admins are a hearty bunch. We took our upgrade lemons and made some tasty SharePoint 2010 lemonade. After wiping our tears, most SharePoint admin adopted the database upgrade method to get SharePoint 2007 content into SharePoint 2010. It worked pretty well, but it required most companies to buy all new hardware. Great for Dell and HP, not so great for SharePoint customers. Then SharePoint 2013 was released.

We lost one upgrade option, the gradual upgrade, when SharePoint 2010 came out. We lost a second upgrade option, the in-place upgrade, when SharePoint 2013 came out. That’s the bad news. The good news is you won’t have to spend a lot of time deciding which upgrade method is best for you. Your only option is the database attach method.

Service Applications

Since you cannot upgrade your SharePoint 2010 farm, you might assume it’s not possible to upgrade your service applications. For companies making heavy use of service applications, such as Managed Metadata, Search, and User Profile Service, this could be a problem. Those service apps represent a lot of information, and even worse a lot of the SharePoint administrator’s time. All is not lost. There are six SharePoint 2010 service applications whose databases can be attached to a SharePoint 2013 farm:

• Business Connectivity Services
• Managed Metadata
• Performance Point
• Secure Store
• User Profile Service
• Search

Customizations

Customizations are the bane of any upgrade. If everyone just uploaded Word documents to SharePoint, upgrades would be as smooth as butter. That wouldn’t be any fun, though. SharePoint is a great platform to customize, and you could make a wide range of customizations to SharePoint 2010. Some will upgrade well, some not so well. This section covers the ones that will upgrade without much fuss.

There are nearly an infinite number of ways to customize SharePoint, so it can be hard to determine whether it’s going to cause you upgrade-related heartburn or not. As a general rule, any customization you do from the web browser should upgrade just fine. This could be a customization to a list, such as adding a column or two, or creating the view that displays your list just right. It might also be adding some pages to your site, or adding Web Parts to the Web Part pages your site already has. If you made the change inside the browser, chances are good that SharePoint knows what you did, and can handle upgrading it to SharePoint 2013.

The next step in customizing SharePoint 2010 was using the much-maligned SharePoint Designer (SPD). SPD gets a bad rap. Like any tool, whether it’s used for good or evil depends heavily on whose hands it is in. Some customizations made to SharePoint 2010 in SPD are very innocent, such as tweaking the properties of a page or Web Part. Other SPD customizations are evil, such as putting Web Parts on pages outside of Web Part zones. In other words, whether your SPD customization will easily upgrade depends to a great extent on how evil is it. If your users have used SPD to customize pages in SharePoint 2010, that needs to be thoroughly tested before the site collection is upgraded in your production SharePoint 2013 farm. You can do this in a test SharePoint 2013 farm, or by using an evaluation site collection in your production SharePoint 2013 farm.

The final step of SharePoint customizations involves busting the scariest tool of all: Visual Studio. If it can’t be done in the browser, and it can’t be done in SharePoint Designer, if you try hard enough you can probably do it in Visual Studio. As mentioned earlier, the more complicated a customization, the more likely it is to cause problems during upgrade. Like the old saying goes, “complexity is the enemy of stability”; and it doesn’t get much more complex in the SharePoint world than Visual Studio.

There were two supported ways to introduce custom code in SharePoint 2010: farm solutions and sandbox solutions. Both types of solutions are supported in SharePoint 2013, so at a high level everything should work when it’s upgraded. It’s when you get down into the weeds that the trouble begins.

In SharePoint 2010, sandbox solutions were solutions that were uploaded as WSP files to a site collection. From there, webs in that site collection can use the functionality that the sandbox solution provides. That could be Web Parts, branding, lists, or any number of other things. Because sandbox solutions live in a WSP file that is stored in a document library, they are in the same content database as the content, and therefore come along for the ride during upgrade. You don’t need to take any special steps to upgrade them, they’ll just fall in line and work.

The only concern is the code they use. SharePoint 2013 does a pretty good job of understanding SharePoint 2010 API calls and translating the differences in their object models, but it is possible to stump it. There are also some things that have been removed from SharePoint 2013, or just flat out don’t work. Because sandbox solutions are so seamlessly upgraded, it’s easy to get complacent and not test them adequately. Don’t let yourself fall into that trap or your users will be very cranky when things don’t work correctly. Similarly, because SharePoint 2010 sandbox solutions are so effortlessly upgraded, it’s easy to convince yourself to not spend any time looking at the code to see if there’s a better way to do it in SharePoint 2013. However, after your developers or you have gone through some SharePoint 2013 development training, take some time for a good thorough code review of all your solutions. If you don’t have time for formal training, at least read Chapters 10 and 11 to get a handle on the new development landscape. Then crack those sandbox solutions open in Visual Studio and see if there are ways to make them run better in SharePoint 2013.

There have been some discussions about sandbox solutions and their relationship to SharePoint 2013. To quote Facebook, “It’s complicated.” One of the first public announcements about sandbox solutions in SharePoint 2013 stated that they were deprecated — a fancy way of saying that they work now but might not work in future versions. This scared a lot of people, as sandbox solutions were introduced in SharePoint 2010, so it looked like they were going away as quickly as they were introduced. Later, Microsoft clarified its stance, saying that the new SharePoint App model was the recommended way for users to add functionality to SharePoint 2013, and that sandbox solutions were just deemphasized. Regardless of the official word, SharePoint 2010 sandbox solutions work just fine in SharePoint 2013. If their functionality can be done through a SharePoint app, you should consider it.

The other way to extend SharePoint 2010 was with farm solutions. Like their sandboxed brethren, they upgrade pretty smoothly for the most part. Microsoft clearly invested a lot of time to ensure that SharePoint 2013 is backwardly compatible with SharePoint 2010 code. To see how deeply it has integrated support for SharePoint 2010, you can even create a new site collection in SharePoint 2010 mode in SharePoint 2013. When SharePoint 2013 executes code, it evaluates it to determine the version of SharePoint for which it was written. After it has determined that, it looks in different locations for assemblies and other resources. This enables SharePoint 2013 to better handle SharePoint 2010 code without sacrificing flexibility in native SharePoint 2013 code.

Unlike sandbox solutions, farm solutions were not stored in the content databases of the site collections that used them. They’re scoped at the farm level, so they are stored in the farm’s Config database. Because you can’t upgrade your SharePoint 2010 farm to SharePoint 2013, you’ll need to manually install the necessary farm solutions in SharePoint 2013 . Hopefully you have all the installation files, normally WSP files, on a file share somewhere. If so, copy them over to one of the servers in your SharePoint 2013 farm and install them using the same instructions you used when you installed them in SharePoint 2010.

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path +
 "\" + $_.Name; 
      $_.SolutionFile.SaveAs($var)}

# Add all WSP files in the current direction to SharePoint
Get-ChildItem | ForEach-Object{Add-SPSolution -LiteralPath 
 $_.Fullname}
# Deploy all solutions in the farm
Get-SPSolution | ForEach-Object {If ($_.
 ContainsWebApplicationResource -eq $False) {Install-
    SPSolution -Identity $_ -GACDeployment} else {Install-SPSolution
 -Identity $_ -
    AllWebApplications -GACDeployment}}