Share via

Create a communication plan (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

It is important that you communicate with your users during the upgrade process from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010. Site users need to know what to expect when they visit their sites again after upgrade, and site owners need to know how they can help prepare for upgrade and what they will have to do after upgrade. Both site users and site owners need to know when the upgrade will occur. As part of the planning process, determine the following:

  • Who are the members of your upgrade team, what other stakeholders are involved, and who will be affected by the upgrade.

  • What information must the upgrade team have, and when.

  • What information must site users and other stakeholders have, and when.

This article describes how to create your communication plan so that your upgrade team, your stakeholders, and your users know what to expect before, during, and after the upgrade.

In this article:

  • Who is on the upgrade team?

  • When and what to communicate to the upgrade team

  • When and what to communicate to site users

Who is on the upgrade team?

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 described 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 not be local administrators for the server.

  • Database administrators   If you have a separate database administration team, you must coordinate with them to schedule the upgrade and perform the upgrade, especially if you plan to use the database attach upgrade method.

  • Server security teams   You must coordinate with your security teams, such as the Active Directory directory services team, to verify accounts and permissions or to take advantage of the new policy settings you can apply for SharePoint Foundation 2010.

  • Client deployment team   Communicate with client deployment teams to coordinate deployments of new client and server applications. Client deployment might have to occur before you upgrade, or it could be an option available to users after their sites have been upgraded.

  • Site collection owners   You must notify site collection owners when the upgrade process is about to occur, and warn them about any issues that you find when you run the pre-upgrade checker or when you upgrade their sites. If you are using Visual Upgrade, you must also communicate with site collection owners about the change to the new user interface and whether the farm administrators or site collection administrators will be completing that change.

  • Site designers and developers   If you have custom templates, Web Parts, Web services, or other custom elements associated with your sites, you must work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements or verify that these elements have been upgraded correctly. For more information about potential issues with custom elements, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

  • Site users   Although you do not have to include site users in making decisions about the upgrade process, you must tell site users when it will happen and what they should expect.

  • Sponsors and other stakeholders   You might have other people in your organization involved in the upgrade planning process. Make sure that you include them in your communication plan appropriately.

    Note

    An upgrade team can include one or more members in each role, depending on your organization.

When and what to communicate to the upgrade team

In general, the server administrators and shared services 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 whole upgrade team needs to work together to determine the following:

  • The upgrade approach to use   The Determine upgrade approach (SharePoint Foundation 2010) article contains information to help you decide which kind of upgrade to perform. The report generated by the pre-upgrade checker is also important to consider when you make this decision.

  • Dates and times to perform the upgrade   We recommend (especially for an in-place upgrade) that you upgrade when site usage is low. For small single-server deployments, upgrade may be completed in less than a day. For larger deployments, such as server farms with large amounts of data, the database attach upgrade method or the in-place upgrade with detached databases method can be used to distribute the upgrade process over several outage windows. There is no way to determine the precise length of time that will be 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 in addition to end users. The day or days that you choose for upgrading should be far enough in the future that the upgrade team has enough time to complete all of the preliminary steps. When you plan the timeline, make sure that you 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 checker has been run, so that they can address any issues that have been identified by the checker. For more information about the pre-upgrade checker, see Run the pre-upgrade checker (SharePoint Foundation 2010). For example, issues such as customized site templates or custom Web Parts should be reported to the appropriate site owner, designer, or developer before you schedule the upgrade, to give them time to investigate the issues and take preliminary steps. Or a developer might decide that it would be prudent to rebuild a Web Part before the upgrade occurs. And site owners might want to note 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 that are needed.

When and what to communicate to site users

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 affect them and what they should know about the new environment   For example, the site will look different and function slightly differently in the new user interface. If you are using Visual Upgrade, inform your users whether they will see the new or old user experience and what to expect. You can also point them to available content, such as What's New articles or training materials, to learn about the new version. For more information about feature changes and visual upgrade, see Plan visual upgrade (SharePoint Foundation 2010) and Changes in key features between versions in the article "What's New in Upgrade".

  • How to get help   If they find an issue with their site after upgrade, where can they go to address it?

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010