Fresh Content on SharePointJoel.com SharePoint Ads
Subscribe in a reader
Performance and time to upgrade depends on a number of things. WSS and SharePoint Server provide multiple methods to upgrade, each have trade offs as well as differences in performance. MS IT included their numbers on upgrade performance which help one understand. I think this document talks through some excellent recommendations such as “dry-runs” and trying it out and getting feedback from users.
I understand the question may be an end to end question which would have even more variables, but this should help outline it a bit better. This paper by MS IT has a section in it that is burried. It's the section on upgrade speed. I'm dropping it here to make it easier to find. If you're doing some planning these could offer an aggressive timeline for an upgrade.
http://www.microsoft.com/technet/itshowcase/content/hostsps07.mspx
Upgrade Performance
Table 1 shows the performance of [some] upgrade methods.
Note: Upgrading is more a factor of the number of site collections than the size of the database, except in the case of a gradual upgrade, which must take into account time to transfer files. These times may be different from what an administrator experiences.
Table 1. Measured Performance of Various Upgrade Methods on Microsoft IT Hardware
Content migration
Time
Database attach for Windows SharePoint Services 3.0 shared services
40–60 GB per hour
Gradual upgrade for Windows SharePoint Services 3.0 team sites
15 GB per hour
Database attach for Office SharePoint Server 2007 personal sites
3–6 seconds per site
Database attach for Office SharePoint Server 2007 shared services
Less than 10 minutes per server, but some re-indexing will have to occur after the upgrade because it does not bring across the search catalogs
Planning
In a complex IT environment such as that of Microsoft, planning and preparation were essential for a successful enterprise-wide upgrade to Office SharePoint Server 2007. Microsoft IT prepared detailed plans and schedules for the upgrade and put considerable effort into preparing the environment to make the upgrade as easy as possible. Of course, customers will generally not have access to pre-release versions of software nor reason to test and install every version. Nonetheless, many of the pre-upgrade procedures that Microsoft IT used are generally applicable—and some of the procedures that the team skipped are instructive as well.
Early in the process, Microsoft IT set up Office SharePoint Server 2007 environments on virtual machines for engineering and operational testing. Testing was useful for identifying potential problems, verifying fixes, and validating settings and configurations before deploying the upgrade process.
Microsoft IT performed “dry runs”—basically, full upgrades that never go live to users—wherever possible. Dry runs became particularly important for database attach situations. Because that upgrade methodology depends on a large number of manual settings for success, dry runs helped Microsoft IT identify orphan and problematic sites before an outage occurred.
A very important step that Microsoft IT learned during the planning phase was the language packs have to be installed before an upgrade for the upgrade to be successful. Two planning steps that Microsoft IT did not take could have saved time and effort. The team also learned that it needed to create a process to track and report exceptions, site collections that the team had to upgrade either sooner than or later than planned. Poorly managed exceptions become time consuming and can negatively affect upgrade schedules.