Create communication plan (Windows SharePoint Services)
Updated: December 1, 2006
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2007-12-13
In this article:
For small deployments in which sites have not been customized to any great degree, the upgrade team might consist of only one person. For larger deployments, on the other hand, several people with different roles can be required, as shown in the following list.
Server administrators The server administrator performs most of the upgrade tasks. There must be at least one server administrator on the upgrade team because running the Setup wizard requires someone who is a member of the local Administrators group on each front-end Web server.
Note: Farm administrators might or might not be local administrators for the server.
Site collection owners You need to be able to notify site collection owners that the upgrade process is about to happen, and alert them to any issues you find when you upgrade their sites. If you are performing a gradual upgrade, you must also communicate with site collection owners to determine whether their sites have been completely upgraded and any customizations re-applied before you delete or deactivate the old sites.
Site designers and developers If you have custom templates, Web Parts, Web services, or other custom elements associated with your sites, you need to work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements, or to verify that these elements have upgraded correctly. For more information about potential issues with custom elements, see Use a trial upgrade to find potential issues (Windows SharePoint Services).
Site users Although site users won't need to be included in making decisions about the upgrade process, you need to tell site users when it will take place and what they should expect.
Sponsors and other stakeholders You might have other people in your organization involved in the upgrade planning process. Be sure to include them in your communication plan appropriately.
Note: An upgrade team can include one or more members in each role depending upon your organization.
In general, the server administrators set the timeline for upgrade, and site owners are notified only when the process is about to begin. However, because team members have their own tasks to perform at particular points in the overall upgrade process, it is critical that you have a solid plan to communicate the progress of the upgrade to all team members so that everyone knows when it is time to perform their particular tasks.
The entire upgrade team needs to work together to determine:
The upgrade approach to use The Determine upgrade approach topic provides information to help you decide which type of upgrade to perform. The report generated by the pre-upgrade scan tool is also important to take into consideration when making this decision.
Dates and times to perform the upgrade We recommend (particularly for an in-place upgrade) that you upgrade when site usage is low. For small single-server deployments, upgrade may complete in less than a day. For larger deployments, such as server farms with large amounts of data, the gradual upgrade option can be used to distribute the upgrade process over several outage windows. There is no way to determine the exact amount of time required to upgrade any particular site collection. Because of this, it is very important to communicate with other team members involved in the upgrade process as well as end users. The day or days that you choose for upgrading should be far enough in the future to enable the upgrade team time to complete all of the preliminary steps. When planning the timeline, be sure to schedule time to validate the upgraded sites and time to implement any changes or do any work to re-brand sites.
It is important to communicate with site owners, designers, and developers at the following points during the upgrade process:
Before the process begins, so that they know the general timeline and what their roles in the process will be.
After the pre-upgrade scan tool has been run, so that they can address any issues identified by the tool. For more information about the pre-upgrade scan tool, see Run the pre-upgrade scan tool (Windows SharePoint Services). For example, issues such as customized site templates or custom Web Parts should be reported to the appropriate site owner, designer, or developer before scheduling the upgrade to give them time to investigate the issues and take preliminary steps. For example, a developer might decide that it is prudent to rebuild a Web Part before the upgrade occurs. And site owners might want to make note of any customizations that have been done to their sites, including site templates and changes to core Active Server Page Extension (ASPX) files.
After their sites have been upgraded, so that they can review the sites and make any changes necessary. Site owners need to know how long the old versions of the sites will be maintained so that they can be sure to retrieve anything they need from the old site.
It is equally important to communicate with the users of the sites to tell them about the following issues:
When their sites will be upgraded In the case of an in-place upgrade, they must also be informed that their sites will be unavailable during the upgrade.
When to expect their upgraded sites to be ready This means that the upgrade team has not only upgraded but also verified the functionality of the upgraded sites.
How the upgrade might impact them and what they should know about the new environment For example, the site might look different or function slightly differently. Or they may need to reapply customizations from the old site after upgrade. You can also point them to available content, such as What's New articles or training materials, to learn about the new version.
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable books for Windows SharePoint Services.