Upgrade considerations for customized sites

This article explains how the upgrade process affects customized pages on your site so that you can make any necessary changes — such as redoing or transferring your customizations — by using Microsoft Office SharePoint Designer 2007.

 Note   If you are an IT professional or server administrator who is tasked with upgrading to either Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007, you can find links to detailed and comprehensive information in the See Also section.

In this article


Types of upgrades

If you have invested time in creating a custom SharePoint site, the prospect of an upgrade to the next version can be both exciting and intimidating. You probably want the new features and functionality, but you may be concerned about how the upgrade will affect your current customizations. This section explains the two types of upgrades that are available (in-place and gradual) and identifies the possible effects of both types of upgrade on a customized site.

When to choose an in-place upgrade

In-place upgrades involve upgrading the system all at once, in a process that updates existing databases and servers. This approach is best for single server or small server farms that do not deploy shared services and that do not have a lot of customizations. Site URLs are the same after the upgrade as they were before. The environment must be offline during an in-place upgrade. There is no way to revert the upgraded environment to its previous state because the old version is overwritten by the new version. Any customizations from the previous state that are to be re-created in the upgraded site must be made from notes or memory because the previous version of the site no longer exists for reference.

When to choose a gradual upgrade

Gradual upgrades involve upgrading the site collections on existing servers individually, instead of upgrading the entire environment at once. This can be a good approach if you operate medium or large server farms that do not deploy shared services, if you have sites that have a lot of customizations, or if you cannot afford to have the entire environment unavailable during the upgrade process. This option allows you to revert back to the original site, if needed, because the data is copied from the original database to a new database before the data is upgraded. The original database is retained until it is explicitly deleted by the server administrator. Gradual upgrades can be a good option for sites that have many customizations, because the site developer can refer to the previous state for guidance on how to re-create customizations in the new state.

Top of Page Top of Page

Decide how to handle customizations

If you have extensively customized your SharePoint sites (by using Microsoft Office FrontPage, for example), you must decide how to handle your customized sites when you upgrade. Your approach will vary based on the extent of the customizations, the complexity of your site, and your goals for upgrading. The types of customized pages that you might encounter include the following:

  • Customized pages    These are pages originally generated based on the site definition but subsequently modified. For example, if you opened your SharePoint site in FrontPage and added text or graphics to the home page, your home page has been customized.
  • Uncustomized pages    These are also pages originally generated based on the site definition that have not been subsequently modified. (Even if you applied a new theme to the site at some point, thereby changing the look and formatting of the site, if you didn't modify the content of a specific page by using a compatible Web site editor like FrontPage, then that page is still considered uncustomized.)
  • New pages    These are pages not originally generated based on the site definition. For example, when a Web designer receives a graphic design for a site, he or she often starts by opening a blank page, adding the graphics from the graphic designer to build the look and feel, and finally inserting Web Parts as needed. Such pages have no association with a site definition.

You can handle the customizations in any of the following ways:

  • Keep the customizations    There are three ways to do this:
    • Do an in-place upgrade, and do not reset the pages to the site definition. By default, an in-place upgrade preserves customizations and does not reset to site definition.
    • Do a gradual upgrade, but keep the site in the old environment (do not upgrade the site). This approach maintains the site in its original state, with the original functionality only.
    • Do a gradual upgrade, and do upgrade the site, but don't reset any pages to the site definition. This approach might result in an uneven look if you have not customized every page. New pages that you create retain the previously customized look and functionality, but uncustomized pages have the new functionality and the new look.

 Note   By default, custom pages are kept as is after the upgrade (except for themes).

  • Discard the customizations    Do either of the following:
    • Do the upgrade (either in-place or gradual), and, when you are done, reset the entire Web site to use the site definition pages instead of your customizations. This way, you can start using the new functionality, and then decide whether to customize the site again. Site owners can decide whether to reapply customizations when they review their upgraded sites.

 Note   If you added a new page to your site (for example, if you replaced default.aspx with a completely different file, rather than making changes to the existing default.aspx file), that new page has no association with the site definition, and so cannot be reset to the site definition. If you want your new page to have the same look and feel as the other pages in your site, consider creating a new page that is based on the site definition, and then transferring your customizations to that new page.

  • Start fresh with a new site in the new environment. This approach works when you are dramatically redesigning your site and don't need to carry forward either the existing site structure or most of the existing site content into the new site.
  • Redo the customizations    Do either of the following:
    • Do an in-place upgrade, and do not reset the pages to site definition. By default, an in-place upgrade preserves customizations and does not reset the pages to the site definition version. After the upgrade, you can open the site, copy the customizations (using Office SharePoint Designer 2007), then reset to the site definition, and finally re-apply the customizations to have both the new functionality and your customizations.
    • Do a gradual upgrade, and then, in the upgraded site, reset the customized pages to the site definition. Finally, transfer the customizations from the old site to the new site by using Office SharePoint Designer 2007.

 Notes 

  • When you perform an in-place upgrade, the upgrade does not preserve the previous version of the site. If you want be able to have the old version and the new version of the site side by side so you can transfer customizations from the Microsoft Windows SharePoint Services 2.0 site to the Windows SharePoint Services 3.0 site, use a gradual upgrade — or, if you are using in-place upgrade, be sure you have a mirrored server or server farm that is still running the old version.
  • Again, resetting to the site definition will not work for truly custom pages that do not have an equivalent in the site definition.

Top of Page Top of Page

Before you upgrade: Identify potential issues

Before you begin the upgrade process, it is important to know approximately how many customizations will have to be redone, and also which sites may not upgrade as expected. The following procedure shows you how to identify the problems that you are likely to encounter during the upgrade process, so that you can address them appropriately afterward.

  1. Run the pre-upgrade scan tool on the server to identify any custom sites or customized pages (required).

You must run the pre-upgrade scan tool to help you identify sites and pages that are customized. For example, issues such as customized site templates and customized Web Parts should be reported to the appropriate site owner, designer, or developer before scheduling the upgrade, to give such people time to investigate the issue and to take preliminary steps. A developer may decide that it is prudent to rebuild a heavily customized Web Part before the upgrade occurs, or the developer may want to make a record of customizations to the site, including site templates and changes to default .aspx files, so that he or she can rebuild them, if necessary, when the upgrade is complete.

  1. Review the common issues that are listed in the next section to see which of them may apply in your environment (recommended, but optional).

The list in the next section gives you a quick look at some common issues that you may encounter and explains how you can address them after completing the upgrade.

  1. Perform a trial upgrade, using a backup or mirrored (read-only) site (recommended, but optional).

This is the best method for identifying possible problems. You can preview the entire upgrade process, find any issues, and address them before you start. At the very least, you will know what to expect. Performing a trial does require extra time and hardware. However, if you can invest those resources, you will have a much easier time during the actual upgrade process.

Top of Page Top of Page

After you upgrade: Redo or transfer your customizations

When you run a test upgrade pass, or when you run the pre-upgrade scan tool, you may notice one or more of the following common issues in your sites. If you have several sites with these issues, we recommend that you perform a gradual upgrade, so that you have both the old version and the new version of any affected sites available and either can revert to the old sites or make updates to the new sites before making the new versions live. If you must use an in-place upgrade, be sure to make a backup of your sites before performing the upgrade. For information about backing up your site, see the article Back up, restore, or move a SharePoint site.

When you upgrade your SharePoint site to Windows SharePoint Services 3.0, you may encounter one or more of the following issues:

  • The look and feel of customized pages changes    Your site's home page, or other pages in your site, may appear differently after the site is upgraded. For example, themes in Windows SharePoint Services 2.0 were collections of industry-standard cascading style sheets that controlled the fonts and formatting for a site. With Windows SharePoint Services 3.0 and Office SharePoint Designer 2007, each updated theme has been consolidated into one cascading style sheet, which also includes more styles and updated styles. After an upgrade, the site's style sheets from the Windows SharePoint Services 2.0 themes are brought over with the upgraded site, but the default theme is changed to the Windows SharePoint Services 3.0 default theme. Because Windows SharePoint Services 2.0 themes do not have updated styles and do not have classes for new styles, they must be updated in order to be successfully applied to Windows SharePoint Services 3.0 sites. Alternatively, if you don't want to update a theme, you can apply a Windows SharePoint Services 3.0 theme that has the look you want.

In addition, site designers may want to implement new master pages to control the look and feel not only of customized pages in the site, but also of the default pages that are generated when you create a new SharePoint list or library. For example, if your Windows SharePoint Services 2.0 site currently uses Dynamic Web Templates to apply a consistent look and formatting to pages, you know that those Dynamic Web Templates only apply to specific pages in the site. With Office SharePoint Designer 2007, either you can customize the default master, or you can create custom master pages and then attach pages to them.

  • Dynamic Web Templates should be replaced by master pages    If you currently use Dynamic Web Templates (DWTs) to define editable regions and to establish the look and feel for a page or pages, you can continue to use DWTs with Windows SharePoint Services 3.0. However, you may prefer to replace your Dynamic Web Templates with master pages because master pages control the formatting not only of specific attached pages, but also of default SharePoint pages (like the Site Settings page and the Documents and Lists page), as well as of new pages. In addition, master pages allow you to designate groups of content regions on attached pages that can be modified by users. For more information, see the article Introduction to ASP.NET master pages.
  • Customizations to pages made by using FrontPage are retained, but new SharePoint functionality is missing    In some cases, you will want to add the new SharePoint functionality (such as the Recycle Bin, or horizontal tabs that link to subsites) to customized pages. To do this, reset the customized pages to the site definition, and then reapply the customizations to each page. For more information about this option, see the article Reset a customized page to the site definition.
  • Web services that have hard-coded URLs no longer work    You may need to reconfigure the Web services that you have added as data sources in the Data Source Library so that they use the new URL schemes and new functionality. For example, during a gradual upgrade, the server URL is redirected to a temporary server for a period of time. During this time, the links to the server that is being upgraded may break.
  • Customized site definitions no longer work    If your sites are based on a heavily customized site definition, we recommend that you create a new site definition before upgrading, and then create a mapping file so that the upgrade process can map your old site definition elements to the new site definition. In addition, if you had custom document types, file types, or editing applications registered with a site definition, you may need to reapply these customizations to the new site definition.
  • Some files can no longer be viewed or opened     Files that have the extension .asmx, .rem, .resx, .soap, or .ashx are no longer visible or can no longer be opened after upgrade. These file extensions have been added to the list of blocked file extensions. If you want to allow users to upload or download files that have these extensions, you can remove the entries for these extensions from the list.
  • Sync to Outlook is missing on view pages     You must reset the page to the site definition to get the new user interface controls on the View pages, such as this control. For more information about this option, see the article Reset a customized page to the site definition.
  • New page cannot be reset to the site definition    If you added a completely new page to your site (for example, if you replaced default.aspx with a completely different file, rather than making changes to the existing default.aspx file), the new page has no association with the site definition, and therefore it cannot be reset. If you want your custom page to have the same look and feel as the other pages in your site, consider creating a new page that is based on the site definition and then transferring your customizations to the new page.
  • Sites are offline during the upgrade process     If you perform an in-place upgrade of your server farm, all sites will be offline during the upgrade, which means that they will be neither accessible nor editable during this time. If your SharePoint environment is a large one, we recommend that you consider a gradual upgrade instead, which will minimize the amount of time when the sites are unavailable. Otherwise, you must alert users to the upgrade schedule so that they can plan to accommodate the offline time.
  • Only Office SharePoint Designer 2007 can open and edit upgraded sites     You and your team members will not be able use Microsoft Office FrontPage 2003 to open and edit Windows SharePoint Services 3.0 sites. You must use Office SharePoint Designer 2007 to edit and customize Windows SharePoint Services 3.0 and Office SharePoint Server 2007 sites.
  • If customizations go wrong, you can reset pages to the site definition    In Windows SharePoint Services 2.0, users who customized their home page but then wanted to reset it back to the site definition found this a frustrating situation if they hadn't saved a copy of their home page. With Windows SharePoint Services 3.0, however, you can reset customized home pages to use the new site definition at any time. Therefore, if you customized the home page of a site but prefer the new look and features of Windows SharePoint Services 3.0 home pages, you can reset your custom home page to use the site definition. For more information about this option, see the article Reset a customized page to the site definition.

 Note   If you added a completely new page to your site (for example, if you replaced default.aspx with a completely different file, rather than making changes to the existing default.aspx file), the new page has no association with the site definition, and therefore it cannot be reset. If you want your custom page to have the same look and feel as the other pages in your site, consider creating a new page that is based on the site definition, and then transferring your customizations to the new page.

  • Site structure changes affect URLs and permissions    Because site structures are changed in Windows SharePoint Services 3.0, some of the hard-coded URLs that are in SharePoint lists or in hyperlink fields in libraries may be changed during an upgrade. For example, if you had some Microsoft Office SharePoint Portal Server areas with the /C2/ or /C16/ paths, the paths may now be /sites/ instead. In such cases, you must locate the Web Parts in which the links reside and then update the links to point to the new location.

Top of Page Top of Page

 
 
Applies to:
SharePoint Designer 2007