Microsoft has made some significant improvements in what might be considered the default method for upgrade.  In place upgrade runs by simply running the prerequisites and upgrading running the SharePoint 2010 setup.  Kudos to Microsoft on these improvements.

First 5 key Improvements…

1. No timeouts - So yes, in the previous 2007 in place upgrade, there would be failures based on timeouts related to things like large lists.

2. Continue on failure – Think of it as on error resume next.  In the previous if you ran into something missing or something unexpected upgrade would fail.

3. Resume – After a failure you will now be able to resume where you left off.

4. Error Logging – So the error logging is much better.  It’s in it’s own file so that definitely makes it much easier to troubleshoot and identify issues.

5. Better status output – new stsadm command localupgradestatus which allows you to see the progress of the upgrade after the configuration wizard has been run.  In fact the new UI in Central Admin, Upgrade Status page in 2010 will also allow you to see the database upgrade status.

Sounds great right?  So what RISKS would keep me from recommending it as the upgrade method of choice?  (Don’t be deceived by these improvements.)

The 5 Risks or Downsides

First, you’re environment is 1) down for an 2) undefined amount of time.  Like I said.  DOWN.  In place upgrade does not support read only databases on the source.  Database attach is more flexible and can support both the read only upgrade option and does not require your source environment be down during upgrade.  The undefined part is important as well.  Many will choose to do upgrade without first testing.  This is obviously a very poor choice.  Testing should always be a prerequisite to any upgrade, but those most likely to run the in place upgrade are more likely to not read blogs and to not test.  So they are also the most likely to have issues with upgrade.  The biggest risk with in place upgrade is the 3) unknown on disk space overhead on multiple drives.  Not only is the database drive one that really gets large, but the transaction log drive, and another often overlooked unknown OS drive where the logging is taking place and many install their binaries.  Of these 3 risks, a decent downtime maintenance window and testing should overcome most of these issues, but what happens if you run out of disk space on your OS drive?  Even your database drive or transaction log drive?  All of the above would be disastrous.  In place upgrade has 4) No rollback!  You are stuck with a restore of your environment which may involve some serious flattening and rebuilding if you fill up your OS drive for example.  Your binaries will be messed up as well, so you have to be really smart about what you’re doing.  In place upgrade still feels like rolling the dice by simply looking at your drives and licking your finger and putting it in the air.  You might be ok, but I can’t recommend it as a sole means of upgrade.  Even with testing and some solid preupgradecheck result there’s a bit of a risk. 5) Other unknowns – As a result of preupgradecheck and test-spcontentdatabase not being perfect in knowing everything that can go wrong including unexpected things with upgrade such as lack of visual upgrade on mysitehost for example will result in some surprises.  You don’t want to be surprised.

Conclusion Unless you are ok with the risks, Don’t Do it!

While I do think it’s fairly safe to do an in place upgrade for dev and test environments that have don’t have critical data and other non production upgrades and even cases where you have virtual environments where you can rollback your environment.  I do NOT recommend in place upgrade as the primary method for MOST environments

1) You’re likely going to find out that your environment isn’t ready for it.  The 64bit Windows Server 2008 with 8GB RAM is often not what most environments are at that are looking at in place upgrade.  Not just that but the SQL environment where often it’s on the same box, is it SQL 2005 SP3 CU3 or SQL 2008 SP3 CU2 or R2?  Getting the prerequisites on the SQL side I’ve found SharePoint 2010 in some cases in will not complain about prerequisites until you’re in the middle of your install where it’s too late, and now you’re tracking down QFEs and hotfixes.  Refer to Ji Li’s installation troubleshooting or my SharePoint 2010 list of troubleshooting installation issues post.

2) If you can’t tolerate more than a day or two of downtime  (You may need to restore no matter how good you think you know your environment.  Recovery for many of the failures may result in you needing to rollback which means a recovery.)

3) For the first server in the farm.  While I can see how in place upgrade could be used to upgrade the binaries on the other servers in the farm, I really don’t see this as a very good primary method for upgrade.  Those who are fans of in place upgrade would be better served to use in place upgrade in hybrid mode to simply upgrade the binaries and to use the database attach for upgrading the databases.  You’ll find the flexibility and the benefits.  It’s actually not that odd of a scenario, in fact TechNet includes mention of the detach databases and use in place in the article “Roadmap for in-place upgrade with detached databases (SharePoint Server 2010)”

4) If you’ve got the hardware you should go with the read only databases on the source environment make a copy of the farm configuration and do a hybrid of doing the in place and database attach.  If you don’t have the hardware you should still do a combination by detaching the databases then upgrading the binaries.  I can’t caution enough the fact that you should test to both get an accurate assessment of time, disk space, and dependencies.  There are always going to be things that you won’t expect and it’s these that will make you wish you had a place you could go back to, hence my recommendation for the read only source.

You can read more about In Place Upgrade from TechNet “Perform an in-place upgrade (SharePoint Server 2010)”