(This is Part 2 of a 3-part series on upgrading to SharePoint 2010. Please find Part 1 here.)
Welcome back! Thank you for patiently awaiting part two of my three-part upgrade process.
As you read in Part one, there is a lot of planning that needs to go in to upgrading your SharePoint environment. We’ve discussed the hardware requirements that must be in place before upgrading, and I also covered what needs to be done with your current environment to ensure a smooth upgrade.
There are a few unique methods for upgrading from SharePoint 2007 to 2010. The two most popular methods are Database Attach and In-Place. In this post, I will briefly describe both methods and list a few pros and cons of each. In the final post of this series, we will go into much greater detail of each method.
Let’s start with the Database Attach method. In my experience, this has become the preferred method. One of the primary reasons I prefer this method is because you can provision the new farm prior to starting the upgrade process. On the other hand, many companies are not able to afford all the new equipment purchases required to perform this method.
The following assumes that the Domain Controller(s) and SQL Server(s) have been configured:
Before performing any steps on the old environment, you must build out the new SharePoint 2010 farm on the new hardware. If there are multiple SharePoint servers in your farm, it is best to install SharePoint on each of those servers before the upgrade. Once SharePoint is installed on all necessary servers, you must create a new (temporary) Web Application and root Site Collection. These items must be in place so that SharePoint has something to overwrite. The final step on the new farm (for now) is to ensure that all compatible Web-Parts, Add-Ons, 3rd Party Tools and template files from the 2007 environment are installed on the new. It’s best to remove the newly created Content Database from Central Admin. That way you can avoid doing this later. (Remember, the new Web Application and Site Collection are only temporary.)
Once the new environment is prepared, it’s time to move the data. Since this is just a high level overview of the method, I’ll keep it brief. Basically, the existing SharePoint site needs to be placed in Read-Only mode. This prevents any user from making changes to the site and ensures that all data will be successfully moved over. Once the site is in Read-Only mode, the clock starts ticking. There are a few methods of backing up the data in order to move it to the new environment. My preferred method is a SQL backup. I realize this method is called “Database Attach” but truly detaching the database from SQL will bring the site down momentarily until the files can be copied to a new location. A few PowerShell stsadm.exe commands work as well and those will be detailed in my final post. Once the SQL backup is complete, you will now have a full backup of the Content Database. Use any method you would like to get the database onto the new SQL server. Then, perform a SQL restore (or Database Attach depending on the method used) of the database on the new SQL Server.
Now that we have the database in place on the SQL Server, it’s time to move back to the new SharePoint server(s). First, test the content database (stsadm –o Test-SPContentDatabase). This is a PowerShell command that will, again, be detailed in my final post. Essentially, this tests the functionality of the database with SharePoint 2010. If the test fails, it will produce a log file, much like the one from the Pre-Upgrade Check tool. Once it successfully passes the test, it’s time to mount the database (*HINT: use this command: stsadm –o Mount-SPContentDatabase).
This will actually upgrade the database schema to a SharePoint 2010 format. Just simply adding the database through Central Administration will not perform the upgrade. Once the upgrade is complete, you should be able to browse to the new site.
Now, let’s talk about the In-Place Upgrade procedures. I know this method sounds a little self-explanatory, and for the most part it is. However, there are still some very important things to consider, because unlike the Database Attach method, this cannot be undone (at least as easily). Like any upgrade method, you must always start by running the Pre-Upgrade Check tool (stsadm –o preupgradecheck) on the current environment to determine if it’s ready for SharePoint 2010. As I said in my first post, the most important part of the upgrade process is BACKUPS! If you do not have a full backup of your environment and you plan to do an In-Place upgrade, you are essentially going all in with no way out.
Once we finally have a successful Pre-Upgrade Check, it’s time to install SharePoint. It is always recommended to run the prerequisite installer to ensure the Setup process runs smoothly. Now that all prerequisites have successfully installed, it’s time to run Setup.exe. When setup completes, we will want to run the SharePoint Products Configuration Wizard. Specify the farm settings of your choice and wait until the wizard completes.
This essentially completes the In-Place upgrade method. There are a few other items I will include in my much more detailed final post, such as language packs and performing the visual upgrade which provides the look and feel of SharePoint 2010. Keep in mind that both methods maintain the 2007 ‘Look and Feel’ until you choose to run the visual upgrade.
One more thing: Did I mention BACKUPS??! Always, always back up your SharePoint site’s contents before performing any part of the upgrade process.
Stay tuned for Part 3 of 3. Many more details to come! Please feel free to leave comments below with any questions you may have! Thanks again.