Pre-Upgrade Maintenance
Generally, SharePoint upgrades go much
smoother when sourced from a well-maintained legacy SharePoint farm. If
your legacy farm is several versions behind on service packs and fixes,
your legacy farm reports critical issues in your health monitoring
service, or perhaps your Windows event log reports some serious errors,
chances are that your upgrade will not go well.
As part of any upgrade plan, it is essential
that you take care of some housekeeping tasks in your legacy system
first. I mentioned a few of them in the previous paragraph. The
following lists those I previously mentioned and some more maintenance
tasks for you to consider before starting an upgrade:
Managing Customizations
Although not unheard of, seldom have I seen a
SharePoint system without any customization. Customization of a
SharePoint farm, site collection, or subsite may consist of the
installation of a third-party module, in-house developed components,
and/or branding. Since SharePoint builds on top of
ASP.NET, and Microsoft promotes extending SharePoint capabilities with
an extensive API, any manner of customizations can be conceived of in a
SharePoint 2010 farm, prior to upgrade.
If something is to go wrong with an upgrade,
the first place I usually look (having combed the log files) is at any
customizations. Even when an upgrade appears to complete without issue,
I am expecting something in the new SharePoint 2013 farm to fail if the
legacy farm included customizations. If you think about it, this is
inevitable: Microsoft cannot account for every possible scenario in the
development of the upgrade process and can really account only for
situations occurring from its own technology. So, if a third party
extends SharePoint (especially if it does not maintain Microsoft
SharePoint development guidelines), it is entirely possible that a
third-party customization will break the upgrade process. This is not
to say you should avoid installing third-party SharePoint components,
or shy away from SharePoint custom development; the key is isolating
these customizations during the upgrade process.
The first task in managing customizations is to
itemize them. If you have only ever installed customizations using
SharePoint deployment packages (Microsoft best practice), then you are
in a good place. However, if your SharePoint site has evolved over time
with various manual edits to files in the hive (the file location where
SharePoint maintains static files), manual changes to configuration
files, and manual placement of custom assemblies in the GAC or web
application, then you have a greater task to manage.
SharePoint 2007 to 2010 upgrade used to include a pre-upgrade check tool,
which would list all potential issues prior to an upgrade. This tool
included a report of all installed features and customizations in the
farm. Microsoft has since retired this tool. Although the process of
identifying customizations is not as straightforward as with the
pre-upgrade checker, the good news is that SharePoint 2013 supports
parallel hives, so you can maintain your customizations in a “14” hive
directory structure without breaking your customizations.
Note SharePoint 2013 no longer supports the pre-upgrade checker.
I recommend that you upgrade all customizations
to SharePoint 2013, which might involve installing the latest version
of a third-party product, or may involve some in-house development of
custom components. However, this process need not hold up the upgrade
process and prevent users using the post-upgraded site on the new
platform while your development team undertakes this effort.
Once you have itemized your customizations, you
should next evaluate the impact of each customization on the upgrade.
Customizations typically fall into one of three categories, as
described in Table 2.
Table 2. Customization Categories
| Visual |
Master pages
Themes
Custom controls
Web pages
Web Parts Custom JavaScript
Custom CSS files |
No impact on database attach upgrades; should work in SharePoint
2010 user interface mode; likely requires change to work in SharePoint
2013 user interface |
| Data Structure |
Content types
List types
Web templates
Site definitions |
May affect database upgrade if content or list types conflict with
new SharePoint 2013 list or content types; missing list definitions or
templates may also cause the upgrade to fail |
| Non-Visual |
Web services
Windows services
HTTP handlers
HTTP modules
Custom classes |
Might not work with SharePoint 2013; test thoroughly in the new
platform and consider updating to a new version (third-party) or
developing against the latest version of SharePoint 2013 API (in-house
development) |
After evaluating every customization and
assessing the impact of the customization on the upgrade to the new
SharePoint system, you can decide the outcome of each customization as
follows:
- Keep the customization but do not upgrade site collections—In
cases where a customization depends on the SharePoint 2010 platform,
e.g., a particular branding married to the SharePoint 2010 branding
style, you can continue to use the customization in the legacy visual
mode. Users are unable to use some of the newer
features of SharePoint 2013 (especially some of the visual
capabilities) until you convert the customization to use SharePoint
2013.
- Replace
the customization—Perhaps you are taking this upgrade
opportunity to redesign your site or redevelop existing customizations.
In this case, redeveloping customizations or deploying the latest
SharePoint 2013–supported version of a third-party component will allow
your users to take full advantage of the SharePoint 2013 capabilities.
-
Discard the customization—Sometimes a customization is no longer
relevant. Perhaps SharePoint 2013 now provides capabilities that
SharePoint 2010 lacked and the customization fulfilled. Perhaps the
upgrade is part of a larger strategy to redesign and there is no place
for a particular customization. In these cases, retire the
customization from service and remove references of the customizations
prior to upgrade (as part of pre-maintenance). The extent of the
customization in the database (e.g., a content type) will determine how
easy it is to remove the customization prior to upgrade, and therefore
determine if you should remove the customization from a production copy
of your SharePoint 2010 farm, rather than production itself—I never
said dealing with customizations is easy.
Different types of customization require
different consideration in their upgrade to work in SharePoint 2013.
Let me assume you have a customization that you intend to upgrade to
SharePoint 2013 and fully integrate into the new visual style of
SharePoint 2013. The implementation type of the customization will
determine the best course of action to upgrade, as shown in Table 3.
Table 3. Customization Types and Upgrade Approach
| Site definition |
Apply the main components of your site definition to an existing
definition in SharePoint 2013—apply features, files, etc. In cases
where you no longer wish to create new sites based on the custom site
definition in SharePoint 2013, you can move over the custom site
definition as is and run legacy sites in SharePoint 2010 mode. |
| Feature |
Evaluate your feature and redesign as necessary. The
feature-packaging model in SharePoint 2013 is identical to that of
SharePoint 2010—it is the capabilities contained in the feature itself
that usually require redevelopment. |
| Workflow and server controls |
Upgrade of workflow and server components depends on the
implementation and typically aligns closely to a business need. Consult
the users of said workflow or component to determine the need of such
functionality in the new SharePoint 2013 system. |
| Event handler |
Event handlers should continue to operate in SharePoint 2013 after
upgrading content. However, any API calls that event handlers make, or
assumptions about the environment, may affect the continual successful
operation of these event handlers. |
| Themes |
You should re-create themes, based on best practices for creating themes for SharePoint 2013. |
| Master pages and CSS files |
Rework visual customizations into SharePoint 2013 master pages and
CSS files so your brand works with the latest SharePoint 2013 user
interface. |
| JavaScript |
Validate that your JavaScript works with the new SharePoint 2013 page mode, and redevelop as appropriate. |
| Web Parts |
Similar to event handlers, Web Parts may make API calls, which
require changes to support SharePoint 2013 API. Additionally, visual
Web Parts should comply with XHTML and support the user interface of
SharePoint 2013 if not operating in legacy SharePoint 2010
compatibility mode. |
| Services |
Services should remain unaffected by an upgrade to SharePoint 2013,
if you host the service outside of SharePoint. Services hosted inside
SharePoint infrastructure follow the same rules as any other code
customization that leverages the SharePoint API and should adhere to
the new version of API. |
| Authentication providers |
SharePoint 2013 implements Claims-Based-Authentication (CBA), which
Microsoft introduced in SharePoint 2010. SharePoint 2013 has dropped
support for Classic Mode Authentication, so you should redevelop any
custom authentication provider that supported Classic Mode and not CBA.
Redeploy and provide to the new SharePoint 2013 farm as part of the
upgrade process. |
| Custom search solutions using SQL syntax |
SharePoint now uses FQL (FAST Query Language) and KQL (Keyword
Query Language) instead of SQL-based search query. Redevelop any
component that uses the legacy SQL syntax. |
Having itemized, evaluated, and reworked (when
necessary) your customizations, the final step is to determine the
packaging type of your customization. Table 4 details the various packaging and deployment types for customizations to a SharePoint farm.
Table 4. Packing Consideration of Customizations
| MSI files |
Vendors sometimes like to package their customizations into MSI
files. In this situation, contact the vendor for the latest version of
the package with customizations that support SharePoint 2013. |
| Manually deployed–dropped files on the server |
As with the previous version, you can deploy these customizations
the same way in SharePoint 2013. As a best practice, I recommend that
you use this opportunity to package all manual configurations into
SharePoint solution packages and features for easy deployment and
retraction. |
| Sandbox solutions |
Sandbox solutions (user solutions) deploy to a site collection and
live in the content database. These solutions operate within a
restricted environment, which SharePoint 2013 supports. You need not
make any changes to these types of deployed customizations, since they
upgrade with the content database. |
| Solution packages (WSP) |
Solution packages are the Microsoft-recommended way to deploy
customizations. Redeploy these solution packages to the new farm and
validate correct operation of your customizations in the new SharePoint
2013 farm. |
| Administrator-deployed form templates |
These templates live in the SharePoint farm and therefore
do not upgrade as part of service application and content database
upgrade. Extract these form templates as XSN files and redeploy them to
the new SharePoint 2013 farm. |
