Sharepoint 2013 : Upgrading to Sharepoint 2013 - Upgrade Considerations (part 3) - Don’t Upgrade Crap

Don’t Upgrade Crap

The upgrade process in SharePoint has always been very robust, and that continues with SharePoint 2013. However, there are a few things you can do before your upgrade that will make it go more smoothly and quickly. This section provides some guidance on things you can do to prepare for your upgrade to SharePoint 2013.

As you’re planning your upgrade, it’s the perfect time to take stock of your SharePoint 2010 farm and look for pieces to leave behind. This could be any part of your farm, but the biggest bang for your buck comes from pruning unnecessary customizations and unused content. Let’s start with the customizations.

SharePoint is very popular and has been for several years. SharePoint 2010 was the most popular version of all and as such it enjoyed a very rich third-party ecosystem. There’s a solution for almost every SharePoint need. Most SharePoint administrators tried a lot of these solutions before they settled on the ones that met their needs; but not all of the failed solutions were always properly cleaned up. In other cases, solutions are still installed for processes that are no longer being used. Regardless of why they’re there, unused farms or sandbox solutions should be removed in SharePoint 2010 before moving your databases to SharePoint 2013. It was mentioned earlier that customizations are one of the biggest problem points when doing upgrades. It makes sense to remove as many customizations as you can beforehand. You can use the following command in PowerShell in your SharePoint 2010 farm to list any installed third-party solutions:

Get-SPSolution

You can also get this information in Central Administration by clicking System Settings ⇒ Manage farm solutions. Figures 1 and 2 show how this information is displayed in PowerShell and Central Admin, respectively.

FIGURE 1

FIGURE 2

In this case, three farm-level solutions are installed. Each of these solutions should be evaluated to determine whether they are actively used in SharePoint 2010. If not, they should be removed. It should also be determined whether their functionality makes sense in the new SharePoint 2013 farm, and whether the new features of SharePoint 2013 replace the functionality in the solution. If a case can be made to remove them, they should be removed. The fewer moving pieces in the upgrade, the more smoothly it will go and the quicker everyone involved will get their weekend back. If the Deployed status of a solution in SharePoint 2010 is “false” then it is a prime candidate for removal to the “farm” where all our childhood pets now frolic.

Because removing unnecessary solutions only helps if you do it on the SharePoint 2010 side before the upgrade, there is an inherent risk because it’s being done to a production environment. As with any change made in production, ensure that good change control measures are in place, and remove the solution in a test environment first. The solution you are removing may seem useless, but it might quietly add the “Give the SharePoint Administrator a raise” workflow that we’ve all come to know and love.

Although farm solutions are the proper way to extend SharePoint 2010 functionality, there are other, back alley, ways to extend SharePoint 2010. This might be manual web.config edits, manually copying features into the Features directory, or other unsavory approaches. Regardless of how you added functionality to your SharePoint 2010 farm, they should all be evaluated before the upgrade takes place.

Features aren’t the only detritus that should be cleaned up before you upgrade your SharePoint 2010 content. The content itself should be reviewed to see if it’s all worthy of gracing a SharePoint 2013 farm. Just as features are often given a test drive, the same can be done with webs and site collections. Suppose some well-meaning user has a site collection or two created for a fun new project that never really takes off. Or worse yet, they create a web or site collection for the sole purpose of trying something they read on a SharePoint blog, or to try some fancy new SharePoint add-in that is supposed to make SharePoint faster, better looking, and cure ear wax, all at the same time. Whatever the case, once they are abandoned, those little sandboxes don’t seem to be cleaned up very often. If your farm has any number of site collections at all, it can be tough to separate the wheat from the chaff. Fortunately, a little PowerShell will help you root out site collections that haven’t had any changes made to them. The following PowerShell command will list all the site collections in your farm according to the order in which their content was last changed:

Get-SPSite -Limit All | select url, LastContentModifiedDate | Sort-Object -Property
LastContentModifiedDate

The output will look similar to what is shown in Figure 3.

FIGURE 3

This uses the site collection’s LastContentModifiedDate property to tell you when it was changed last. While this isn’t the only way to find stale data, it’s a good way to get the hunt started. If you have a site that is used for archiving, it might be very important but only infrequently updated. Also, each site collection has a LastSecurityModifiedDate that reflects when the permissions on a site collection were last changed. This might also tell you whether a site collection is important. Don’t delete any site collections based on their LastContentModifiedDate alone. This just gives you an idea of where to start investigating first. If you’re not sure whether a site collection should be upgraded, consider creating a new content database in your SharePoint 2010 farm for questionable site collections. Then use the PowerShell cmdlet Move-SPSite to move the questionable site collections there. That way, they won’t slow down your upgrade of the important site collections but you still have them if needed.

Finding webs that haven’t been changed recently is a little tougher, but still doable. The following PowerShell command uses a similar technique to list all the webs in the site collection http://sharepoint/sites/portal to see when they were last modified:

Get-SPSite http://sharepoint/sites/portal | Get-SPWeb -limit all | select url, 
LastItemModifiedDate | Sort-Object -Property LastItemModifiedDate | 
Format-Table -AutoSize

This output will look similar to what is shown in Figure 4.

FIGURE 4

However you determine which functions and features or content you’re still using, spending a couple of hours going through it all can save you a lot of time and frustration during the upgrade to SharePoint 2013.