Microsoft published a technical whitepaper about the lessons learned upgrading/deploying MOSS 2007 at Microsoft itself. In this situation, the environment is huge, but this document will give you several point to take into consideration.
Microsoft IT recommends the following best practices for deployment of an Office SharePoint Server 2007 solution within an enterprise. In some cases, deploying the solution without following these suggestions is possible, but this may result in unnecessary expense or effort.
Best practices for initial activities are as follows:
- Perform a thorough audit of all products and platforms that the upgrade may affect, including Windows Server, SQL Server, IIS, Windows SharePoint Services, and prior versions of SharePoint Products and Technologies, in addition to portals, sites, and content.
- Optimize and clean up current environments. These activities include:
- Merging and splitting databases to optimize sizes.
- Balancing content loads among databases.
- Consolidating server farms where possible.
- Make sure that level settings are consistent across the environment to be upgraded.
- Identify and install missing language packs. Doing so during the upgrade itself is inefficient and can cause problems.
- Document initial activities and discoveries made during the process, creating a reference in case personnel need to look back during the upgrade to see what actions were performed and to help make future upgrades easier.
Best practices for the schedule part of planning are as follows:
- Schedule and analyze prescans by using the prescan tool (Prescan.exe) at least two days before each upgrade.
- Leave space on the schedule to catch up after unexpected events. Upgrading is a complex process with a big impact on the business. It should be completed efficiently but not rushed.
- Upgrades can fail for a variety of reasons. Have a contingency plan in place in case minor or major roadblocks occur.
- Schedule database upgrades based on free space.
- Determine the priority of exceptions and to what degree they will be allowed to affect the schedule. Communicate this information to affected users.
- Frequently update the calendar and provide it to all teams involved.
- Schedule, perform, and confirm backups before performing upgrades. Ensure that backups and upgrades are not scheduled to run at the same time, because this will cause upgrade failure.
- Schedule time and resources for testing and previews of the new functionality.
- In performing a database attach, the number of sites is the most important factor in how long the upgrade will take. If many sites exist on a farm, schedule upgrades based on the number of sites. If there are fewer sites (as may be the case with team and portal sites), schedule them based on the quantity of data.
Best practices for the communication part of planning are as follows:
- Before upgrading, communicate that sites cannot be accessed or reverted during the upgrade.
- Define the upgrade process thoroughly before sending communications about the schedule and process. Not doing so will confuse end users and may encourage them to think the schedule is negotiable.
- Avoid committing to specific dates where possible.
- Use images in communications to explain the upgrade process to non-technical personnel.
- Send notifications to site owners and administrators often—before, during, and after the upgrade.
- Finishing the upgrade is not the end of the upgrade process. Define, convey, and implement a post-upgrade communication plan.
- Define the support process for exceptions and escalations. If some technical issues are not supported, make sure that users know beforehand.
Best practices for the planning process are as follows:
- Training is key to getting the most benefits from Office SharePoint Server 2007, even if users are familiar with Windows SharePoint Services 2003 and SharePoint Portal Server 2003. Plan to invest time, resources, and money in training users.
- Determine whether to reset pages to site definitions (reghost) or leave customizations intact during the upgrade.
Best practices for the upgrade process are as follows:
- Perform a dry run whenever feasible. Identifying and fixing problems beforehand will increase the likelihood of maintaining the schedule after the upgrade begins.
- Do not avoid testing because of limited hardware resources. Use virtual machines for testing if excess hardware capacity is not available.
- Data requirements usually grow during an upgrade; exceeding the capacity of a database will cause the upgrade to fail. Increase the target databases to appropriate sizes before the upgrade process and set databases, temporary databases, and log files to autogrow.
- Watch for upgrade problems caused by full-text search. Moving the SQL Server database to a different server or disabling full-text search on the SQL Server computer can mitigate the impact.
- Maintain a list of which sites have been upgraded.
- Move exception sites to a new content database via the Stsadm.exe command-line tool so that they do not interfere with the general upgrade process and schedule.
- Shut down and restart (bounce) SQL Server computers between SQL Server instances.
- It is difficult to complete tasks correctly the first time no matter how carefully custom templates, definitions, and Web Parts are configured before the upgrade. If performing a gradual upgrade or database attach, maintain a copy of the previous environment to allow for rollbacks if necessary.
- Do not finalize the upgrade until you are sure the upgrade is finished. Finalizing the upgrade removes the connection to the previous version and deletes any temporary data, and it is irreversible.
- Allow only one administrator at a time to make changes to the configuration database.
Best practices for validation are as follows:
- Document the entire process in as much detail as possible. This will enable personnel to track problems back to their sources and will make future upgrades easier.
- Develop custom user guides to help users understand the specifics of your Office SharePoint Server 2007 environment.
- Lock previous site versions after the upgrade to prevent users from making updates to old sites. This not only prevents general confusion, but also helps avoid a situation in which misapplied updates are lost when old versions are taken offline.
Check out the complete document here.