Export (0) Print
Expand All

Determine how to handle customizations (SharePoint Server 2010)

 

Applies to: SharePoint Server 2010

Topic Last Modified: 2011-09-28

If you have extensively customized your sites based on Microsoft Office SharePoint Server 2007, you must determine how you want to handle your customized sites when you upgrade to Microsoft SharePoint Server 2010. Your approach will vary based on the extent of the customizations, the kind of customization, the complexity of your site, and your goals for upgrading. Before you upgrade, you must identify and then evaluate the customizations in your environment and determine whether you will upgrade them, and how.

In this article:

As part of your upgrade testing process, you should create an inventory of the server-side customizations in your environment (solutions, features, Web Parts, event handlers, master pages, page layouts, CSS files, and so on). For more information about how to identify customizations, see Use a trial upgrade to find potential issues (SharePoint Server 2010). You can use the Upgrade Planning worksheet to list specific customizations and then record the results of your evaluation in the next section. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

After you have identified the customizations, you can decide what to do about them. The following questions can help you evaluate the customizations:

  • Is the customization still valuable?

    • Does it serve a useful business need?

    • Is it widely deployed and used?

  • Is the customization well-designed?

    • Is it built on supported, predefined site definitions?

    • Does it follow best practices for customizations?

    • Is it a supported kind of customization, or does it introduce risk into your environment?

As you evaluate each individual customization, you can also think about your overall approach for customizations. You can choose from among these options:

  1. Keep the customizations   Use Visual Upgrade to continue to use the previous version's user experience for specific sites. Although you can use this approach to keep the same functionality, you will not be able to take advantage of the new visuals — such as the Fluent user interface (UI), also called the ribbon — and capabilities that are available in the new version.

  2. Replace or redo the customizations   If you want to use new functionality, plan to redesign your sites, or are significantly changing the information architecture, the upgrade is your opportunity to start over with new features, a new look, or a new organization. When you replace or redo customizations, you can take advantage of the new capabilities, modify your design slightly if you want, or move to a more manageable design.

    For more information about redoing and redeploying solutions, see Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=182335).

  3. Discard the customizations   Replace the customizations by using default functionality. You can reset pages to the default site definitions and remove any Web Parts or features that you no longer want to support. If you decide to discard any customizations, you must fix any issues that result from removing the customizations in the sites that used them. You can use your customizations inventory to determine which sites require this kind of attention before or after upgrade.

In addition to your overall decision about how to treat customizations in your environment during upgrade, you must examine specific types of customizations to determine whether you must perform any additional actions to make them work in the upgraded environment.

The following table lists some common customizations and a recommendation for addressing that kind of customization.

 

Customization type Recommendation

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. For more information, see Troubleshoot upgrade issues (SharePoint Server 2010).

Site definition

Migrate 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.

However, if you must perform custom upgrade actions for the definition, you might have to create an upgrade definition file for that site definition. For more information, see Upgrade Definition Files (http://go.microsoft.com/fwlink/p/?LinkId=182339) on MSDN.

"Fabulous 40" application templates

Microsoft is not creating new versions of these templates. Sites that are based on these templates can be upgraded, but make sure that you test each site before you upgrade the production environment. For more information, see Troubleshoot upgrade issues (SharePoint Server 2010).

Feature

Evaluate, then redesign or redeploy if necessary.

Workflows and server controls

Depends on the solution. Contact the vendor to find out whether there is an updated solution. If a workflow is compatible with the new version, redeploy.

Event handler

Rewrite and redeploy as a feature.

Managed paths (inclusions/exclusions)

Re-create inclusions for a database attach upgrade. Exclusions are assumed and do not have to be re-created.

Themes

Because of the extensive changes to the UI, custom themes that are based on Office SharePoint Server 2007 will not work in SharePoint Server 2010. Use Visual Upgrade to continue to use the sites in the old user experience until you can create and apply a new theme that is based on SharePoint Server 2010.

Toolbar actions

Move to the ribbon (Fluent UI).

Master pages and CSS files

Rework to accommodate the new user experience.

JavaScript

Test to determine whether any actions are required. In some cases, you might have to adjust the scripts to work with the new page model. Verify that it works on an upgraded site, and in both Visual Upgrade modes.

Search provider or security trimmer

Test to determine whether any actions are required.

Web Parts

Test to determine whether any actions are required. You might have to adjust the Web Parts to work with strict XHMTL mode.

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.

Services

Test to determine whether any actions are required. Redesign or adjust code, as needed.

Authentication providers

Test 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 kinds of customizations are not supported. If you have any of these customizations in your environment, you must replace them by using a supported kind of customization before you can upgrade. Otherwise, you might experience upgrade issues that cannot be fixed:

  • Predefined files, features, or site definitions that have been modified.

    warningWarning
    Some predefined file types — such as document icons or actions — can be modified and although they will not be upgraded, their changes can be carried forward in a supportable way. Modifications to other predefined files, such as server-side ASPX pages, will be lost during upgrade if you revert to the site template. Depending on the files that have been changed and the extent of these changes, the upgrade experience can vary significantly. The best practice is to revert all changes in all files on the disk.
  • SharePoint databases that have been modified, either by directly changing data or changing the schema, including adding or removing triggers, tables, views, or indexes.

If you have any of these kinds of customizations, remove them and replace them with supported customizations before you attempt to upgrade. This is a best practice for helping to ensure that not only your current upgrade will work, but any future upgrades will go more smoothly. Changing predefined files and databases will remain unsupported.

Ensure that your environment performs well and follows best practices. Deploy only those customizations that follow the best practices described in the following articles on MSDN and TechNet:

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft