|
Type of customization or feature
|
Explanation of migration issues
|
|---|
|
Customized home pages
|
Home pages customized by using a Windows SharePoint Services-compatible Web page editor such as Microsoft Office FrontPage 2003 revert to the standard team Web site home page. Home pages customized in the browser retain their customizations, including views that were added and changes that were made to the Quick Launch bar.
Note:
When you migrate a site, the default.htm home page is replaced with a new page. The original default.htm page is renamed as default_old.htm.
|
|
Customized view and form pages
|
Most view and form pages customized by using a compatible Web page editor such as Microsoft Office FrontPage 2003 revert to standard view and form pages. However, views created with other applications or that include settings not available in the SharePoint Team Services browser interface will not migrate.
|
|
Customized link bars
|
Link bars, such as the top link bar, that were customized using a Windows SharePoint Services-compatible Web page editor such as Office FrontPage 2003 revert to the standard link bars.
|
|
Custom script files executed on the server
|
By default, the ISAPI filter for Windows SharePoint Services blocks the use of any script files (such as ASP pages) that are executed on the server and are not part of the installation. If you want to use custom script files with your SharePoint sites, you must put the script files in a separate virtual directory, and create an excluded path for the directory in Windows SharePoint Services. This allows IIS to control the directory, rather than Windows SharePoint Services, and allows the ASP pages to run. Note that script files running on the client are not blocked. For more information about creating an excluded path, see Managing Paths (Windows SharePoint Services 2.0). For more information about ASP pages in Windows SharePoint Services, see Windows SharePoint Services 2.0 Architecture. To prevent script files from being included during migration, either add those file extensions to the blocked files list in the destination Windows SharePoint Services site, or remove those files from your SharePoint Team Services site before migrating. See Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0).
Caution:
Custom script files that are not being executed on the server can be browsed by users with read access to the folder where they are stored on the server. Browsing the files can allow users to discover information such as user names and passwords contained in the script files, as well as network paths.
|
|
Custom pages that link to SharePoint lists
|
The SharePoint Migration Tool does not include an automatic link fixup tool. After migration, any links that you have created to point to specific lists are broken. You can update the links to refer to the current list location after migration.
Note:
If you have a link to a subsite, that link remains, but any links to parent Web sites or other Web sites at the same level do not work.
|
|
Customizations based on CAML
|
Customizations made to your site by using the Collaborative Application Markup Language (CAML) are not migrated. You must re-create these customizations. For more information about customizing SharePoint sites programmatically, see the Windows SharePoint Services Software Development Kit.
|
|
Files or folders with trailing spaces
|
Trailing spaces at the very end of a filename ("filename.doc ") are not supported in Windows SharePoint Services. You must change the file name and then add the file manually to your site.
|
|
Unsupported characters
|
The following characters are not supported in Windows SharePoint Services:
/\:*?"<>|#{}%&~ or tab characters and multiple periods.
If a file, folder, or URL name in your original site contains one of these characters, it is replaced with an underscore (_). Multiple periods are replaced with a single period. Additional digits may be appended to the file or folder name if there are conflicting renaming changes.
|
|
Files with file extensions that are blocked in Windows SharePoint Services
|
A new feature allows server administrators to control whether specific file types can be uploaded or downloaded to the server. If a file in your site uses one of these file extensions (for example, .exe), the file is not migrated to the new site. If you know that certain file extensions are in a site you want to migrate, you can temporarily remove those file extensions from the list of blocked file extensions while you migrate the site. For more information about blocked file extensions, see Configuring Blocked File Extensions (Windows SharePoint Services 2.0).
|
|
Long file and folder names (more than 255 characters)
|
File and folder names longer than 255 characters are not supported in Windows SharePoint Services. You can rename files or folders that have long names before migrating a site, or rename them after migration and add them manually to the new site.
|
|
Lists with too many fields or columns
|
Lists in Windows SharePoint Services can only contain a certain number of fields or columns. If a list in your site contains too many fields or columns, it is not migrated. You must manually re-create the list. Note that this includes surveys. The maximum numbers for fields and columns are:
-
64 text fields, including the following field types: Single line of text, Choice, Hyperlink, or Picture
-
16 Lookup fields
-
16 Date and Time fields
-
16 Yes/No fields
-
32 Number and Currency fields
-
32 Multiple lines of text fields
|
|
Links with long URLs (more than 255 characters)
|
URLs longer than 255 characters are not supported in Windows SharePoint Services. Note that this character limit is for the URL and description.
|
|
User account limits
|
User account limits are not supported in Windows SharePoint Services. If you are using Active Directory account creation mode for user accounts, you can limit the number of users per site by using quotas. For more information, see Configuring Site Collection Quotas and Locks (Windows SharePoint Services 2.0).
|
|
Local user accounts
|
Local user accounts are only supported if you are using Active Directory account creation mode with Windows SharePoint Services, and local user accounts from your original site are not automatically created during migration. If you are using local accounts, first be sure that the server you are migrating to is using Active Directory account creation mode, and then add the users to the site manually after migration. For more information, see Installation Considerations for Windows SharePoint Services 2.0 and Managing Users and Cross-Site Groups (Windows SharePoint Services 2.0).
|
|
Subscriptions
|
The subscriptions feature in SharePoint Team Services 1.0 changed to the Alerts feature for Windows SharePoint Services. Users can create alerts in the new site to notify them about changes. To restore subscriptions as alerts, you must be sure that alerts are enabled for the virtual server you are restoring to. Set the number of alerts to unlimited so that the restore does not stop when it reaches a limit. Also note that if a user only set up subscriptions on the original site and hasn't added information to lists or libraries, his or her subscriptions won't get migrated. To resolve this problem, the user should create a new item in a list and then delete it. For more information about alerts, see Managing Alerts (Windows SharePoint Services 2.0).
|
|
Remote Web discussions and subscriptions
|
Windows SharePoint Services does not support using a server running Windows SharePoint Services in an intranet to discuss content on the Internet, nor does it support creating alerts for content on the Internet. For example, you cannot use http://server1 to create discussion items or alerts for http://www.example.com.
|
|
Web discussions and subscriptions from unavailable user accounts
|
If the user account for a Web discussion or subscription cannot be determined at restore time, the Web discussion or alert is restored with the user name of the administrator restoring the site.
|
|
Security from a site based on FrontPage 2002 Server Extensions
|
If the original server is running FrontPage 2002 Server Extensions, the security information (such as user roles) cannot be migrated.
|
|
Created By/Modified By fields
|
If the original user account is not available on the new server when the site is restored, the Created By and Modified By fields are set to the account that performed the restore.
|
|
Subsites that have the same name as a wildcard inclusion or exclusion
|
If you have set up included and excluded paths for the server that hosts the migrated sites, ensure that the names of those paths do not conflict with the names of the sites to be migrated. For example, if you had a subsite named http://server1/sites, and the /sites path on the new server is a wildcard inclusion, the http://server1/sites subsite is not migrated. For more information about included and excluded paths, see Managing Paths (Windows SharePoint Services 2.0).
|
|
Theme applied to site
|
If the original site was based on SharePoint Team Services and had a theme applied, when you restore the site, you may notice formatting issues such as the Search box being sized differently than it was. To fix these issues, apply a new theme in Windows SharePoint Services.
|
|
Specific file permissions on the file system
|
If you set access control lists (ACLs) on specific files or folders in your Web site, those ACLs are not restored, and the files and folders are accessible to any user with access to your restored site.
|
|
Currencies
|
When migrating a site from SharePoint Team Services to Windows SharePoint Services, Windows SharePoint Services converts some obsolete currencies to their modern equivalents. For example, German Deutschmarks are converted to Euros. However, only the format of the currency field is changed. The value for each entry is not altered and must be manually converted using the desired conversion rate.
|
|
SharePoint Team Services sites based on customized schemas
|
SharePoint Team Services sites that are based on customized schema files may not migrate properly to Windows SharePoint Services. Even though the Software Development Kit (SDK) documented how to customize schema files for SharePoint Team Services, the Smigrate.exe utility does not support migrating SharePoint Team Services sites based on customized schema files.
|