As we know, there are three main ways to perform an upgrade to Office SharePoint Server 2007:

• In-place upgrade
• Gradual upgrade
• Database attach

I used each of the three strategies in different scenarios. However, we overwhelmingly favored gradual upgrade and database attach due to the quantities of sites and data involved, in addition to the large number of users affected.So, I would like to recommend 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.

1. 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.
2. Make sure that level settings are consistent across the environment to be upgraded.
3. Identify and install missing language packs. Doing so during the upgrade itself is inefficient and can cause problems.
4. Schedule and analyze prescans by using the prescan tool (Prescan.exe) at least two days before each upgrade.
5. Upgrades can fail for a variety of reasons. Have a contingency plan in place in case minor or major roadblocks occur.
6. Determine the priority of exceptions and to what degree they will be allowed to affect the schedule. Communicate this information to affected users.
7. 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.
8. 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.
9. 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.
10. Perform a dry run whenever feasible. Identifying and fixing problems beforehand will increase the likelihood of maintaining the schedule after the upgrade begins.
11. Do not avoid testing because of limited hardware resources. Use virtual machines for testing if excess hardware capacity is not available.
12. 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.
13. 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.
14. 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.

Hope this helps!